When writing code stops being the bottleneck

The topic of a recent AWS User Group Hong Kong meetup was:

Will software engineering be replaced by AI?

The AWS User Group Hong Kong meetup behind this post.

My answer used to be a comfortable no. It is not anymore.

AI is already replacing part of the job: the production of code. That part is bigger than many engineers want to admit, and the change is moving faster than many companies are ready for.

But writing code is not the same as software engineering. AI is compressing one part of the job extraordinarily quickly. The mistake is taking the fastest-changing slice and calling it the whole profession.

Copy linkWhat software engineering really is

Code is the most visible output of software engineering, so it is easy to confuse the two. The actual job is broader: design, build, verify, operate, and evolve.

It starts even earlier: someone has to decide which problem is worth solving. Then we define the behaviour, choose the architecture, implement it within real constraints, release it safely, support it, and change it without breaking everything around it.

At work, I lead engineering teams but still spend time in our TypeScript codebases. The implementation matters. A bad implementation creates real cost. But many of the decisions that determine whether a feature succeeds happen before the first line is written and after the pull request is merged.

What does the user actually need? What can possibly go wrong? Does this fit the system we already have? Is it valuable enough to justify another thing that must be reviewed, secured, monitored, and maintained?

AI can help with every one of those questions. It does not make them disappear.

Copy linkThe fear is understandable

For years, scepticism was reasonable. Generated code looked impressive in a demo and then fell apart under real constraints. It would put non-existent packages in package.json, reinvent a helper already sitting three files away, or, given enough autonomy, accidentally rm -rf your entire operating system. That history makes it tempting to dismiss today's models as better autocomplete. I think that is now a mistake.

The generation layer is no longer a toy. Models can do more than fill in boilerplate, and telling engineers that AI is merely another tool avoids the real question. If an important part of how we create value becomes dramatically cheaper, what happens to the rest of the job?

The fear is rational because our industry has spent decades treating coding as the profession. We test candidates on it and estimate projects around it. If a model can produce that output faster and, increasingly, better, something fundamental has changed.

Copy linkThe model that actually convinced me

For me, the inflection point was Claude Fable 5.

A lot of engineers reached this conclusion with Opus 4.6. I did not. It was useful, but I still felt that I was supervising a fast assistant whose output needed substantial correction.

Fable 5 felt different.

What impressed me was not the amount of code it produced. It was the quality, thought, and depth behind the implementation. On non-trivial TypeScript work, I found myself reviewing its output the way I would review a strong engineer's pull request: checking assumptions, examining trade-offs, and deciding whether the approach suited the wider system, rather than rescuing a pile of plausible syntax.

I still test it, challenge its assumptions, and reject approaches that do not fit. The difference is the posture of the review: the first draft is often genuinely strong.

Competing in the AWS AI League had already reinforced another lesson for me: reliable AI systems depend on good decomposition, tools, context, and guardrails, not just a clever model. Fable 5 changed a different belief. The raw implementation itself could now be better than what many senior engineers would produce on a first pass.

That is worth saying plainly. It is also not the same as saying the model can replace the senior engineer.

Copy linkWhat AI actually replaces

The most obvious target is the build slice of software engineering: starting from a blank file, connecting APIs, implementing known patterns, generating tests, refactoring, debugging, and translating a reasonably clear design into a working change.

AI compresses the distance between clear intent and a reviewable implementation. It increasingly helps with design and verification too. A well-scoped feature that once took days can take hours.

AI is an amplifier, not an equaliser. A good engineer asks better questions, provides the missing context, decomposes the problem well, and knows when a polished answer is still wrong. AI turns that judgment into better results at much greater speed.

The opposite is also true. An engineer with weak judgment can give vague direction, accept plausible output uncritically, and produce the wrong system faster. AI amplifies the user, including their blind spots.

That amplification is real leverage. Small teams can explore more ideas and ship at a pace that previously required many more people. The cost of rolling out a well-defined feature has fallen dramatically.

But cheaper generation does not make every feature worth building.

The model bill is not the cost of the feature. Every addition expands the surface area that people must review, test, secure, operate, document, support, and eventually remove. It creates more behaviour for users to understand and more interactions for the system to carry.

So the scarce question moves upstream. It is no longer only:

Can we build this?

It is increasingly:

Is this worth instructing AI to build?

Copy linkWhat remains scarce

AI is very good at turning a clear request into a technical draft. It is less reliable at deciding what the request should have been.

A model can draft a specification, and it should. But I would not let it invent the feature request and then treat that proposal as product truth. Humans still need to supply or ratify the objective, constraints, priorities, and trade-offs.

The model does not automatically know which stakeholder has misunderstood the problem, which constraint was left out of the ticket, or which minor behaviour will become an operational burden six months later. And it does not own the consequences when the answer is wrong.

Context, judgment, verification, and ownership become scarcer as generation gets cheaper. Someone still has to define success, surface the missing constraints, demand the right evidence, and decide whether the result is right for this use case, not just technically impressive in isolation.

Copy linkPeople skills get more important, not less

One of the strongest ideas from the meetup was that people skills become more valuable as AI handles more of the technical production.

Cheaper implementation means organisations can request more. Every stakeholder has another feature that would be useful. The bottleneck shifts from producing technical drafts to deciding which requests deserve to become part of the product.

That requires engineers who can uncover the actual need, separate must-haves from nice-to-haves, and push back without turning the conversation into a confrontation. That distinction is rarely a pure intelligence problem. It is a negotiation among competing goals, incentives, constraints, and tolerances for risk.

Useful pushback is not, "No, that is a bad idea." It is closer to: "We can deliver the core outcome first. This additional behaviour increases the review and operating cost; can we validate the first version before taking that on?"

AI can help phrase that response. It cannot build the trust that makes the response effective.

As technical drafts get better, stakeholder negotiation, expectation-setting, and clear explanations of trade-offs become a larger part of engineering, not a soft extra around the edges.

Copy linkReplacement versus leverage

None of this means every current engineering role is safe.

The same productivity gain can look like leverage or replacement. One company will keep its team and ship more; another will keep its roadmap and use a smaller team. Roles built mainly around translating tickets into code will shrink. Pretending otherwise would make this argument less honest.

But a better draft does not remove the need for responsibility. It increases the amount of output that each person can put into the world, as well as the damage a weak requirement or missed assumption can create.

Engineering value shifts from typing the code to directing the work, verifying the result, and owning the outcome.

Copy linkDo we still need juniors, or even seniors?

If AI writes better code than most junior engineers, why hire juniors?

Because a healthy engineering organisation does not hire juniors as inexpensive code generators. It hires them for their contribution today and to develop the people who will carry its technical judgment tomorrow.

The apprenticeship has to change. Juniors should learn to define, instruct, verify, and own, not compete with a model on typing speed. AI can shorten their path to useful end-to-end ownership: give them bounded changes to specify, generated work to challenge, evidence to produce, and production behaviour to observe.

That is how they build real understanding. Tests, documentation, and runbooks should preserve the knowledge; people build continuity and the next generation of expertise. If every company stops hiring juniors because the model closes tickets faster, the industry creates its own shortage later.

The same uncomfortable question applies to senior engineers. If Fable 5 can outcode many of them on a bounded implementation, what is seniority for?

Seniority is becoming less about producing the best first draft and more about knowing which draft fits this system, which evidence should be demanded, and which risks the team is accepting. Oversight is not passive approval. It is problem framing, constraint-setting, integration across systems, verification design, mentoring, and ownership of high-blast-radius decisions.

Seniors are not automatically protected. AI can compress senior-heavy teams too. Deep technical understanding matters because polished, plausible code arriving at high velocity is harder, not easier, to challenge.

Copy linkWhat the job is becoming

I see six practical shifts:

1. From tickets to problem selection. Before asking AI to build, decide whether the outcome deserves to exist and carry a maintenance cost.
2. From vague requests to precise specifications. Define behaviour, constraints, acceptance criteria, and what is deliberately out of scope.
3. From authoring every line to directing the work. Decompose the problem, provide the right context, inspect the result, and know when to take over.
4. From code review to evidence review. A clean diff is not enough. Demand tests, invariants, failure modes, security reasoning, and operational proof.
5. From shipping to owning. Observe the feature in production, prepare the rollback, respond when it fails, and evolve it as the system changes.
6. From individual output to organisational leverage. Negotiate priorities, mentor engineers, document decisions, and make the whole team more capable.

Less effort will go into translating an understood solution into syntax, and more into deciding what should exist and taking responsibility for it.

Copy linkCloud did not replace operations

We have seen a version of this transition before.

Cloud computing did not abolish operations. It made provisioning cheap and turned architecture, reliability, security, and cost control into more consequential parts of the job. It shrank some roles, created others, automated a costly middle, and introduced new ways to fail.

AI may do something similar to software engineering. It is automating a large part of the build layer, changing the shape of teams, and moving the scarce decisions elsewhere.

So, will AI replace software engineers?

It will replace a great deal of what software engineers currently do. If we keep defining engineering as code production, the answer is increasingly yes. If we mean the full work of deciding, designing, verifying, operating, and evolving, the centre of gravity is moving rather than disappearing.

AI replaces software engineering the way cloud replaced operations: it renames the work, automates the middle, and raises both our leverage and our accountability.