The agent writes the code. I'm paid for the rest.

I don't type much code any more. Over the past year I rebuilt AEGIS, my own operations layer, into its third version, kept the Ansaar data platform running every night, and shipped most of the Hikmah Technologies site. Claude Code wrote most of the lines. Work I would once have planned in weeks now fits in days.

So where do my hours go? Almost none of them go on writing code. They go on three things:

1. Finding out what the person actually means.
2. Deciding what a correct result looks like.
3. Checking what got built against the real world.

That is the job now. The agent handles the part in the middle.

The code was the easy part all along

For most of my career it didn't feel that way, because writing code was slow and took up the day. Whoever could write it was the expensive person in the room, and every other role was arranged around them.

Now a clear description turns into working code in minutes. Agents are also getting steadily better at the work after that: reviewing, fixing bugs, deploying. I expect them to get most of the way there. What I don't expect them to get is the description itself.

The knowledge isn't written down

Take a simple request: "we need a way to track our leads."

Hundreds of products fit that sentence. The right one for a property brokerage is not the right one for a software company. At a brokerage, the lead may be a family, not a person. The same buyer calls in through three channels. A site visit matters more than an email open. The rules about who "owns" a lead can decide whether the partners stay friends. Usually none of that is written down. The owner carries it in their head and would struggle to list it if you asked directly.

No model has seen it, because it has never been written anywhere. Someone has to sit with the business, pull it out piece by piece, and turn it into something exact enough to build. Then they have to show the result and hear "no, not like that", because the first version is always wrong in a way nobody could have predicted.

This also does not carry over from one client to the next. What "correct" means for one brokerage's leads is not quite what it means for the next. That is why off-the-shelf software grows a hundred settings and still doesn't fit. Cheap code makes it possible to build the version that does fit, but only if somebody has done the finding out.

Green tests, wrong numbers

The second job, deciding what correct looks like, is the one I underrated.

Here are three bugs from my own systems this year. The code was clean, the tests passed and the reviews were fine for all three.

• A zero that meant "missing". A crypto market table stored the Fear & Greed Index, a number from 1 to 100. On four days with no reading, it stored 0: the most fearful market possible. A unit test asserted exactly that value. The bug was locked in by a passing test.
• A job that did nothing and said it worked. After a schedule change, the nightly equity forecast ran one minute before its input data landed. It found nothing, wrote zero forecasts and reported success. It stayed green for days.
• A year that wasn't a year. A 365-day performance figure counted 365 rows, not 365 days. Some weeks had no rows, so the window stretched back about 500 days and showed a positive number for a year that had actually lost money.

An agent reading the diff would have approved every one of them. So would I, if all I had was the diff. They were caught only by knowing what the answer should be and checking against something independent: a known date, a hand count, a second source.

That knowledge doesn't come from the code. It comes from understanding what the numbers are for.

What this means if you are buying

If you are hiring someone to build software or a data platform, the typing is now the cheap part. Don't pay a premium for it.

Pay for the other two jobs. That is how I have set up my own work:

• The Data Platform Audit is a week spent learning how your business uses its data before anything is built. What comes out is a written definition of what correct and done mean for you, plus a ranked fix list.
• My free checklists, the data platform teardown and the AI workflow teardown, contain no code at all. They are questions: who can stop this, what happens when it is wrong, what does it really cost. Those questions decide whether a system is any good, and an agent won't ask them for you.

The usual alternative is a $150–200k senior hire. That is still the right call if you have a full week of this work every week. But judge candidates on whether they can do the understanding, not on how fast they build. Fast building is now available to everyone.

What this means if you are starting out

I learned judgment the slow way. I wrote code, someone senior tore it apart, and after enough years I had absorbed what they knew. Agents now do the first half of that loop, and they are starting on the second. I don't know what replaces it, and I think that is the real problem the industry has to solve.

If you are early in your career, my advice is to get close to the people who use what you build. Sit with them. Watch them work. Learn to say back to them what they need, better than they could say it. Practise checking your results against something you already know is true. The agent will write the code. Knowing what it should say is the part that stays yours.

The best moment in programming was always the one just before you started typing, when a messy problem suddenly took a clear shape. That moment used to be a small part of the day. Now it is most of the job.