Gardening the codebase.
Coding agents now write much of my code. So what’s left for me to do? Tending the garden that code grows in, and pulling the weeds.
By Nizar Oukhchi, Solution architect
Published · 8 min read
For most of my career, my job was to write code.
That's not really true anymore. In the repositories I work on today, a large share of the code is written by coding agents. I still review it, steer it and sometimes rewrite it. But I type far fewer lines than I used to.
So what is my job now?
I've been thinking about this a lot, and the best answer I've found is a slightly unusual one. I think my job is gardening.
Code grows. Gardeners tend.
A gardener doesn't make plants grow. That part happens on its own.
What a gardener does is prepare the soil, decide what goes where, put up a trellis, water regularly and pull the weeds before they take over. The skill isn't in the growing. It's in the conditions.
Coding agents are very productive growers. Give one a task and it'll produce working code, fast. But here's the catch: an agent grows whatever the environment encourages.
In a codebase with clear conventions, fast feedback and good examples, an agent writes code that fits.
In a codebase full of inconsistent patterns, slow tests and hidden coupling, it also writes code that fits. It faithfully reproduces the mess, at a pace no human team could match.
That's the shift. My main job is no longer to write every piece of code. It's to build the garden that lets code grow healthily, and to pull the weeds before they spread.
Why the boring work matters more now
By "platform work" I mean everything that makes a codebase clean, fast and easy to maintain. A coherent architecture. A test suite you trust. A quick build. Consistent conventions, and the tooling around them.
For years, this was the work that got pushed back whenever a deadline came close. I've done that myself more times than I'd like to admit.
With agents in the loop, I don't think we can afford to anymore. Here's why.
Agents imitate. An agent learns how your codebase works by reading it. If there are three ways to call an API, it'll pick one at random. Or invent a fourth. Every clean example is a template, and so is every shortcut.
Agents learn from feedback, not memory. How does an agent know its change is right? The types check, the tests pass, CI is green. If that feedback is slow, flaky or missing, the agent guesses. Or loops. Or declares victory too early.
Agents get stuck where people improvise. An experienced developer works around technical debt with knowledge that lives in their head. "Don't touch that module." "That test always fails on Mondays." An agent has none of that. Bad architecture doesn't just slow it down. It blocks it, or sends it confidently in the wrong direction.
Put together, this means something uncomfortable.
The quality of your platform is now the ceiling on the quality of everything your agents produce.
Product and platform, at vidIQ
I didn't arrive at this through agents. I arrived at it through a much older tension.
At vidIQ, I worked on both sides of the line. I shipped product features that users could see, and I worked on the platform underneath them. Early on, these felt like they were competing. Every week I spent on the build, the tests or the architecture felt like a week of features I didn't ship.
Was I wasting time?
Not exactly. But I was thinking about it wrong.
Over time, I learned to see them as one system. The feature is the plant. The platform is the soil. (I hope you'll forgive me for stretching this metaphor. I'll keep doing it.)
A feature shipped into poor soil costs more to change, breaks more often and slows down the next one. And platform work done with no product in mind drifts into polishing things nobody needs.
The balance that worked for me was simple:
- Every feature should leave the code a little better than it found it.
- Platform work gets deliberate, protected time, not a "cleanup sprint" that never comes.
Agents tilt this balance even further. When producing a feature gets cheaper, the bottleneck moves to everything around it. How fast can you verify it? How safely can you change it? How clearly does the codebase tell the agent what good looks like?
All of that is platform work.
Pulling weeds
This might all sound a bit abstract. So here are two concrete weeds I pulled.
Weed 1: tests that didn't earn their keep
Agents write tests readily. And they write them in the image of the tests they find.
Over time, we had piled up a lot of unit tests that checked implementation details, mocked almost everything and duplicated each other. They made the suite slower. They broke on every refactor without catching real bugs.
Worst of all, they taught the agents that this was what a test looks like.
So we deleted them. In bulk.
We kept the tests that protected real behavior at meaningful boundaries, and added a few where coverage actually mattered. The suite got faster, and when it failed, the failure meant something again.
And then something I didn't fully expect happened. The agents' new tests got better too. Not because the agents changed, but because the examples they learned from did.
Sometimes the most productive change you can make is deleting code.
Weed 2: agents that couldn't see CI
The second weed was quieter.
An agent would make a change, run a few checks locally and report that it was done. A few minutes later, CI would fail on something it never saw. Then a person had to notice, read the logs and send the agent back.
Was the agent being careless?
Not really. It just couldn't see. It finished the work it could verify, and stopped there. People (me included) do the same thing.
So we gave it eyes. We added tooling that lets the agent follow its own CI run: see which jobs failed, read the failing logs and fix the problem before calling the work finished. We also made flaky jobs visible, so people would fix them instead of hitting retry.
The definition of done changed from "I wrote the code" to "the pipeline is green." A whole category of back-and-forth just disappeared.
Here's the loop we ended up with:
- EngineerSet the conventionsWritten instructions, reference examples, architecture boundaries.
- AgentThe agent implements the change
- CheckFast local checksTypes, lint and focused tests, in seconds.
- CheckCI runs, and the agent watches itIt reads failing logs and fixes them before calling the work done.
- EngineerReview the changeJudge the choices, not only the outcome.
- PlatformWeed and improve the platformDelete useless tests and duplicate patterns, update the conventions.
A gardener's checklist
If you want agents to write code you're happy to maintain, start with the ground they work in.
- Write your conventions down where agents read them. An instructions file at the root of the repository, with links to reference examples.
- Keep one way to do each thing. When you find two patterns for the same job, pick one and delete the other.
- Make feedback fast and trustworthy. Remove tests that only test the mocks, fix the flaky ones, keep local checks to seconds.
- Close the loop on CI. An agent that can see its own pipeline stops handing you broken work.
- Keep modules small and boundaries explicit, so a change makes sense without reading the whole system.
- When you see a weed, fix the root. Correcting one bad instance in review helps once. Correcting the convention or example it came from helps every change after it.
More fun, not less
Our industry is changing faster than at any point I can remember. It's easy to read that as a threat.
My experience has been the opposite.
Handing the repetitive parts to agents leaves more room for the parts that made me love this work in the first place: design, judgment, and building systems that hold up.
Honestly, it's more fun than it's ever been.
You just have to take care of the garden.
If your team is adopting coding agents and the codebase keeps pushing back, that's exactly the kind of platform work our software engineering services cover. Tell me where it hurts.