AI Is Removing the Middle of Software Engineering

Last month I gave Claude Code a precise instruction: build the export layer for Labwor Fleet King, the fleet telematics system I am building, so a fuel efficiency report can come out as CSV, XLSX and PDF without pulling in a third-party reporting library. It produced a working first version in about twenty minutes. Reviewing it, fixing the number formatting, and making sure a long asset name did not silently truncate in the PDF took me two days.

That ratio is the honest state of this profession. Writing code has become close to free. Knowing whether the code is right has not moved at all.

The part that actually got cheaper

I entered tech in June 2023. I remember exactly what the first eighteen months cost me. Learning the shape of a Spring Boot module. Learning why a React component re-rendered when I did not expect it to. Learning the difference between a migration that can be reversed and one that is a door closing behind you. A great deal of that time was not thinking. It was looking things up and typing.

That part is gone, and I do not miss it. Copilot finishes the line I had already decided to write. Claude Code writes the migration, the data transfer object, the test scaffold, the small utility I have written eleven times in other projects. When I need a library I have never touched, I no longer read the documentation end to end. I ask, I read, I check the answer against the real documentation, then I move.

I want to state the consequence plainly, because there is a lot of comfortable talk in the industry that avoids it. If your value to a team was that you could reliably turn a clear ticket into working code, that value has dropped. Translation work, taking a specification somebody else wrote and rendering it in syntax a compiler accepts, is exactly what these tools do best.

The part that did not get cheaper

Generation is now parallel. I can have an agent working on the reporting module while I read something else. Comprehension is still one human brain, reading one line after another, at the same speed as in 2023.

The same task on Labwor Fleet King: about twenty minutes to generate, two days to review.

That asymmetry is the real change, and it is more dangerous than the job-loss headlines suggest. Bad decisions used to be slow. An inexperienced developer needed a month to build something structurally wrong, and in that month somebody usually noticed. Now the same person can produce a thousand lines of plausible, working code that is structurally wrong before lunch, and the reviewer has to hold all of it in their head to see the problem.

Fleet King has a fuel drain detector. It watches tank level telemetry from GPS devices and decides whether a drop is a theft or a normal burn. Ask a model to write a tank-balance function and you will get one, and it will look correct. What the model does not know is that drivers on the northern corridor siphon at a stop with the ignition off, that a rough road produces a level reading that looks exactly like a small theft, and that a refuel and a drain can look identical in the data if you trust a single reading. I learned all of that by pointing the detector at a live Traccar instance and watching it be wrong.

There is a second thing the tools do not catch, and it frightens me more. When I audited an earlier prototype of that same system, I found that critical fuel-theft alerts rendered identically to informational notices. Same colour, same weight, same shape. Nothing was broken. Every test passed. An agent reviewing that code would have found nothing to report, because the defect was not in the code, it was in what the code meant to the person reading the screen at six in the morning.

Why it is the middle that goes

Put those two facts together and you get an uncomfortable shape. Cheap generation raises the value of anyone who can judge output, because judgement is now the bottleneck. It also raises the value of anyone learning, because a beginner with a patient tutor learns faster than I did. What it hollows out is the seat in between: the competent implementer who was paid to produce code from someone else’s decisions.

This matters more in Kampala than in San Francisco, and we should say so. The outsourced implementation seat is the job most Ugandan graduates have been quietly trained to want. Take a spec from a client abroad, build it, deliver it, invoice. That was the on-ramp to a global salary. It is the exact seat that is now cheapest to replace.

There is a version of this argument that ends in despair, and I do not accept it. The implementation seat was never a good deal anyway. It paid in foreign currency and it taught you almost nothing about why the software existed. What it did give people was a first job, and that is the loss worth taking seriously: the rung that used to carry a Ugandan graduate from a bootcamp certificate into paid practice has been sawn off, and nobody has replaced it yet.

I do not think this means fewer engineers. I think it means the profession stops paying for typing and starts paying for two things: deciding what should be built, and standing behind what was built.

How I actually work with these tools

My practice has settled into something fairly boring, which I take as a good sign.

Before I ask for anything, I write the acceptance condition in plain English, usually as a test or a line in a task file. If I cannot state how I will know the result is correct, I do not delegate it, because I will not be able to review it either.

I keep a list of code the agents do not touch without me reading every line. Anything handling money, because Fleet King stores money as integer minor units with a currency code and one careless float would corrupt a customer’s bill. Anything touching tenant isolation, because that database has row-level security and exactly one sanctioned cross-tenant read. Anything that decides what a user sees when something has gone wrong.

I use Copilot and Claude Code for different things. Copilot is for the line I have already composed in my head. Claude Code is for a slice I can describe precisely and check cheaply: a migration, a parser, a report, a set of tests around behaviour I have already specified. When a task is vague, the output is confident and useless, and I have learned to read my own vagueness in the shape of what comes back.

I also read the diff before I read the summary. The agent’s own account of what it did is written to be reassuring, and it usually is accurate, and the one time in ten that it is not is the time that costs you a weekend. Reading the diff first takes ninety seconds and has caught a deleted guard clause, a quietly widened database query and a test that was passing because it asserted nothing.

The place I stopped using generation altogether is Acholi. I run a translation pipeline over Sunbird AI’s Sunflower model for a hymnal and a devotional app. The model drafts. I read every line, because a word can be technically correct and still unsingable, and no test will tell me that.

What to learn if you are starting now

If I were nineteen and starting in Kampala this month, I would spend my time on five things, and only five.

• Read code you did not write, on purpose, until you can explain a module to another person without looking at it.
• Learn one domain properly: patient records, cooperative accounting, school assessment, logistics. Domain knowledge is the thing prompts cannot supply.
• Learn to verify. Tests, migrations, logs, a debugger, a real device. Verification is now the scarce skill, not production.
• Sit with the person who will use the software. Ask what they do when the system is down.
• Write. In English, in your own words, about what you decided and why.

Notice that only one of those is about writing code. That is deliberate.

The five, and the single one of them that is about writing code.

What I would tell myself in June 2023

I would not tell myself to learn faster. I would tell myself that the years I spent surveying roads before I ever touched a keyboard, setting out design data on site and then watching the contractor build something slightly different, were not a detour. They were the training. Somebody has to stand at the edge of the work, look at what was actually produced, and say whether it is right. The machines have taken the shovel. They have not taken the responsibility, and I do not believe they are going to.