{"slug": "an-open-letter-to-leaders-your-job-isn-t-to-have-the-answer", "title": "An Open Letter to Leaders: Your Job Isn't to Have the Answer", "summary": "Engineering leaders who delay AI adoption because of concerns about output quality, cost, or risk are focusing on symptoms rather than the real problem, argues Paul Stack in an open letter. Stack asserts that models have been capable enough for serious engineering work for nine months, and poor output stems from process limitations, not model limitations. He urges leaders to invest in engineering processes—such as architectural constraints, encoded conventions, and review pipelines—rather than waiting for certainty.", "body_md": "# An Open Letter to Leaders: Your Job Isn't to Have the Answer\n\nI've had versions of this conversation with founders, CTOs and engineering leaders every week this year. The three reasons they give for waiting are all real concerns — and all three are pointing at the wrong problem.\n\nI've had versions of this conversation with founders, CTOs and engineering leaders pretty much every week this year. If you're leading a team right now and you haven't committed on AI, I can almost guarantee you're hearing three things. The output isn't good enough. It costs too much. The risk is too high. These concerns are real but I think all three are leading you to the wrong conclusion. They're symptoms, not the actual problem.\n\nI've written a lot over the past few months about how I work with agents, what's changed, and where I think we are heading. This post's different. This is for the leaders caught between the pressure to adopt and the responsibility of protecting their organisation. I understand your position. You're not choosing between certainty and uncertainty — you're choosing between two different uncertainties, and you're accountable for whichever one you pick. That's genuinely hard.\n\nAnd to be fair, caution was the right instinct in our industry for a long time. A year ago the models were less capable, the tooling was immature, and there were more questions than answers. The problem isn't that you've been cautious, it's that the world has moved while you've been waiting. Those aren't the same thing.\n\nPart of what's made that so difficult is that the conversation itself keeps changing. Every few months there's a new term, a new workflow, or a new way of describing how teams should work with AI. It's easy to mistake that churn for uncertainty about the direction. I don't think that's what's happening. The labels are changing much faster than the underlying direction. The organisations learning how to build reliable engineering systems around increasingly capable models are the ones pulling away.\n\nI think the three inputs shaping your hesitation are leading you stay uncertain, and I want to walk through why.\n\n## \"The output is bad\"\n\nThis is the most common one I hear. The code is sloppy. The agent doesn't understand our codebase. It produces plausible-looking garbage. We can't possibly use AI, we're in a brownfield codebase. And honestly, that tracks with a lot of people's first experience. If you hand an agent an ambiguous prompt with no architectural context and no conventions, you get bad output. Of course you do.\n\nDax Raad, who built [OpenCode](https://opencode.ai/?ref=stack72.dev), said something on LinkedIn that resonated well with me and what I write about:\n\nif you're still struggling to get good code out of the machine, it might be a you thing.\n\nThat sounds provocative but it's accurate. The models have been good enough for serious engineering work for about nine months. The teams getting bad output aren't hitting model limitations. They're hitting process limitations.\n\nWhen you give agents architectural constraints, when you encode your conventions into something the machine can follow, when you build review pipelines that catch the things humans used to catch in code review, [the output changes](https://stack72.dev/the-vibes-dont-scale/). The model didn't get smarter, the process around it did. Good engineering has always been more about process than individual brilliance. AI just makes that impossible to ignore. In the previous era of software, you could hide a bad process and still get results. In this AI-led era, a bad process can't be hidden and will come back to kick you in the ass sooner and harder. The feedback loop is so much faster now that the pain shows up before you've had time to pretend it isn't there.\n\nIf the report you're getting from your team is \"the output is bad,\" ask whether anyone has actually done the engineering to make it work in your environment. That's a solvable problem and waiting doesn't solve it.\n\n## \"It costs too much\"\n\nThis one usually shows up as a spreadsheet. Someone ran a pilot, looked at the token spend, extrapolated to the whole team, and the number looked scary.We've all see this kill AI initiatives more than any actual technical failure.\n\nI've heard of teams allocating token budgets by seniority: $50 a month for juniors, $100 for seniors, $200 for principals. That tells you everything about how leadership is thinking about this. They're managing cost by title, not by value. A junior with good conventions and a well-scoped problem might generate more value per token than anyone else on the team. But you'd never know, because you've capped them before they can show you.\n\nMost teams measure the cost of their first attempt and treat it as the cost of the approach. Adam Jacob carried out a bunch of research on this and wrote [a practical guide to reducing token spend](https://www.adamhjk.com/blog/a-practical-guide-to-reducing-token-spend/?ref=stack72.dev) that shows what happens when you actually engineer the workflow. He took an existing pattern someone created from 23 agents to 3, cut it's token usage from 4.6 million to 500,000 (an 8x improvement) and halved it's execution time. That wasn't because of better prompts, it came from removing the LLM from loops where it didn't need to be and replacing agent coordination with deterministic code.\n\n[The agent builds the thing once, a deterministic workflow runs it forever](https://stack72.dev/stop-paying-your-agent-to-do-the-same-job-twice/). You use the agent to build the program that minimises the need for the agent itself. That's the architecture that makes the economics work. Cost projections based on an unoptimised pilot aren't measuring the technology, they're measuring a first draft.\n\nThe teams I talk to who've got past this phase describe the same trajectory. High token spend initially, then a sharp drop as they learn where the LLM adds value and where deterministic code does the job better. That's the pattern we built [swamp](https://swamp.dev/?ref=stack72.dev) around. You spend the tokens to have an agent build the automation, then you work to remove inference from the hot path so the workflow runs deterministically from that point on. The expensive part is temporary by design, and it only stays expensive if nobody engineers it down.\n\n## \"The risk is too high\"\n\nThis is the one I take most seriously because it's the one most grounded in legitimate concern. You're responsible for production systems. Agent-generated code that breaks something is your problem. I get it. If I were in your position and someone told me to trust code I hadn't reviewed from a system I didn't fully understand, I'd push back too. We read about people having outages caused by agents changing production systems all the time.\n\nIs \"can we trust agents?\" the wrong framing. The useful question is what trust infrastructure you've built around them. Layering adversarial AI review on every PR: conventions, edge cases, UX consistency, security. Each one independently trying to find problems. That's systematic verification, and it's buildable.\n\nThe payoff goes beyond safety. With that infrastructure in place, code changes that could never be justified, including full rearchitectures, become days of work rather than quarters.\n\nAgent-generated code with proper guardrails still carries risk. But it's measurable risk, and it's manageable. Meanwhile, the risk of not rearchitecting when you know you should, of carrying technical debt because the cost to address it was always too high, of shipping slower because every change is manual. Nobody puts that on a slide, but it's just as real. You're already managing risk. The question is whether you're accounting for all of it.\n\n## The job isn't a mandate\n\nHere's where I want to be direct with you: the answer isn't to mandate AI adoption from the top. I've watched enough top-down mandates fail to know that's not the only way. But the answer isn't to ban it either. Both of those are leadership avoiding the harder work.\n\n[Mews](https://www.mews.com/?ref=stack72.dev), a hotel software company valued at $2.5 billion, recently laid off 200 people, 15% of their workforce. Their CEO said AI makes it so \"a singular employee can do so, so much more with AI.\" They raised $300 million six months earlier. They spent six months training their teams. And they still ended up cutting 15% of the company because the organisational structure they had was designed for a throughput that no longer exists.\n\nCredit to Mews, that's actually impressive leadership. They recognised the mismatch, they made the hard call, and they talked openly about why so others can learn from it. That takes courage. But it's also what happens when the structure hasn't evolved alongside the tooling. We're going to see more of this. Companies that adopted AI but didn't rethink how their teams are organised will hit the same wall. The restructuring isn't a failure of AI adoption. It's what happens when you adopt the technology without adapting the organisation around it.\n\nCompare that to a CEO I who recently [banned AI entirely](https://www.inc.com/joe-procopio/the-first-company-wide-ai-ban-just-hit-my-inbox-heres-what-it-means/91357535?ref=stack72.dev) because he \"couldn't get people to make the right judgment calls on where it made sense to use AI and where it didn't.\" So instead of building that judgment, he removed the option entirely.\n\nNeither approach fully works because neither involves the people doing the actual work in figuring out what changes. The engineers on your team already know which parts of their job are tedious and mechanical. They know where they waste time on implementation that doesn't require judgment. What they need from you isn't a mandate or a prohibition. It's space to figure it out, and infrastructure to make it safe.\n\nThat means investing in the conventions, the review pipelines, the architectural boundaries that make agent-assisted work reliable. It means letting teams experiment with real problems, not sandbox demos that never graduate to production. It means being honest that nobody has this perfectly figured out yet, and that's exactly why you need your people learning now, not later. Your job isn't to have the answer. It's to create the conditions where your organisation can find it.\n\n## What waiting actually costs\n\nI know \"act now\" sounds like pressure, and I know you're getting that from every direction already. But this isn't about urgency for its own sake. It's about what's quietly happening while you deliberate.\n\nThe industry is still figuring out how AI changes the shape of engineering organisations. Mews is evidence of that. So is every team running a pilot that never graduates, every committee evaluating tools their competitors shipped with six months ago. Nobody has the final playbook. But the teams doing the figuring are building knowledge their competitors don't have. Every workflow they encode, every convention they capture, every architectural pattern they learn compounds. [The teams that started nine months ago aren't just nine months ahead](https://stack72.dev/the-gap-is-already-wider-than-you-think/), they're nine months of compounding improvements ahead, and that looks nothing like linear progress.\n\nThe cost of waiting isn't just lost productivity. Your best engineers, the ones with the judgment you can't afford to lose, are watching. They know what's possible. They're reading the same posts, trying the same tools on side projects, seeing the same results. If you're not giving them space to work this way, someone else will. And when they leave, they take with them exactly the institutional knowledge and judgment that would have made your AI adoption successful.\n\nThe people who stay build muscle memory around processes that are becoming obsolete. When the correction comes (and it will, because the results from teams working this way are getting harder to ignore) you'll be staffed with people trained to work in a way that no longer exists, trying to catch up to competitors who've been compounding for a year.\n\n## The question you're actually answering\n\nEvery one of those three inputs (bad output, high cost, too much risk) has the same root cause. They're engineering problems, not technology problems. I think that's where many organisations are getting stuck. They're treating an engineering problem like a procurement problem, waiting for the next model or the next tool instead of building the capability to use what already exists well. Process, architecture, infrastructure. All solvable. All being solved right now by teams who decided to treat them that way instead of as reasons to wait.\n\nNobody has this figured out perfectly. I haven't. Mews hasn't. Many others are trying to get there too. The teams writing about their successes are leaving out the failures it took to get there. But the direction is clear, and the gap between teams who are learning and teams who are waiting is widening every week.\n\nYour team is waiting for something from you. Not a mandate — a direction. Space to experiment, infrastructure to make it safe, and honest acknowledgement that the way you've been building software is changing whether you're ready or not. You don't need to have all the answers. You need to let your organisation start finding them.\n\nWhether to adopt AI isn't really the decision anymore. That one is being made for you by every competitor, every model release, and every engineer discovering what's now possible. The harder question isn't whether AI belongs in your organisation. It's whether your organisation knows how to learn while the ground is moving beneath it.\n\nThat's the job now. Not predicting the future perfectly, but creating the conditions where your people can discover it safely.", "url": "https://wpnews.pro/news/an-open-letter-to-leaders-your-job-isn-t-to-have-the-answer", "canonical_source": "https://stack72.dev/an-open-letter-to-leaders-your-job-isnt-to-have-the-answer/", "published_at": "2026-07-23 14:47:39+00:00", "updated_at": "2026-07-23 15:08:58.629727+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-agents", "developer-tools"], "entities": ["Paul Stack", "Dax Raad", "OpenCode"], "alternates": {"html": "https://wpnews.pro/news/an-open-letter-to-leaders-your-job-isn-t-to-have-the-answer", "markdown": "https://wpnews.pro/news/an-open-letter-to-leaders-your-job-isn-t-to-have-the-answer.md", "text": "https://wpnews.pro/news/an-open-letter-to-leaders-your-job-isn-t-to-have-the-answer.txt", "jsonld": "https://wpnews.pro/news/an-open-letter-to-leaders-your-job-isn-t-to-have-the-answer.jsonld"}}