There is a growing belief that AI will dramatically reduce the need for experienced software engineers. It won’t.

The demonstrations are compelling. We see AI connected to Figma for design context, Jira for tickets, source control for repository history, and CI/CD pipelines for deployment. A feature request goes in, code comes out, and a pull request appears. The workflow looks increasingly automated.

On the surface, this automation appears to be the natural evolution of software development. In practice, however, it is far more constrained.

The assumption behind these demonstrations is that the inputs are complete. The Jira ticket captures every business rule. The acceptance criteria anticipate every edge case. The design system is fully consistent. All dependencies are documented. There are no unanswered questions. There is no ambiguity.

In more than twenty years of building software across enterprise systems, I have never seen a ticket that meets that standard.

Real tickets are approximations. They capture intent, not full reality. They rely on knowledge that exists in conversations, prior decisions, Slack threads, and architectural conventions that were never formally documented. They reflect trade-offs that were negotiated informally. They assume the context that experienced engineers carry implicitly.

Automation assumes clarity, but most real-world software development operates under ambiguity. This has many implications for software development organizations, but the most important is that experienced engineers are still needed. In fact, they are more valuable than ever.

The price of imprecision

The ambiguity inherent in software development tasks does not mean AI-driven automation will not work. It means its effectiveness is directly tied to how precisely the problem is defined. If you want AI to autonomously build a feature, your instructions must approach the level of a complete technical specification. Every edge case must be identified in advance. Every assumption must be explicit. Every open question must be resolved before implementation begins.

The intelligence of the output never exceeds the precision of the input.

That principle applies broadly. With AI, however, the gap between incomplete input and confident output can be harder to detect because the result looks polished and authoritative.

I have used AI to build entire features. When you describe the problem clearly enough, AI will generate code that compiles, runs, and often handles more scenarios than you initially considered. It feels efficient. It feels modern. It feels inexpensive.

However, the result is frequently more complex than what I would have written myself.

There is a quiet truth about developers that rarely gets stated openly: we are lazy. At least, I am. I do not want to write more code than necessary. I want the smallest solution that solves the problem cleanly. That instinct is not about shortcuts; it is about discipline. When I invest time thinking about structure before writing code, the implementation becomes smaller. Clear boundaries eliminate duplication. Accurate modelling removes defensive branching. Thoughtful constraints reduce the need for additional layers.

Good architecture allows you to write less.

AI optimizes differently. It optimizes for coverage and robustness. It anticipates variations. It introduces abstractions to cover broader cases. The generated output is rarely incorrect, but it is often comprehensive in ways that exceed the immediate need. That comes with a cost. 

When requirements change, you must modify logic you did not consciously design. When a bug surfaces, you are debugging control flow that you never fully reasoned through. When another engineer asks why a specific abstraction exists, the explanation may be that it was part of the generated solution rather than a deliberate architectural decision.

AI reduces the cost of writing code. It does not reduce the cost of owning it.

Ownership includes understanding. It includes the ability to reason about how a change will propagate through the system. It includes confidence that simplifying logic will not introduce unintended consequences. This understanding and confidence reside in engineers, not AI.

Acceleration amplifies architecture – good or bad

If your system’s boundaries are clear and your domain model coherent, AI increases your leverage. It allows you to extend that structure more quickly. If the architecture is loosely defined, AI accelerates the accumulation of complexity. The tool does not change direction; it increases velocity.

That amplification becomes especially visible in larger organizations, where architecture is not a diagram but accumulated history.

Enterprise systems are rarely greenfield. They evolve over the years. They carry decisions made under old constraints. They include integrations that cannot be easily rewritten. Much of what keeps them stable is not captured in documentation; it exists in memory. It is the knowledge of why a certain boundary was introduced, why a dependency was restricted, and why a previous refactor failed.

AI does not have access to that lived architectural memory unless it has been painstakingly encoded somewhere. Even then, it interprets patterns statistically rather than contextually. It does not remember the outage caused by an overly coupled service. It does not remember the internal debate that led to isolating a pricing engine. It does not remember why a team chose simplicity over extensibility in a specific module.

Experienced engineers remember those things.

That memory shapes decisions in subtle ways. It influences whether a new abstraction is worth introducing. It informs whether a shortcut is acceptable. It determines whether a proposed simplification might destabilize another part of the system. These considerations rarely appear in Jira tickets, yet they materially affect implementation quality.

The more AI-driven the workflow becomes, the more valuable that architectural memory becomes. Without it, teams risk repeating past mistakes more efficiently. When implementation accelerates but contextual awareness does not, fragility scales.

There is also an organizational shift embedded in this change. If teams want AI to implement features autonomously, they must dramatically improve how requirements are written. Tickets must move closer to formal specifications. Ambiguity must be resolved earlier. Decisions that were once clarified during implementation must now be clarified before prompting a model.

Someone still needs to decide what the system should do. Someone still needs to define boundaries. Someone still needs to determine how a new feature integrates with existing constraints. AI does not remove that responsibility. It simply changes where friction appears.

A new, old kind of engineering expertise

For years, technical depth was often demonstrated by the ability to write complex-looking code, to master framework internals, or to assemble sophisticated reactive flows. Those skills still matter, but they are no longer differentiators in the same way. AI can assist with all of them.

What remains scarce is judgment.

Judgment is the ability to recognize when a solution is heavier than the problem requires. It is the ability to model a domain accurately before introducing abstractions. It is the discipline to choose restraint over cleverness. It is the awareness that every additional layer becomes a future maintenance cost.

In my 20-plus years of working as a software engineer, I have seen the tools evolve dramatically. We have moved from manual infrastructure management to cloud platforms, from verbose frameworks to declarative ones, from hand-written configuration to generated scaffolding. Each wave promised increased productivity. Each wave delivered it.

What never changed was the need for someone to think deliberately about structure before scale magnified its flaws.

AI is another wave of leverage. It raises the floor of productivity. It lowers the barrier to experimentation. It makes scaffolding and boilerplate nearly trivial. But durable systems are not defined by how quickly they were assembled. They are defined by how intentionally they were structured. Working software is not the same as durable software.

AI makes it cheap to build software. It does not make it cheap to think. And thinking remains the part of the job that determines whether a system merely functions today or continues to function tomorrow.