The anxious version of this conversation asks whether senior engineers still matter when a model can produce a working service in an afternoon. It is the wrong question, and you can see why by looking at what senior engineers were actually being paid for.
Very little of it was typing. A capable senior engineer's day is mostly spent on decisions: whether this belongs in that service, what happens when the third-party API is down for six hours, whether the thing being asked for is the thing that is needed, which of two ugly options is less ugly in three years, and — most valuably and least visibly — talking someone out of building something.
None of that got cheaper. What got cheaper was the part that came after the decision.
Judgement, concretely
"Engineering judgement" is one of those phrases that sounds like a compliment and communicates nothing. It is worth being specific, because the specifics are what makes the case.
Judgement is knowing that a feature which works perfectly for the five records in the demo will behave completely differently at fifty thousand, and knowing roughly where the break will be. It is looking at a design and asking what happens when this call times out — and knowing from experience that the answer "it won't" is wrong. It is recognising that a proposed integration creates a dependency between two teams that will produce a coordination problem long before it produces a technical one.
It is also, frequently, restraint. The most valuable thing a senior person does in a week is often to establish that a requested feature would create an obligation the organisation cannot afford to maintain, and to say so before anyone builds it. That has never been easy to justify on a timesheet, and it becomes considerably more valuable when building the unnecessary thing takes an afternoon instead of a month — because the low cost of building removes the natural friction that used to stop bad ideas.
The gates, and the questions they ask
The governance chain in most organisations is written down as a list of reviews. Written that way it reads as bureaucracy. Written as the question each review actually asks, it reads as a list of ways to lose money.
Look at what these questions have in common: not one of them is about whether the code works. That was settled before the chain started, and it is the part AI has made dramatically cheaper. Each gate is a judgement call, and each requires somebody who can be wrong about it.
This is also why "the AI will handle governance too" does not follow. A model can draft a threat assessment; it cannot be the party that accepted the residual risk. A model can generate the compliance documentation; it cannot be the person the regulator asks. The bottom gate in that chain is deliberately blunt — a named person accepts the risk. Not a committee, not a process, a person — because that is the only formulation that survives contact with an actual incident.
The invoice approval example
A concrete case, because the abstraction gets slippery. Someone in finance builds an invoice approval workflow with AI. It handles the five invoices they tested it on flawlessly. Everyone is pleased.
To make it the organisation's actual approval mechanism, the following have to exist, and none of them are visible in the demo:
- Role-based access, because approving an invoice and raising one must not be the same person's ability
- Delegation, because approvers take leave, and the alternative is a two-week payment freeze every December
- Exception handling, because the invoice that does not match the purchase order is the entire reason the control exists
- Fraud controls, because an approval workflow is a fraud target the moment it becomes the official route
- An audit trail, because "who approved this and on what basis" is the first question in any dispute
- Integration with the finance system, because a workflow that requires manual re-keying will be bypassed within a month
- Reconciliation, because a system that silently drops one invoice in two hundred is worse than no system
That is not a list of things the original builder did wrong. It is a list of what an approval control is, as distinct from a tool that approves things. The distinction is invisible until you have watched one fail.
The role moves, and it moves upward
The practical consequence for senior engineers and architects is that the work shifts from producing features to creating the conditions under which many features can be produced safely. Less writing the authentication code, more deciding what authentication looks like everywhere and making that the path of least resistance. Less reviewing every change, more designing which changes need review at all.
This is a harder job, not an easier one. Reviewing a pull request is bounded work with a clear finish line. Designing a set of defaults that will hold across two hundred future changes made by people you will never meet — some of them agents — requires you to be right about things you cannot yet see. It is closer to what architecture was always supposed to mean, and further from what it usually degenerated into.
It also has an uncomfortable implication for how organisations develop people. The traditional path to judgement ran through years of writing mediocre code, breaking things and living with the consequences. If juniors now generate working code from day one, the experience that produced judgement does not accumulate the same way. Nobody has fully solved this. The teams handling it best seem to be the ones that deliberately have people debug and operate systems rather than only build them — because judgement comes from the debugging far more than from the building.
We have written separately about the architecture mistakes that recur most often and about why cheap code changes the technical debt calculation.
What this means for hiring and structure
Three practical consequences, stated plainly.
The value of a mid-level engineer who is fast at producing code has genuinely fallen. The value of one who is good at reading code critically and spotting what is subtly wrong has risen, because that is now the constraint.
Review capacity is your bottleneck. Structure teams around it. A team of eight producing at the volume of eighteen with two people capable of serious review is not a fast team; it is a queue with a nice tooling story.
Write down the decisions. When change is cheap and frequent, the reasoning behind an architecture is what stops it being eroded one plausible-looking change at a time. Architecture decision records were always a good idea and were always the first thing dropped. They are now closer to load-bearing.
How CloudNala can help
We are frequently brought in as the review layer an organisation does not yet have — architecture and security review on AI-assisted builds, production-readiness assessment before something becomes business-critical, and design of the gate chain itself so that it is proportionate rather than ceremonial. The aim is always to make the chain shorter and sharper rather than longer: fewer gates, each one asking a question that genuinely changes the decision.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za