Ask most developers whether an AI coding agent writes better code than a junior programmer, and you’ll get an opinion. At Levi9, the answer is that it’s the wrong question. Comparing a junior developer’s code to an agent’s code is apples and oranges. They shouldn’t be measured against each other at all.
One way to illustrate it: an old joke about a husband sent to buy margarine, told “if they have eggs, buy ten,” who comes home with ten packs, taking the instruction literally. Give the same errand to an AI agent, and if there are no eggs, it might solve the underlying problem instead and come home with both eggs and margarine. It’s not incoherent, but it’s also not what you asked for. The point isn’t that agents are unpredictable and best avoided. It’s that talking to one is a different skill than briefing a junior developer.
What “Harness Engineering” Really Means
A harness is everything wrapped around an autonomous coding agent: its tools, instructions, skills, sub-agents, and the feedback loops that keep its output stable over long, unsupervised stretches. Tools like Claude Code, GitHub Copilot, Cursor, and Codex ship with built-in harnesses, but engineers can extend them with their own. That design work is what’s known as harness engineering.
The last six months felt like a turning point. Claude Code paired with Opus was, in our words, an “earthquake.” Before it, prompting meant spelling out instructions line by line. After it, a well-written ticket became enough to get an agent working alongside a developer, lowering the cost of writing software. Companies now have to adapt.
From a First Ticket to a Virtual AI Team
The first real test came when a lighter workload freed up time to experiment. Working on a well-organized project with an established set of instructions, a small ticket was handed to a coding agent through GitHub Copilot’s CLI. After a round of review and revisions, it was done in about ninety minutes, work that would normally take far longer. That’s when it became clear this could genuinely be used on a real project.
A Microsoft team had run a coding agent inside one of their repositories for eight months, working out which tickets to hand it and how much guidance each one needs. The takeaway was similar: CLI-based agents are a good fit for tasks that take more than fifteen minutes and can be explained with a good plan attached in the ticket.
In May, GitHub shipped a coding agent named GitHub Copilot App built for long-running, autonomous work: hours-long sessions that read documentation, run tests, and act without hand-holding. It went straight into testing on a small proof of concept, an app that turns a craving (“potatoes”) into recipe suggestions and auto-fills a grocery list. It worked quickly, which raised the real question: what happens if it keeps growing for six months without any discipline around it?
So the harness engineering had to be done properly: custom sub-agents modeled on real team roles, a delivery manager, an architect, a frontend developer, a backend developer, each with its own rules, wrapped in a weekly choreography. Tickets get filled in on Monday, a plan and open questions on Tuesday, answers on Wednesday, coding on Thursday, review and polish on Friday. The rhythm didn’t always hold exactly, but it stuck often enough to become a working version of “intent-driven development”: planning, coding, validation, and, critically, refactoring.
The tool itself made this easier to run well. It logs every session automatically, questions asked, assumptions made, answers given, giving a team lead a full record without having to reconstruct it from the diff. A canvas feature lets agents drop in artifacts like screenshots, and a “pick and polish” mode handles small fixes in minutes. Costs typically ran 300 to 400 credits per ticket, occasionally spiking to 1,000 when a session sat open too long. Ownership still matters here: agent-drafted tickets can get noisy, and someone on the team has to shape them into something usable.
Cognitive Debt: What Happens When You Skip the Refactor
What happens when that refactoring step gets skipped isn’t a secret. In one sprint, tests were passing, so the code didn’t get a close look. When a change was later requested for that component, the agent quietly created a duplicate instead of modifying it, leaving dead code behind. You have to look at what it wrote.
That experience is behind the idea that matters most here: cognitive debt. Just as unmanaged shortcuts pile up as technical debt, unmanaged reliance on agents piles up as a gap in what a team actually understands about its own code. If production breaks and nobody knows how to navigate code an agent wrote, the whole team is stuck waiting while someone argues with it. Reviewing agent-written code, tickets, and plans isn’t optional. It’s what keeps that debt from coming due at the worst possible moment.
A Lesson From Prompt Design: When One Rule Breaks Everything
One story from prompt engineering for image generation, using Nano Banana, sums this up well. The setup separated product-specific prompts from a shared, system-level one. A request came in to make generated people look more diverse, and the fix seemed simple: add a rule to the shared prompt. But because that rule sat at the system level, it fired even on prompts with no people in them at all, and people started appearing in images where none belonged. It’s the margarine joke from the other side: a coherent instruction can misfire the moment it meets a context nobody scoped it against.
The Takeaway
None of this hands more control to AI. If anything, it’s the opposite. The more autonomously an agent works, the more deliberately the boundaries around it have to be designed, and the more seriously the team has to stay fluent in the code that comes out. Harness engineering, sprint choreography, and refactoring discipline aren’t friction slowing the agent down. They’re what makes the speed usable.
***This article is part of the AI9 series, where we walk the talk on AI innovation.***
In this article:
@ Levi9 Serbia
