AI writes code now. That is settled. What changes is where the value sits. The routine work of producing functions and boilerplate is being absorbed by machines, and the human job is moving up: deciding what to build, how the pieces fit, and whether the output is actually correct. Coder to architect.
This article puts numbers on both halves of that claim: where AI genuinely accelerates software work, where it quietly makes things worse, how everyday development tasks now divide between person and machine, and what to ask anyone who builds software for you.
What a software architect decides
A software architect is the person who decides the structure of a system: how it is split into parts, how those parts talk, where the data lives, what fails safely, and which trade-offs are worth making. That role used to sit above the day-to-day typing. Now the typing is the part machines do best, and the architecture is the part that still needs a human.
Architecture is judgement under constraints. It means choosing boundaries, naming trade-offs, and deciding what to keep simple and what to make flexible. A model can generate a thousand lines toward a bad design and never notice the design is bad. It has no stake in the outcome and no memory of why the last approach failed. Systems thinking is the discipline underneath the title: seeing how a change to billing touches reporting, how a new integration affects load, how a "small" feature creates a support burden later. AI can answer a narrow question well. It cannot hold the whole business in its head and tell you which narrow questions are the right ones. That framing decision, the build-versus-buy call, the choice of a custom solution over off-the-shelf software, sits with the architect.
What AI genuinely does well
Let me be concrete about the wins, because they are real. In a controlled experiment run by GitHub, 95 professional developers were split into two groups and asked to write an HTTP server in JavaScript. The group using Copilot finished 55% faster, averaging 1 hour 11 minutes against 2 hours 41 minutes, a statistically significant result. That is what AI code generation is good at: well-specified, greenfield, boilerplate-heavy work where the answer is fairly standard and the developer can check it at a glance.
Most developers agree. The 2025 Stack Overflow Developer Survey found 84% of developers are using or planning to use AI tools, up from 76% the year before, and 51% of professional developers use them every day. The tools draft the first version, fill in the obvious patterns, and turn a blank file into something you can react to. For a large language model trained on a vast amount of public code, predicting the next plausible line is exactly the task it was built for.
In our work building for small businesses, this matters most at the start. The early scaffolding of a project, the throwaway prototype, the standard screens for entering and editing data: these now take a fraction of the time they did. That speed is real and we use it every day. It is why we can take a client from idea to a working MVP faster than we could three years ago.
The pattern behind every win is the same. The task is bounded, the correct answer is conventional, and a person can verify the result in seconds. Write a form validator. Convert this data into that format. Generate the API client from a schema. Those conditions describe a large share of any working day, which is why the tools feel indispensable within a week of adopting them.
Felt speed is not measured speed
Now the misconception, and it is held by developers and their clients alike: that you can tell whether AI is helping by how the work feels. Fast-feeling tools must be making the project faster.
The best evidence available says feel and fact come apart. A 2025 randomised controlled trial by METR put 16 experienced open-source developers to work on 246 real issues in their own mature repositories. Allowing AI tools made them 19% slower. Not faster. Slower. The same developers had expected AI to speed them up by 24%, and even after finishing, they still believed it had sped them up by 20%. They were wrong about their own productivity, in the direction that flattered the tool.
The mechanism is visible in the frustration data. On a complex system with deep context, the AI proposes code that looks right, the developer accepts it, then spends the saved time untangling what it got subtly wrong. The single biggest frustration in the Stack Overflow survey, cited by 66% of developers, is "AI solutions that are almost right, but not quite," and 45.2% say debugging AI-generated code takes more time, not less. Trust reflects the experience: only 3.1% of developers say they highly trust the accuracy of AI output, 45.7% actively distrust it, and the top reason for turning to another person, given by 75.3%, is "when I don't trust AI's answers."
The correct model: the machine is a fast junior who never says "I'm not sure." It produces a confident hallucination in the same tone as a correct answer. Reading its work, and knowing where it tends to invent, is now a core technical skill. That is why human review stays in the loop on anything we ship, and why the only honest answer to "is AI helping?" is a measured one: cycle times and defect rates, not the feeling of speed.
The same tasks, split differently
The clearest way to see the role change is to look at ordinary tasks and where the human effort now goes. On our builds, the division looks like this.
| Task | The model's share | The human's share |
|---|---|---|
| Contact or booking form | Drafts the markup, validation, and wiring | Reviews it, checks failure behaviour, ships it |
| API client from a documented schema | Generates the whole client | Verifies it against the schema and the error cases |
| One-off data conversion | Writes the script | Spot-checks output against source records |
| Payments and permissions logic | Fills in code to a written design | Designs the flow, writes the tests, reviews line by line |
| System architecture | Offers options when asked | Decides, and owns the consequences |
Notice what moved. The typing went to the machine. The specification, the verification, and the accountability stayed human, and grew, because there is more output to check than before.
Directing the machine well is its own craft, closer to managing a capable, literal-minded contractor than to writing code by hand. The first half is description. Prompt engineering is the surface layer: stating the task, the constraints, and the shape of the answer you want. The deeper layer is context engineering: giving the model the right surrounding information at the right moment, the existing patterns in the codebase, the data structures, the rules it must respect. Feed it the wrong context and it confidently builds the wrong thing.
The second half is delegation, and here is our standing verdict. Let the model draft anything bounded, conventional, and cheap to verify. Keep anything that touches money, permissions, private data, or an irreversible step under human design and line-by-line review. When a task sits between the two, the deciding question is how quickly a person can tell whether the output is wrong. As the tools grow into agentic systems that take multiple steps on their own, this judgement about what to delegate, and what never to delegate, becomes the central part of the job.
Faster developers do not mean faster delivery
Here is the trap businesses fall into. They see the individual speed-up and assume the whole pipeline gets faster. It does not work that way.
Google's 2024 DORA report measured this across thousands of professionals. A 25% increase in AI adoption was associated with real individual gains: documentation quality up 7.5%, code quality up 3.4%, code review speed up 3.1%. Good news. In the same breath, that adoption was associated with an estimated 1.5% drop in software delivery throughput and a 7.2% drop in delivery stability. More code, shipped less reliably.
DORA's conclusion is the sentence every owner should tape to the wall: improving the development process does not automatically improve software delivery, and "AI does not appear to be a panacea." It only pays off with the basics in place: small batches and strong testing. If you let AI raise the volume of code without raising the rigour around it, you have built a faster way to ship bugs. The architecture, the testing, and the review process are what turn raw output into working software, and they are exactly where measuring AI return on investment gets honest.
Will AI replace software engineers?
Short answer: no, but it will change who counts as one. The work that is purely typing known patterns is being automated, and roles defined only by that work are exposed. The work that is judgement, AI code review, architecture, and understanding the business is becoming more valuable, not less.
The Australian labour market is starting to show the shift. In 2025, Jobs and Skills Australia removed "software engineer" from its national shortage list for the first time since the study began in 2021, while higher-specialisation roles such as cybersecurity engineers and software testers stayed in shortage. The report noted the easing is "consistent with various sectors in the labour market that are integrating artificial intelligence technology". Read it carefully: this is correlation, not proven cause. But the pattern fits. Demand for generic coding is cooling. Demand for judgement and specialism is not.
The developers who thrive will direct AI rather than compete with it. They will write the spec, set the constraints, generate a draft, then bring the part a model cannot: taste, scepticism, and accountability for the result. There is a deeper point about what AI cannot do. It has no genuine model of your customers, no stake in your reputation, and no way to know whether the thing it built was worth building. It produces fluent output regardless of whether the output is right. Closing that gap is human work, and it pays.
Three questions to ask whoever builds your software
You do not need to read code to judge whether a developer or agency uses AI with discipline. Ask these three questions and listen to the shape of the answers.
- 1.Ask where they use AI in a build, and where they refuse to. A disciplined team answers in seconds and names both sides: generation for scaffolding and standard screens, humans for money, permissions, and data migrations. Be wary of "everywhere," and equally wary of "nowhere."
- 2.Ask what happens to AI-written code before it ships. The answer you want involves human review and automated tests, plus a named person accountable for the result. "The model checks its own work" is the wrong answer.
- 3.Ask how they know AI is actually helping. The strong answer points to delivery measures such as cycle time and defect rates. The weak answer is that it feels faster, and the METR result above is the reason that answer should worry you.
Ten minutes of answers will tell you whether you are hiring an architect who directs the tool or a typist who trusts it.
The Enki Approach
We treat AI as a tool that makes good developers faster, never as a replacement for thinking. On every build, the same order holds: understand the problem first through proper discovery, decide the architecture, then let AI accelerate the parts it is genuinely good at, under review.
We measure outcomes, not vibes, because the METR finding proved people misjudge their own AI-assisted speed by a wide margin. We keep a human in the loop on anything that touches real users or real data. And we plan the build before we generate a line of it, so the speed of AI works for the design instead of against it. You can read how we structure that in planning AI builds.
The role is moving from coder to architect. For us that is not a threat. It is a description of the job we already do.