What Agentic Engineering Actually Requires

Four tickets went through clean last week. The agents read them, built them, wrote the tests, ran the suite, opened the PRs. I reviewed and merged. That part of the job is basically solved now, and it still feels a little unfair.

The fifth one broke the pattern. The ticket said “show the timezone on the matches cards.” Two lines. Any agent on earth could do that in a minute, and one did.

But something about it bothered me, so before I merged it I went and looked at where those times were coming from. The app was collecting a date, a time, and a timezone from the user, then throwing the timezone away and parsing the rest as UTC. An 8pm Eastern session was stored as 8pm UTC, four hours early, on every record that had ever been created.

Nobody had noticed because every screen printed the stored value straight back. You typed 8pm, you saw 8pm, everything looked fine. Meanwhile the reminder emails, the join window, and the 48-hour warnings were all keyed off the wrong instant, so rooms would have opened hours before anyone showed up. It’s in beta with a handful of sessions on the calendar, which is the only reason this is a story about catching something instead of a story about a very confusing week.

So the ticket was real, but it was a symptom. Adding a timezone label to those cards would have made the bug more convincing, because now the wrong time would have a confident little “EST” next to it.

The agent does exactly what you asked

An agent is very good at executing the request in front of it and has no opinion about whether the request makes sense. It won’t stop halfway through and ask why this screen needs a timezone label in the first place. It doesn’t wonder. It builds.

So the failure mode has inverted. It used to be that you knew what you wanted and the hard part was getting it built. Now getting it built is the easy part, and the hard part is being right about what you asked for. A wrong ticket used to cost two weeks of somebody’s time, so it got questioned on the way in. Now a wrong ticket costs ten minutes, so it sails through, and you find out later when the thing you built does the wrong thing at scale, with confidence.

When people ask me what skills agentic engineering requires, they expect me to talk about prompting. Or which framework, how many agents, subagents versus one big context window, MCP servers, memory. I called that layer decoration in Good Spec, Good Robot and I’ll say it again here. You can learn all of it in a weekend and it changes almost nothing about your output.

The skills that matter are older and less fun to talk about. None of them show up on the levels of agentic engineering as tools you adopt, because they’re not things you install.

Suspecting the ticket

The first one is the one that saved me last week. Every request that arrives is a symptom of something, and you have to be curious enough to ask what. Not every time, or you’d never ship anything. But often enough, and with decent instincts about which ones deserve it.

The tell is usually that the request is too small for the thing it’s touching. “Just show the timezone,” or “just add a retry.” When somebody asks for a cosmetic fix to something structural, that’s usually the structure asking for help.

An agent won’t do this for you. It has no reason to be suspicious, because it wasn’t there when the thing was built and it doesn’t carry any of the doubt.

Reading code you didn’t write

The second skill is the one nobody warns you about. You’re reviewing all day now, on code that appeared while you were doing something else. If you were mediocre at code review before, you’re the bottleneck now, because review used to be maybe 10% of the week and now it’s most of it.

And it’s a harder kind of review than the one you’re used to. The code is usually fine. It compiles, it’s tested, it follows the patterns in the repo. What you’re actually checking is whether it solves the real problem, which requires you to already know what the real problem is. See above.

Deciding what counts as proof

The third one is verification, and this is where I see people get burned the most. The agent ran the tests and the tests passed. Cool. The tests were also written by the agent, against its own understanding of the ticket, which is the same understanding that might be wrong.

A green suite tells you the code does what somebody thought it should do. That’s not nothing, but it isn’t proof. On the timezone thing the suite was green the whole time the data was wrong, because no test ever checked an 8pm Eastern input against a real instant in time. Nobody had thought to write that one, so nothing was watching.

Designing the check is the job, and it means picking the one thing that tells you you’re fine if it holds. The tooling won’t pick it for you.

Knowing when to stop

The last skill is taste, and DHH said it better than I will. Your constraint isn’t time anymore, it’s taste. When you can build anything in an afternoon you will build too much, and unlimited capacity with no discipline gets you a blob nobody wants to maintain.

I catch myself here all the time. Something takes twenty minutes now, so why not. Twenty of those and you’ve got a product with forty features and no shape.

The agentic engineering skills that actually matter

Curiosity about what’s underneath a request, the patience to review code you didn’t write, the judgment to decide what proof looks like, and the restraint to skip most of what you’re now capable of building. Prompting and framework choice didn’t make the list.

Which is a mildly annoying answer, because those are just engineering skills. They’re the ones that separated good engineers from fast ones long before any of this, and the AI didn’t replace them. It deleted everything else that used to hide them.

The four clean tickets were fine. I don’t want to undersell that, it’s genuinely a different way to work and I’m not going back. But the fifth one is where the value was, and no agent was ever going to find it.