I still open the editor. I still know what's in the repo. But the actual typing of functions, the thing I've done for years and the thing I'd call my job if you asked me at a party — that mostly doesn't happen now. An agent does it, and I tell it what to do.

I want to be careful here, because "I don't write code" and "I don't read code" both sound like I've stopped paying attention. I haven't. What changed is when I look and how much. I don't watch lines appear. I look at the result, at checkpoints, and how hard I look depends on how big the change was.

I do miss it. Writing code was the part of the day I didn't have to motivate myself for. That's gone and I haven't fully made peace with it.

What replaced it is harder to name. I used to say developer, then architect. Now I'm something closer to a product builder who knows the technical side deeply. That sounded like a demotion to me for a while. It isn't one. The code was never the scarce part — knowing what to build and what breaks if you build it the obvious way was always the hard bit, it was just hidden behind the hours of typing.

What follows: what the work looks like now, why my engineering background is the reason it works at all, where agents fall apart on real projects in ways you won't see in week one, the practices I use, and what I think this does to people trying to get into the field. That last part isn't cheerful.

The job, roughly

Decide what to build. Describe it well enough that something else can build it. Check that what came back is what you meant.

The describing is where people lose time. A vague instruction doesn't get you a vague result — it gets you a confident, complete, well-formatted result that solves a slightly different problem than the one you had. Then you spend an hour finding the wrong part, and it's usually an assumption made in the first thirty seconds that you never saw happen.

So I say more upfront than feels natural. What the feature does, what it shouldn't do, which existing code it should reuse, what happens when it fails, what the result should look like for a user and for the next developer. It feels like over-explaining. Every constraint you skip is a decision you handed over without noticing.

Verification. Tests first — they're free. Then I run it and use it myself, because passing tests and a working feature are not the same claim. Then I read the diff. If the diff is big enough that I know I'll skim it, and that happens, I give it to a second agent with specific instructions on what to look for. Not "review this." That gets you a summary of what the code does, which I already know.

The second-agent thing is less a technique than an admission. The change got too big to hold in my head, so I spend another agent's attention to buy back some of mine.

Why any of this works

There's a line going around that anyone can build software now. It's half true in a way that matters. Anyone can get code out of an agent. Getting a system out of one is different.

The things I tell an agent before it writes anything are things I only know to say because of years of watching software rot. Not "follow DRY" — that's a label, and it'll agree with you and then duplicate the same function across five files anyway. What works is telling it where I expect duplication to show up and why it'll hurt: this validation logic is going to get called from the API layer and the background job and eventually the admin panel, so it lives in one place and the three callers import it.

Same with structure. I don't say "use MVC." I say what goes in which layer, what's allowed to import what, and where the boundary is that I don't want crossed even when crossing it would be convenient. An agent has no opinion about that boundary. It'll cross it the moment crossing it is the shortest path, and it won't mention that it did.

And contracts. What this module promises, what it accepts, what it returns when things go wrong. If I don't define that, the agent invents one per call site, and they'll be subtly different from each other in ways I find three weeks later.

None of that is coding skill. It's knowing what tends to go wrong, which comes from having been there when it went wrong. That's the part the degree and the years actually bought me, and it turns out it's the part that survived.

Where it breaks

Week one of a new project with an agent is the best week of software development I've ever had. Things appear. Features that would have taken me two days take twenty minutes. If you've only done that part, you understand why people are making big claims.

Week four is different, and the reason is boring: agents add.

On a side project of mine I'd been moving fast for weeks, mostly trusting the output, reviewing lightly because everything worked. Then I went to change something by hand and couldn't find where it lived. Not because the code was hidden, but because it lived in four places. The same logic, written four times, slightly differently each time, because each time the agent needed it, it wrote it fresh instead of looking for what already existed.

That's the whole failure mode. It doesn't survey the codebase and ask what's already here. It solves the problem in front of it, and solving it locally is always easier than finding the existing abstraction and adapting it. Every individual decision was reasonable. The pile they made was not.

The cost of that arrives late, which is what makes it dangerous. Duplication is free until the day you need to change the thing that got duplicated. Then every edit is a search, and every search has to account for side effects in places you'd forgotten existed, and the agent can't help you much because it never had the whole picture either. That's the point where I stopped and did a full audit of the codebase — looking specifically for repeated patterns, for logic that should have been generalized and wasn't, for the places where "just add another case" had been the answer six times in a row.

It doesn't know when to refactor. It knows how, if you ask. It'll do a good job. But it will never volunteer, because adding always works and refactoring is a judgment call about the future, and it doesn't have a view of the future. You do. That's your job now.

What I do differently

I think before there's a repo. This is the biggest change and the least fun one. I used to start with a boilerplate and figure things out as they came up, because refactoring early code is cheap when you're the one writing it. That doesn't hold anymore. Early structure is what the agent will keep imitating for the entire life of the project, so a bad early decision compounds much faster than it used to.

So before anything gets generated I work out: what the structure is and why, monolith or services and what that implies, what the layers are and what's allowed to depend on what, which parts are load-bearing and which are throwaway, what the contracts are between the pieces, and roughly where I expect this thing to be in six months. Some of that is guessing. Guessing on paper is still better than the agent guessing in the code.

Principles with reasons, not names. "Follow DRY, KISS, SOLID" is worth nothing. Those words are in every codebase's README including the terrible ones. What works is the specific version: here's the duplication I expect, here's why it will hurt, here's what I want instead. An agent can act on that. It can't act on a slogan.

The documents live in the repo. PRDs, architecture decisions, the conventions list — in the codebase, not in a chat window and not in a wiki nobody opens. The point is that they're reference material the agent reads as part of the work rather than context I have to re-explain every session. Chat history evaporates. Files don't. And the side benefit is that writing them forces me to have actually decided, instead of thinking I've decided.

Verification scaled to the change. Covered this above: tests, hands on it, diff, second agent if the diff is too big. The only thing I'd add is that the ladder is real and I do use all of it, but the honest failure mode is that on a good day, when everything's passing and I want to keep moving, I skip a rung. Everyone does. Knowing which rung you skipped is the difference between a risk and a surprise.

What I don't hand over

Anything where being wrong is expensive and quiet. Data migrations, permission logic, anything touching money. Not because an agent can't write them — it writes them fine — but because the failure mode is silent and the blast radius is large, and "the tests passed" is not the standard I want for a thing that can corrupt production data at 3am. I still use agents there. I read every line of that output.

The other one is the initial shape of a system. Not because it can't propose one, but because if I don't own that decision I spend the rest of the project living inside someone else's guess.

More output, less focus

Here's an effect I didn't expect. I'm considerably more productive, which means I can carry more work, which means I do. Three or four things in flight where it used to be one. And each of them has stretches where I'm waiting on an agent, which is exactly the gap that tempts you to go look at another one.

The result is that context switching has become the dominant cost of my day. Not typing speed, not build times. My attention. Every switch costs me the mental model I'd loaded up, and reloading it takes longer than I want to admit.

I don't have this solved. What helps a bit: fewer things in flight than I'm technically capable of running, and treating agent wait time as thinking time for the same task rather than an opening to start another. The tooling made throughput cheap. It made concentration expensive, and nobody warned me about the trade.

Juniors

This is the part I've been avoiding.

Companies don't need people who can code. That's what the last three years actually changed. What they need is people who understand the product, the users, and what the business is trying to do — and who can turn that understanding into something that works technically. That skill was always the valuable one. It was just bundled with coding, and you got it by doing the coding for a decade.

The bundle came apart. Coding no longer differentiates anybody, and the gap between a junior and a senior on writing code is close to gone. That sounds like good news for juniors and it isn't. The gap didn't close because juniors got better. It closed because that skill stopped being the one that's scored. What's scored now is judgment, and juniors don't have it, and the path they used to walk to get it — small well-defined tasks, done badly, then done better — is exactly the work that's now handed to an agent.

I don't know what I'd tell someone starting today. Build things end to end, probably, so you accumulate the experience of your own decisions failing, since that's where judgment comes from and there's no shortcut I know of. Get close to users early. Don't spend your first two years being a faster typist than the machine. But I'm aware that's advice from someone who got in before the ladder was pulled up, and I'd be suspicious of me if I were you.

On tools, briefly

I've tried a lot of them. Claude, Codex, Hermes with Qwen, Gemma running locally through LM Studio, others. They differ in ways that feel important for about a week.

What actually separates them is how efficiently they turn what you need into what you get. That's it. Right now Claude does that best for me and it's what I use daily. That sentence has a shelf life of maybe a quarter, which is the point — the tool matters much less than whether you know what to ask it for. People switching tools looking for the one that finally works are usually solving the wrong problem.

Where this leaves me

I still miss writing code. I've decided that's allowed and it doesn't have to mean anything.

What I do now is harder to describe at a party and more valuable than what I did before. I think about the product more, about users more, about what should exist and why. The engineering knowledge didn't become obsolete — it moved. It's the thing that lets me tell an agent something useful, and the thing that lets me notice when what came back is quietly wrong.

The people who do well at this won't be the ones with the best prompts. They'll be the ones who can take an idea and turn it into a product that works, in the full sense — solves the right problem, holds up technically, doesn't collapse in month six. Agents write code. They don't have a view about what should be built. That's still ours, and I don't see it moving.