We Don't Code Manually Anymore. We Build the Harness.
You added a coding agent to your workflow. You’re faster now. Features that used to take a day take an afternoon. It feels like a superpower, and for a while it is.
But look down for a second. You’re still in the traces. You’re pulling the cart right alongside the machine, hand on the keyboard, correcting it, re-prompting it, cleaning up after it. “AI-assisted” means a human and an agent hauling the same load together. That’s better than one human hauling it alone. It is not the thing.
Here’s the uncomfortable truth: as long as a human is in the loop of producing the work, you’ve only made the human a faster laborer. And a faster laborer is still spending the two things you can never buy back: their time and their attention. Every hour someone on my team spends generating output by hand is an hour they didn’t spend on the strategy, the IP, the judgment that no agent has. That’s the wrong trade, and doing it faster doesn’t fix it. It just breaks even sooner.
So we drew a line. At HikmaAI, we don’t code manually. Not the app logic, not the tests, not the plumbing that runs the repo itself. Humans don’t hand-patch. That sounds extreme written down, and it felt extreme the first time I said it out loud, coming from someone who has spent most of his adult life happy with his hands in an editor. But it’s not a stunt. It’s a direction.
Think of a harness
A workhorse is strong. Left loose in a field it’s still strong, and completely useless to you: the power has nowhere to go. You don’t make the horse stronger by grabbing a rope and pulling next to it. You make it useful by putting it in a harness.
A good harness doesn’t add horsepower. It channels the power the animal already has. And it does one more thing that matters more than people think: it moves the human out of the traces and up onto the seat. You stop pulling. You start driving. Reins, not rope. You point, you correct, you decide where the whole thing is going, and the power under you does the hauling.
That’s the shift. The agent is the horse. It has real power now, more every month. What’s been missing isn’t strength. It’s the harness.
So we built one. We call it Bridles. I’m not going to walk you through its guts today, but the idea behind it is simple enough to say in a paragraph: it turns our engineering conventions into something an agent can actually read and follow, and it refuses to call work “done” on the agent’s word alone. Humans plan, steer, and validate. The agent does the rest.
Three moves, and only three, are ours.
The three things a driver actually does
Plan. Point the cart at the right place before anything moves. This is where taste lives, where the hard product calls get made. It’s the most human part of the job and, not by accident, the part I want my people spending their hours on.
Steer. Not constant correction. A hand on the reins for the moments that genuinely fork, where the road splits and only judgment tells you which way. The rest of the time, you let it run.
Validate. Not “does it look right.” Does the evidence agree that it is right. This is the part most people skip, and skipping it is how you end up trusting a confident machine that’s confidently wrong.
Everything else that used to eat a developer’s day now happens down in the harness, out of the human’s hands.
What I learned building it
A couple of things surprised me, and they’re worth more than the tooling.
The first is about being stuck. When an agent gets stuck, the old instinct kicks in immediately: try harder, write a cleverer prompt, or just grab the keyboard and do it yourself. We banned that instinct. When the agent gets stuck, that’s not a signal to jump into the traces. It’s a signal that something is missing from the harness: a guide it can’t see, a check it doesn’t have, a piece of context that lives in someone’s head instead of in the repo. So you don’t do the work by hand. You build the missing piece, and then you let the horse pull again. Struggle stopped being a reason to intervene and became a to-do list for the harness.
The second is about trust. I don’t trust the agent because it sounds confident. Confidence is free, and a model has an endless supply of it, and it will spend every bit of that confidence being wrong. So the whole system runs on evidence instead of on prose: nothing is “done” because the agent said so. That one rule, evidence over eloquence, changed how the team works more than any model upgrade did.
From context engineer to harness engineer
Here’s the reframe, and it’s the real point of this post.
For the last couple of years the craft was context engineering: feeding the model the right information, at the right time, in the right shape, so it would do a good job on the next task. Useful. Still necessary. But it keeps you next to the horse, handing it things.
The craft now is harness engineering. The question is no longer “how do I get the agent to write this code.” It’s “how do I build the thing that lets the agent write this code, and reliably prove it’s right, without me in the traces.” That is a different job. It requires:
- Encoding what your best people know into guides an agent can follow, instead of keeping it in their heads
- Building the checks that decide “done,” so a human doesn’t have to read every line to trust it
- Treating every stuck moment as a missing capability to build, not a task to do by hand
- Getting comfortable up on the seat, steering, when every instinct trained over a career says grab the reins and pull
I’ll be honest: that last one is the hardest, and I’m not fully past it. The pull to open the editor and “just fix it myself” is strong. Sitting on the seat and trusting the harness is a discipline, not a feeling. I’m still building the muscle.
I’m going to write about this transition as we live it. What breaks, what the team resisted, where the harness wasn’t good enough and we had to go rebuild it. Not a polished case study after the fact. The real thing, as it happens.
Ask the machine first
Here’s the habit I keep pushing on my team, and it’s smaller than the harness but it feeds it. Before you start any task, before you open the doc or the editor or the spreadsheet, ask one question: can the agent do this instead of me? Not “can the agent help me do this.” Can it do it.
That question sounds trivial. It isn’t. It rewires everything upstream and downstream. It changes what you hire for, because you stop staffing the work and start staffing the judgment. It changes execution, because your first move on any task is no longer “how do I do this” but “how do I hand this off and check it.” Make it your reflex and the harness stops being a thing engineering built. It becomes how the whole company thinks.
And once you’re asking it, you notice how much work you’ve been quietly not doing. The stuff that never makes it off the someday list because you don’t have the hours. Scraping arxiv.org for the papers that actually touch your business. Pulling the YouTube channels you follow, transcribing the talks worth an hour of your attention, and getting back the three paragraphs that matter instead of the ninety minutes. Watching Reddit so you don’t have to. The point isn’t to read more. It’s to triage: let the agent do the reading and hand you the shortlist. Same move on the rest of it, the issues piling up in your codebase, the leads nobody’s chased, the marketing idea you had in the shower and lost by lunch. That’s not laziness dressed up. It’s the whole bet. Work smart, not hard.
This isn’t an engineering trick
The last thing, and the reason I think this matters beyond my four walls.
None of what I described is specific to code. Guides that carry your best judgment. Sensors that decide when something is actually done. Humans reserved for planning, steering, and validating, and pulled out of the manual grind. That’s not an engineering pattern. That’s an operating model.
The same harness thinking belongs in marketing, in sales, in every function that today runs on people hand-producing work an agent could pull. Engineering is just where we started, because it’s where the sensors are cheapest to build and the feedback is fastest. It is not where it ends.
The goal was never a company of faster laborers. It’s a company where every team is up on the seat, hands on the reins, driving. The horses are strong enough now. The work is building the harness, and then having the nerve to let go of the rope.
— Mauro
References: