AI Is Not an Engineering Strategy

When a board hears that 90% of code will be written by AI within a year, what do they do about engineering headcount? It’s worth sitting with that question before we rush to complicate it.

The claim arrived with genuine credibility attached: named people, serious people, people who have spent years building the technology said it plainly. A non-technical executive listening to sources of that quality isn’t being naive by taking it seriously. The inference is coherent: if the primary output of an engineering organisation is code, and code is about to become as fast and cheap to produce as a typed prompt, then the people hired to produce code are an obvious area for review. Boards don’t get criticised for responding to that kind of signal. They get criticised for ignoring it.

The argument here isn’t that those decisions were made in bad faith, or that the tools being described aren’t genuinely powerful. It’s that something important got lost between the founder interview and the headcount spreadsheet, and the loss was consequential. What got lost isn’t a nuance that careful reading would have caught. It’s a structural distinction between what “code” means in those original claims and what “engineering” means in the organisations now being restructured around them. That distinction is load-bearing, and reconstructing it is what this post is for.

“AI” is not one thing

The word “AI” is doing an enormous amount of work in most engineering strategy conversations, and most of that work is obscuring rather than illuminating what’s actually happening. The term covers a spectrum of tools and techniques with fundamentally different capability profiles, failure modes, and appropriate use cases. Treating them as a single category is precisely how strategic misunderstanding takes root, and it compounds quickly when structural decisions follow from it.

• General-purpose language models (ChatGPT or Claude consulted directly) are the most widespread and least visible category in most organisations. Engineers use them informally for architecture questions, debugging, and technical decisions, typically outside any governed tooling. The usage is distributed, personal, and rarely audited. The risk surface is real and largely ungoverned, which is its own problem.

• AI coding assistants (Claude Code, GitHub Copilot, Cursor) are amplification tools. They require an engineer to direct them, evaluate their output, and own the result. The output quality depends entirely on the judgement applied to it, and that judgement sits with the person using the tool, not inside the tool itself.

• AI tools for testing, documentation, and code review carry a specific risk that deserves naming directly. They create a measurable sense of quality assurance and process rigour without necessarily delivering it. The danger is that they make weak practices look stronger than they are, providing the appearance of discipline without the substance. An organisation that has substituted AI-assisted testing for a genuine testing culture hasn’t improved; it’s hidden the problem more effectively.

• AI agents and autonomous workflows sit at a meaningfully different point on the capability spectrum. These are systems making decisions and taking actions with considerably less human oversight than a coding assistant requires. The governance demands are correspondingly greater, the failure modes are less visible until they’re consequential, and the skill required to deploy them responsibly isn’t trivially available in most engineering teams.

• Vibe coding is not a tool category but a technique: using AI to explore and prototype quickly without deep engagement with the output. It’s legitimate in its proper context, and it will be examined in detail shortly.

Treating all of these as a single thing called “AI” and making structural decisions accordingly is roughly equivalent to treating a scalpel, an anaesthetic, and a hospital administration system as interchangeable because they all belong in a hospital. The differences matter enormously for how each should be adopted, governed, and understood at a strategic level. A board can’t make sensible decisions about AI adoption if the thing they’re deciding about is defined loosely enough to mean almost anything.

What the founders actually said, and what got lost in translation

The confusion at board level isn’t entirely companies’ fault, and it’s worth being honest about that before the argument becomes more pointed. The claims that shaped this wave of hiring freezes and restructures came from people with genuine authority on the subject. Dario Amodei predicted that 90% of code would be written by AI within a year. Jensen Huang declared that nobody needed to learn to code. These aren’t fringe positions from analysts with peripheral exposure to the technology; they’re the considered views of people building it. A non-technical executive taking those claims seriously is doing the rational thing.

The critical nuance that rarely survives the journey from founder interview to board presentation is what “code” means in this framing. In that context, code means the implementation phase: writing functions, generating boilerplate, translating a well-specified requirement into working syntax. It doesn’t mean:

• understanding the problem deeply enough to specify it correctly in the first place
• making architectural decisions or evaluating the trade-offs between them
• owning reliability and compliance, or responding coherently when things fail in production at two in the morning
• the organisational judgement required to know which problems are worth solving, in what order, and at what level of investment

All of those things are engineering, but they’re not code in the sense those claims were describing.

That distinction is load-bearing, and it’s almost universally dropped in translation. The slide that arrives at a board meeting typically reads something like “AI will write most of the code” with an arrow pointing to reduced headcount. The connection is coherent if you believe that writing code is what engineers are fundamentally for. It fails if you understand that code is what engineers produce during one phase of a more complex process, and that the surrounding phases remain unchanged.

This follows a consistent historical pattern worth noting. Every significant programming abstraction, from high-level languages in the 1950s to object-oriented programming to no-code platforms, has been pitched at some point as making software engineers obsolete or dramatically fewer in number. The demand for people who understand systems hasn’t followed any of those predictions. That’s not professional sentiment defending territory; it’s a structural reality that repeats because the nature of the work expands to fill the space that abstraction creates. Cheaper and faster implementation has historically increased the volume of what gets built, which increases the need for the judgement that guides what gets built. There’s no strong reason to believe the current abstraction breaks that pattern.

What AI-assisted development actually looks like

There’s a significant gap between what AI tooling looks like in a curated demonstration and what it looks like in production engineering work. Most strategic misunderstanding lives in that gap.

The demonstration version is compelling: a developer describes a feature in natural language, an AI produces working code, the developer accepts or lightly modifies it, the feature ships. This is real. It does happen. It’s also a carefully selected slice of a much messier and more demanding process, and it isn’t representative of how the tools perform on production systems with real complexity and history.

In practice, working effectively with AI coding tools is closer to operating as a senior engineer directing a team of highly capable but profoundly forgetful developers. The AI requires continuous governance. Requirements need to be clear and well-structured before the AI engages with them, because ambiguity produces plausible-looking output that solves the wrong problem confidently. Plans need to be documented at a level of specificity the AI can be held to, not because the AI is incapable of generating plans but because it won’t remember them. Expectations that emerge during the work need to be written back into that documentation, or they won’t exist for the AI the next time it looks at the context. Code review isn’t a final check; it’s an ongoing discipline that feeds back into the governance layer, refining the specifications and constraints that shape subsequent output.

The AI doesn’t remember previous decisions, accumulate understanding of a codebase over time, or self-correct against established standards without being directed to do so. That direction requires engineering judgement: knowing what the standards are, recognising when the AI has diverged from them, and having the technical depth to articulate the correction clearly. Engineers who haven’t yet developed that judgement find the tools produce plausible-looking output that requires substantial correction; engineers with strong judgement find the tools genuinely extend what they can accomplish.

This isn’t a limitation that will be patched out in the next model release. It’s structural. The AI operates on what’s in front of it, and what’s in front of it is only as good as the engineer who has defined, structured, and documented it. Better models improve the quality of the output given that context; they don’t substitute for the context itself.

There are also contexts where the collaboration takes a genuinely different shape, and one recent example is specific enough to be worth naming. Developing a Gradle plugin for the JVM build environment involved navigating a language and framework ecosystem where hands-on experience was limited. The engineering work covered architecture, requirements definition, and governance; the AI contributed domain-specific knowledge of Gradle and the JVM ecosystem, filling a knowledge gap that would otherwise have required either substantial preparation time or a specialist engagement. The result was something usable and maintainable.

What made that work wasn’t the AI’s knowledge filling a gap autonomously. It was experienced engineering judgement shaping how that knowledge was applied: defining the architecture clearly enough for the AI to produce coherent implementation, reviewing output against that architecture, and iterating on the specification when the output revealed misalignments. The distinction between “the AI provided knowledge” and “the AI provided knowledge that was applied with engineering judgement” sounds subtle. In terms of what the resulting code looks like six months later, it isn’t subtle at all.

The before and after problem

The productivity gains from AI coding tools are real and, in the right conditions, substantial. AI genuinely compressed the implementation phase: writing functions, generating boilerplate, producing first drafts of code that an engineer can evaluate and refine. Engineering organisations observed this compression and drew a conclusion from it that doesn’t follow.

What didn’t compress is worth stating directly:

• understanding a problem deeply enough to specify it correctly
• making architectural decisions and evaluating the trade-offs between them
• owning reliability and compliance requirements, and ensuring the system that gets built actually satisfies them
• responding to production failures: diagnosing the unexpected, knowing where to look, understanding why the system is doing what it’s doing rather than what it was designed to do

The phases of engineering work that sit before and after implementation require exactly the engineering depth that AI tools have no bearing on.

The strategic error, common enough to deserve naming plainly, is treating a productivity gain in implementation as evidence of a reduced need for engineering judgement. These aren’t the same thing, and the relationship between them is close to the inverse of what most restructuring strategies assume.

Compressing implementation time makes the before and after phases proportionally more important, not less. They now represent a larger share of total engineering effort and they remain entirely dependent on human expertise. The organisation that reduces its engineering investment in response to AI productivity gains is cutting the capacity that covers precisely the phases the tools can’t touch. The cost reduction shows up on a spreadsheet this quarter; the capability gap won’t show up until the system misbehaves in a way nobody anticipated, the architecture proves unsustainable at scale, or the incident that needed deep engineering knowledge to diagnose can’t be properly resolved.

What vibe coding actually is, and is not

Vibe coding is a legitimate technique and it deserves a clear defence before it receives the criticism it also deserves.

Using AI to explore and prototype quickly, without deep engagement with the output, is genuinely useful. It’s the right approach for validating an idea before committing serious engineering effort to it, for building a demonstration to show a stakeholder, for moving quickly in a context where the output is something to be learnt from rather than shipped. The speed is real. The ability to hold a question about what a system might look like and have a working sketch of an answer within hours rather than weeks has genuine value in the right context.

The problem is that vibe coding is being observed at the demonstration level and mistaken for a development methodology applicable to production systems. The moment real users, real data, or real liability enters the picture, the assumptions that make vibe coding productive become the assumptions that create risk. Code produced without deep engagement is code the team doesn’t fully own. It can’t be audited with confidence, because the people reviewing it didn’t build sufficient understanding of it during creation to know where the risks are. It can’t be maintained reliably, because maintenance requires understanding that was deliberately set aside in the name of speed.

The analogy that captures this most precisely is architectural sketches. Architects use sketches to think through a building: to explore ideas, test proportions, and work through spatial problems before committing to form. Sketches are essential to the design process. They’re also entirely unsuitable as structural drawings. The sketch and the structural drawing serve different purposes, are held to different standards, and must never be confused for one another. Confusing them isn’t a minor process error. It’s a category mistake with serious structural consequences, and the consequences don’t announce themselves in advance; they emerge when load is applied.

A vibe-coded prototype that becomes the basis for a production system has undergone exactly that category confusion. The speed that justified the prototyping approach is now a liability: the team owns code it doesn’t fully understand, built on assumptions it didn’t examine, with a risk surface it can’t fully characterise. The refactor required to address this is rarely less effort than building it properly would have been. More often it’s substantially more, because it must be done around a system that’s already in use and can’t simply be replaced.

Explicit policy distinguishing prototyping contexts from production contexts, established before incidents make the distinction obvious rather than after, isn’t bureaucracy. It’s the minimum governance required to use these techniques responsibly.

The amplifier problem

AI amplifies what’s already present in an engineering organisation. Where strong practices, clear governance, and experienced judgement exist, AI makes those qualities more productive. Where those things are absent or underdeveloped, AI accelerates the consequences: more code produced against the same weak foundations, faster accumulation of technical debt, and a quicker arrival at the failures that poor practices eventually produce regardless.

This is the most important thing to understand about AI adoption at scale, and it’s almost entirely absent from the conversations that drive adoption decisions. The tools are pitched as improving engineering outcomes. In well-run organisations with solid foundations, they do. In organisations where the foundations need attention, they tend to make things worse faster.

The pattern visible across organisations adopting AI is consistent. Companies progressing most smoothly are those that have approached adoption deliberately: they’ve examined their existing workflows, identified where AI genuinely improves efficiency, and introduced it gradually alongside the knowledge and experience of already-skilled people. They treat AI as a tool to be used by people who understand their domain well, not as a replacement for that understanding. Adoption starts narrow and becomes broader as the organisation develops the competence to use each category of tool appropriately.

The organisations that are struggling are those that moved to meet investor or board targets without a coherent strategy. Engineers use AI coding tools in isolation whilst the rest of the organisation uses whatever AI their existing vendors have embedded in their products. Adoption is broad and coherence is absent. Nobody is quite sure which tool is responsible for which output. The governance layer is either nonexistent or aspirational. The efficiency gains that motivated adoption are offset by coordination costs and quality issues that come from ungoverned AI use spread across multiple tool categories simultaneously.

The strategic implication is counterintuitive, and worth pausing on. The organisations best placed to benefit from AI are those that have invested most seriously in engineering foundations, and they tend to be the ones least likely to gut that investment in response to capability claims. They understand what the foundations are for. The organisations making the deepest cuts are often those whose foundations were already under strain. AI isn’t improving that situation. It’s accelerating the trajectory those organisations were already on.

The inverted career ladder

The threat AI poses to engineering careers is almost universally framed as a senior problem: expensive, experienced engineers replaced by cheaper tools that can do what they do. The reality points in the opposite direction, and where it points is considerably more structurally serious.

The roles most disrupted by AI capability are at the entry and associate level, and the disruption isn’t elimination but transformation into something the industry hasn’t yet designed a coherent replacement for.

Junior and associate roles have historically been defined by supervised implementation: taking well-specified tickets, writing code under guidance, and learning the craft through repetition and review. The feedback loop of writing code, receiving review, understanding why the approach was wrong, and writing better code as a result is how engineering judgement develops. AI handles the implementation part of that loop competently. This doesn’t make junior engineers redundant; it removes the primary mechanism through which they’ve always developed into capable engineers.

The role needs to become something different: directing AI collaboration effectively, writing clear specifications that produce useful output rather than plausible-but-wrong output, evaluating AI output critically, and identifying where the AI has generated something that looks correct but isn’t. These are skills that currently develop through implementation experience. A junior engineer who has written several hundred functions has, through that process, developed an intuition for what plausible-but-wrong looks like, for which approaches tend to cause problems at scale, for where the gaps typically are in AI-generated solutions to familiar problem types. The pathway to developing that intuition without implementation experience hasn’t been built. Most organisations haven’t recognised that it needs to be.

Mid-level engineers face a compression problem of a different kind. The traditional path from junior to senior ran through accumulating implementation experience until judgement developed naturally: progressive complexity, progressive responsibility, and the gradual development of an ability to see patterns across systems and anticipate where they’ll fail. If implementation compresses significantly, that accumulation path shortens or disappears. Engineers reach the point where senior judgement is expected without having accumulated the hours that previously produced it. Manageable with deliberate investment in structured review, architectural discussion, and involvement in incident analysis; damaging if left unaddressed. In most organisations, it’s currently being left unaddressed, because the pipeline problem is less visible than the headcount line on a spreadsheet.

Senior and principal engineers will find their roles largely recognisable. Systems thinking, architectural decision-making, trade-off analysis, cross-functional communication, incident ownership, and governance: none of that compresses with AI. What changes is the emphasis. Code review and architectural governance become more critical rather than less, because there’s significantly more AI-generated output requiring evaluation. A senior engineer operates increasingly as a reviewer and quality gate alongside existing responsibilities. The judgement requirement stays constant; the volume of work requiring that judgement increases substantially. This isn’t a relaxation of the senior role. In many respects it’s an intensification of it.

The pipeline problem is the structural issue most organisations aren’t yet confronting, and it deserves to be stated plainly. Senior engineers are developed through years of supervised implementation, progressive responsibility, and accumulated judgement. Thinning junior and mid-level roles removes the mechanism that produces senior capability, not merely the roles themselves. In three to five years, the organisations that have done this will find that strong senior hires are harder to find and more expensive to compete for. In a decade, the scarcity will be structural rather than cyclical.

This compounds a pattern examined in “The Expertise Discount”: organisations are simultaneously removing senior expertise on cost grounds and disrupting the pipeline that would eventually produce replacements. Taken individually, each decision can be rationalised. Together, they don’t produce a leaner engineering function. They produce a hollowed one that functions adequately until it encounters a problem requiring the depth it has systematically removed, and the timing of those encounters isn’t under the organisation’s control.

What a genuine engineering AI strategy actually requires

A genuine engineering AI strategy starts with understanding what has actually been adopted. Not “we use AI” but a clear picture of which categories of tool are in use, what governance exists for each, and what the appropriate applications are. The distinctions between informal language model use, AI coding assistants, quality tooling, autonomous agents, and prototyping techniques matter for governance, risk assessment, and appropriate application. Treating them as one thing produces one strategy where several are needed, and most of those needs will go unmet.

Maintaining the engineering depth to cover the before and after phases matters just as much. This means resisting the temptation to respond to AI-driven productivity gains in implementation by reducing the capacity that handles requirements, architecture, and production incidents. The productivity gain and the capability requirement are in different parts of the process. They don’t cancel each other out.

Explicit policies distinguishing prototyping contexts from production contexts are essential, and they need to exist before incidents make the distinction obvious rather than after. The vibe-coded prototype that migrates into production because nobody has a clear rule about when it needed to become a properly engineered system is a governance failure that was entirely predictable. Most organisations will experience at least one version of it. The ones that establish the policy first will experience it less expensively.

Thinking about AI adoption as an amplification investment requires examining what is being amplified before committing to it. The engineering foundation needs to be worth amplifying. Strong practices, clear governance, and experienced judgement aren’t things the tooling provides; they’re what the tooling multiplies. Organisations that haven’t established those foundations won’t find them in the tools. They’ll find the tools making their existing problems more visible, more expensive, and harder to address whilst they’re simultaneously managing the overhead of AI adoption itself.

All of this depends on maintaining a considered approach to developing engineering judgement across the full career ladder, particularly at junior and mid-levels, without assuming the traditional development pathway still functions as it did. The pathway is disrupted. That isn’t a reason to abandon investment in junior and mid-level engineers; it’s a reason to redesign what that investment looks like. Structured exposure to architectural decision-making, deliberate code review practice beyond the pull request, explicit mentoring around how to evaluate and direct AI output effectively: none of this happens by default. It requires intent and resourcing, and the return on it is measured in years.

The pipeline is a long-term asset. It produces the senior capability that makes the rest of the engineering organisation function well. Disrupting it for short-term cost reduction is a trade that looks favourable on a spreadsheet for several years before the consequences become visible. When they do, they aren’t reversible quickly. Senior capability isn’t available on demand; it’s the product of investment decisions made years earlier.

Returning to the question

What did that board actually need to understand before drawing the headcount conclusion from what they heard? Quite a lot, as it turns out.

• That the 90% claim refers to implementation, not to engineering.
• That implementation is one phase of a larger process, and compressing it doesn’t reduce the need for the phases surrounding it.
• A differentiated picture of which categories of AI tool the organisation actually uses, rather than a single word covering all of them.
• That AI amplifies what’s already present, which means the return on adoption depends directly on the quality of the foundation being amplified.
• That the pipeline producing senior engineering capability is a long-term asset that restructuring decisions can damage faster than it can be rebuilt.

None of that is technically esoteric. It’s context that engineering leaders are well-placed to provide and that boards are entitled to expect from the people they rely on for technical judgement. The information gap is real, but it isn’t insurmountable, and closing it is part of what technical leadership in this period means.

The engineering leaders who will look back on this period most clearly aren’t the ones who avoided AI adoption. Avoiding these tools would be its own category of strategic error, and a costly one. They’re the ones who understood precisely what they were adopting, built the foundations to support it, protected the human expertise that makes it work, and maintained deliberate investment in developing that expertise for the engineers who will carry the function forward. That isn’t a conservative position or a defensive one. It’s the only position that makes the tools worth having.

---

About The Author

Tim Huegdon is the founder of Wyrd Technology, a consultancy specialising in operational excellence, AI adoption, and engineering leadership. With more than 25 years of experience in software engineering and technical leadership, including time at Amazon, Tim works with engineering leaders navigating the strategic and organisational dimensions of AI adoption: what it changes, what it does not, and how to build teams and practices that benefit from it without dismantling what makes them effective. His focus is on the distinction between AI as a productivity tool and AI as a substitute for engineering judgement, and on helping organisations understand which one they are actually deploying.