The sceptic's case for going agentic

At my last company, shipping one feature meant coordinated edits across four repositories. Nobody found that strange. It was just the shape of the place.

It is also the reason I spent a long time unconvinced that agents should be writing our code. We had AI in the product already; what we didn't have was AI doing most of the building — writing the code, reviewing the pull requests.

The reservation was never really about the models

That codebase was started in 2019: six years of decisions nobody ever went back to, three generations of patterns for doing the same thing, half the conventions living only in the heads of the people who'd been there longest.

It was also microservices, the flavour of the time, which made it harder rather than easier: no single place the whole of a change is visible, and every service drifted into its own idea of how things are done.

Which made it exactly the wrong thing to hand an agent, because here's the part I don't think gets said enough: agents amplify whatever consistency you already have. Point one at a codebase with three competing ways to fetch data and you get a fourth. Point one at a codebase where there's one obvious way to do everything and it lands somewhere close to what you'd have written yourself.

Going properly agentic there wouldn't have been an adoption exercise. It would have been a rebuild. That's a legitimate reason to say no, and it's a very different reason from "I don't trust the models".

What I wanted to see was the other case: not a product with AI bolted on the side, but one that only exists because of what the models can now do, built by a team that assumed it from day one.

What made me look at Conveo

Honestly, the job spec. Not the AI part — the agency part. It was unusually direct about how much rope you get as an engineer here, and about there being one engineering role rather than a ladder of titles and a product layer above you telling you what to build. Dieter and Maarten have written about why, so I won't repeat it. I read it as either genuinely unusual or just too good to be true, and I wanted to find out which.

I met the team through the interview process, and each conversation gave me more insight into the way they work — enough to answer my own question in favour of genuinely unusual. Nobody was pitching me on AI. It's a company of builders: a meaningful amount of what people use day to day is internal software someone knocked together because the friction annoyed them.

I was onboarded inside a day. Laptop, tooling, every access I needed, no ticket queue. My second official day was a hackathon on a boat in London, which is where I met the entire team and shipped an AI assistant feature. That's not a normal week one. It did tell me something true about how the place operates.

What the work actually looks like now

The biggest change isn't that I write less code. It's where in the process I spend my attention.

Most of my day is planning and refinement — getting a problem specified precisely enough that handing it off is safe. The implementation goes to an agent. Vincent has written up Nightwatch, his version of this taken to its conclusion: plan in the afternoon, agents work overnight, review pull requests over coffee. That sounds like a stunt until you've done it a few times and realise the hard part was never the typing.

Some specifics, because the abstract version of this always sounds the same:

• I work almost exclusively on remote hosts now. Which means I can close my laptop. If something urgent lands, I'll pick it up from Claude on my phone while I'm walking the dog, and it carries on where it was.
• The tooling is integrated to a degree I hadn't seen before. I can query production logs and analytics data from inside my editor session to help data drive decisions. Often that's the difference between an opinion and a decision: "just send them a link" is what everyone says about sharing research, and how many recipients still export a deck instead is a query. I can spec a detailed issue with full codebase and company context without leaving the terminal. Linear issues get created from Slack threads carrying the whole conversation with them, and they update their own status as the work moves.
• Worktrees everywhere. Several agents on several branches at once, isolated from each other. Each worktree gets its own dev server on its own port and its own database, so several features can be running side by side on the same machine, and I can click through any of them without tearing down another.
• Weekly show and tells where people demo new agentic flows and tools they've wired up. This is the bit I'd underweighted from the outside — the practice moves fast enough that a formal process would be stale before it was written down, so instead it propagates by people showing each other. A lot of us now run Superset for orchestrating parallel agents, which arrived through exactly that route.

The trade-offs, honestly

If this post stopped there it'd be recruitment marketing, so here's the other side. Going agentic doesn't remove work, it relocates it, and some of what it relocates it to is harder.

The bottleneck moves to specification. When implementation is nearly free, the cost of a vague idea goes up, not down. An imprecise spec used to cost you a conversation halfway through the work, because you'd notice the ambiguity while writing the code. Now it costs you a finished, confident, wrong pull request. If you can't state clearly what "done" means, agents make you slower.

You don't get understanding for free any more. This is the one I underestimated most. When you write code by hand you understand it by the time it compiles — the understanding arrives with the work, and you never had to plan for it. When an agent writes it you get working code and no understanding, and you have to go and build that yourself, deliberately, across far more code than you used to read in a week. Reviewing is genuinely harder than writing. Anyone telling you review is the easy half isn't reviewing this much of it.

Consistency is what makes agents predictable. Conventions, a real design system, exhaustive switch handling, lint rules that actually fail the build, written-down context about how this codebase does things. In a human team those are nice-to-haves that senior engineers hold in their heads. With agents they're the reason the output comes back usable. A surprising share of the highest-leverage work here is maintaining the guardrails rather than the features.

Judgement doesn't transfer. Agents are extremely good at how and still bad at should we. They will build the thing you asked for beautifully, including when the thing you asked for is a mistake. Which is precisely why the discovery half of the job — sitting with customers, understanding the actual problem — has become more of the job, not less.

Less stays manual than I expected. I assumed there would be a stable set of work I'd keep doing by hand — small surgical changes to code I know well, anything where the spec would be longer than the diff. Small fixes get handed to Devin and come back as a pull request. What's left is the work where the point is the understanding rather than the patch: debugging something subtle where I need the mental model in my own head, and live incidents.

And there's something you give up. Long uninterrupted stretches of writing code are, for a lot of us, the reason we took this job in the first place. That shape of day is rarer now. I've found the trade worth it — the range of what I can attempt in a week is not comparable to before — but I'd rather say that plainly than pretend nothing was lost.

Where I've landed

My reservations were never really about agents. They were about a foundation that couldn't absorb them without a rebuild — and somewhere along the way I let that harden into a view about the way of working itself, which is a much bigger claim than the one I'd actually tested.

What changed my mind wasn't a demo. It was seeing what it's like when the foundation was laid for this from the start — consistent codebase, integrated tooling, a team that treats its own workflow as something to keep rebuilding — and noticing that the ceiling on what one engineer can do had moved somewhere I didn't expect.

If you're the sceptic on your team right now: you might well be right about your codebase. Worth checking whether you've quietly generalised it.

And if you want to find out what the other version feels like, we're hiring.