I asked an agent to help me plan this post. It read one file out of thirteen, then came back with four confident questions about material I had already written and stored in the same repository, about six feet from where it had been looking.
I didn't answer the questions. I asked whether it had read my previous posts or my drafts, and told it that this was one of the weaknesses, live. It went and read them, and then answered its own questions out of my own writing, better than I would have.
That exchange is the whole post. The agent moved confidently on context it never bothered to gather. I corrected it in one line, by pointing at the material rather than going and getting it myself.
I have been on both sides of that exchange.
The Post Everyone Is Writing
There is a genre going around right now. A developer who clearly cares about the craft writes an honest piece about why they are done using AI at work. Sometimes it is a video. The specifics move around, the shape does not, and I want to state it in good faith, because the description is accurate.
It runs roughly like this. I have been turned into a code reviewer and a QA tester for a machine. It agrees with everything I say, so I can't trust it to push back on me. It ignores half of what I told it and builds something I didn't ask for. Nobody can actually review that much code, so the review is theater. And I don't know my own codebase anymore, because I didn't write any of it.
I believe all of it. Every one of those is a true description of what their week now looks like. The experience is not what I want to argue with. The diagnosis is.
That Is What Being a Lead Feels Like
Read that list again with the machine taken out of it.
I can't review everything they write. They agree with whatever I suggest in planning. They nod in the design review and then build something we never discussed. I don't know the code anymore, because other people write most of it now. And most of my day is reviewing and unblocking instead of building.
That is a first-time lead, about six months in, describing their team. I have said versions of all of that out loud. Every lead I know has. Nobody hears it and concludes that teams don't work, or that hiring was a mistake, or that the industry has been ruined. We understand that leading is a skill, that few people are born holding it, and that the first months of it feel exactly like being demoted into paperwork.
The complaints are real. They are just not complaints about AI.
An agent is not a junior. That difference matters, and I come back to it.
The Part Where They Are Right
I want to be careful here, because there is a version of this argument that is smug and useless, and it goes "skill issue" and walks off. The people writing these posts are smart, and some of them are probably better engineers than me.
Leading is genuinely a different job. It is not the job those people signed up for, and it is not strictly better than the one it replaced. Plenty of excellent engineers take the promotion, discover they hate it, and go back to building, and that is a legitimate choice made by people who know themselves.
What is not legitimate is what happened to the developers writing these posts: nobody offered them the promotion. The tooling arrived, the job quietly changed shape underneath them, and they were expected to be good at the new one immediately, with no training and no say. That is a real grievance. It is just pointed at the tool instead of at the people who restructured the work.
I can't fix how the job was handed to you. What follows is the part that is in your hands.
The other arguments in those posts, about training data and about what the data centers cost, are separate and legitimate, and they deserve their own hearing. This post is not about them.
Four complaints, and the lead habit that answers each one. I learned all four habits managing people, before any of this.
Don't Vote First
It agrees with everything I say.
When my team sizes tickets, I abstain. I don't put a number in.
The reason is that my number is not one opinion among several, it is the anchor. If I say "this is probably a three" and then ask the room, the room lands on three. Not because they agree, but because disagreeing with the lead's number is a small tax that most people, most days, will just pay. What I get back is my own estimate with more steps and a false sense of consensus around it.
So instead of a number I give them a way to find their own. The one that works best for me is buckets. One, two, three, five, eight. You are not measuring the work, you are choosing a container for it, and four litres of work goes in the five litre bucket, not the three. That framing kills the argument about whether something is "really" a four.
The other tool is a grid. Effort on one axis, uncertainty on the other. Bottom left is small and you have done it a hundred times, that is a one. Top right is large and nobody in the room has done it before, that is a twenty-one. Everything else sits somewhere between the two corners. The team places the ticket, the number falls out of where they placed it, and I never had to say anything.
Now the agent. It agrees with you because you keep putting the answer inside the question. "This is a race condition, right?" gets you a race condition. "Should I use a queue here?" gets you a queue, plus three paragraphs about why your instinct was excellent. You asked a targeted question and the agent anchored on it.
Ask what would make this fail. Ask it to argue the other side and mean it. Ask for the two approaches you did not think of before you tell it the one you like. When it agrees with something you were already leaning toward, that agreement carries almost no information, and treating it as confirmation is an expensive habit. Abstain from voting first, exactly the way you would in a planning session.
Make It Say It Back
It forgets what we agreed and builds the wrong thing.
The architecture walkthrough is where I learned this one. I present the design, I ask if it makes sense, and everyone nods. No questions. Great session.
The feedback arrives three days later, when someone has built half of it in a direction we did not discuss. The nod was never agreement. It was the absence of processing. People cannot evaluate a design at the speed you can narrate one, and "does that make sense?" is a question whose only comfortable answer is yes.
So I stop and I ask someone to say it back to me, on the spot. Not a summary of the slides. Walk me through what you are going to build tomorrow morning. The gap between what I said and what comes back is the entire value of the meeting, and it shows up in about forty seconds instead of three days. The same thing happens with tickets: whatever we agreed in planning has evaporated by the time someone opens the editor, unless they had to reproduce it in their own words while I was still in the room.
The agent fails this identically, and worse, because the forgetting compounds. A constraint you set ten messages ago goes quiet, then comes back misremembered, and everything downstream of it inherits the wrong premise while the confidence stays pinned at a hundred percent the entire way down.
The fix is the same fix. Get the plan before the code. Make it restate the constraints and the boundaries in its own words before it touches a file, and read that restatement as the real signal, because where the restatement drifts is where the work was about to drift. Then re-establish the boundary the moment you see it slipping, because it will slip, and it will not tell you.
The other half of this habit is the size of what you hand over. A lead who drops a vague twelve-part ticket on a junior and gets vague work back did that to themselves. I found the same line measuring extraction pipelines: asking for twelve fields in one call is worse than asking for three fields four times, because accuracy falls off as the thing you are asking for gets more crowded. That is not an LLM quirk. That is what happens to anyone holding too many instructions at once.
Notes and Walls
I can't possibly review that much code.
You can't. Neither can any lead, and none of them are reading every line their team ships. You cannot read your way out of the volume.
There are two kinds of instruction, and mixing them up is what makes review feel like theater. There is the note and there is the wall. What I say in standup is a note. What CI does when you push is a wall. Notes are advice offered to something that gets to decide whether to follow them. Walls fail when violated, and nobody gets a vote.
Your CLAUDE.md is a note. It is worth writing and I would not work without one, but it is prose handed to the thing that forgets prose, which means the line in it that says never do X will drift the same way the constraint you typed five messages ago drifted. Writing it down does not make the rule enforceable. It makes it more likely to be remembered.
What actually binds is smaller and more boring:
- A hook that blocks the tool call.
- A test that goes red.
- A type that will not compile.
- A schema that rejects a malformed object before it poisons the next step.
Those are walls. Building one costs more than writing a sentence in a file, and it is the only version that holds when the model forgets.
The conventions I got tired of repeating are the ones that became lint rules. The agent would follow a written rule for a while, then quietly stop, and I would catch it in review and say it again. Once the rule is in the linter, the run fails and neither of us has to remember it. Every hour you spend converting a convention from prose into something that fails loudly is an hour that buys back review time forever.
Then spend what review you do have where it pays. Not line by line, top to bottom, but at the boundaries: what crosses between layers, what the shape of the data is on either side, what happens on the unhappy path.
One Voice in the Codebase
None of this is mine. I don't know my own codebase anymore.
This is the complaint I think is most badly misdiagnosed, and the one I have the most sympathy for, because feeling lost in code you are responsible for is awful.
But a lead has never written most of the code they own. I usually have more than one project running at a time, which means that while I am deep in one codebase with my hands on it every day, there is another one I am responsible for and have barely touched in weeks. I can still open any file in that second one and find my way. Not because I memorized it. Because it reads as though one developer wrote all of it, when in reality several people did. Same naming, same layering, same file structure, same error handling, same shape of test.
You open something you have never seen before and you already know where things are, because it looks like everything else.
That is what a style guide is for, and it has nothing to do with AI. It was always about consistency, onboarding, and not relitigating the same five arguments every quarter. What changed is the volume. A team of six generating inconsistent code produces a mess you can absorb. The same inconsistency at agent throughput produces a codebase nobody can navigate, including the agent. An agent works by monkey see, monkey do: it reads the code around the thing it is about to write and imitates whatever pattern it lands on. In a consistent codebase that is a feature, and it picks up your conventions for free. In an inconsistent one it finds whichever local dialect happens to be nearest and spreads it further.
There is an irony sitting in the middle of this complaint. The grievance is that the code does not feel like theirs, and a codebase worth working in has always been deliberately built so that you cannot tell whose it is. Uniformity is the thing that makes unfamiliar code legible, and it was good practice long before there was a machine writing any of it.
How to write a style guide that both your team and your agents will actually follow is its own post, and the short version is that the file has to be the same source your linter enforces, and it should be smaller and stricter than what humans would tolerate on their own. I will link it here when it is up.
An Agent Never Graduates
The analogy has a limit, and it is worth naming before someone else does.
A junior grows. You spend six months explaining your boundaries and your conventions and asking them to say the plan back to you, and then one day you stop, because they have it, and they are the one explaining it to somebody newer. The habits above are onboarding, and onboarding ends.
An agent does not do that. It starts every session at zero, keeps nothing between them, and it is never going to become a senior. There is no month where it finally learns your codebase and you get the time back.
So these are not onboarding habits. They are the job now, permanently, and that changes what they are worth. Every convention you turn from prose into a wall, every restatement you ask for before work starts, and the questions you learn to ask without the answer already inside them, all keep paying on the next session and the one after that, because nothing here ever outgrows the need for it.
Which brings me to the complaint I have not answered yet, and it is the one underneath all the others. I stopped doing the hard work, so I stopped learning, and I am getting worse.
Half of that I read differently, and half of it is a risk you have to manage on purpose.
The learning is the part I read differently. Writing the code is the mechanics, and the mechanics were never the part that made you understand the system. A novelist's work is deciding what to say. Putting the words down is how it gets out of their head. Code is the same.
When someone says add a caching layer, the engineering is whether it should be cached at all, how stale the answer can get, and who owns invalidation. Handing that over does not excuse you from understanding anything. You still have to know what should be built, whether what came back is right, and why the thing it proposed on the third attempt was wrong. That is the same material it always was.
What is new sits on top of it: working out what you actually want, precisely enough that something else can build it, which is a deep skill you did not have to learn five years ago.
The other half is real. Write none of it yourself for long enough and you will get slower at writing it. So keep some of the work. Sometimes you write code to find something out: you build the throwaway version because you do not know yet whether the architecture holds, and that only teaches you anything if you build it. If you already know what it says and you are just getting it down, it can go to the agent.
The Third Wall
I wrote a post in 2015 called Keeping Up with Technology, arguing that every new wave threatens the developers who stand still, and that the defense is breadth and a willingness to be bad at something for a while. Eleven years later I am making the same argument about a different wave, which is either consistency or a lack of imagination. I see this one as an enabler, the same category as the industrial revolution, the computer, and digitization. The lever gets bigger, and so does what you can build with it.
I have also written about the walls in my own career, the moments where the way I had always worked stopped being enough. There have been three. The move has been the same every time: lean in, get your hands dirty, be worse than you are used to being for a few months, and come out the other side ahead. This one is the third wall, and it is happening right now, to all of us.
You did not get worse at your job. You got handed a different one, without being asked, and without anyone teaching you how to do it. The new job is called leading, it is hard, and almost everyone who is good at it was bad at it first. The tool is not too agreeable, you are anchoring it with the question. Review stops being theater when you read boundaries instead of lines. And the code only feels unfamiliar because nobody made it speak with one voice.
So if you still want to be the one writing the code, write it. Nothing here took that away, and every good lead I have worked with kept their hands in the work. They were just deliberate about which parts they kept.
There is only one strategy for sitting a wave like this one out, and it involves turning into a goat and living out your days in Nepal.
I am staying here and learning the new job.
Top comments (0)