There’s a tradition in the trades that I’ve always admired. Carpenters build their own sawhorses. Blacksmiths forge their own tongs. Machinists make their own precision tooling.
The first thing you build isn’t something you sell. It’s something that helps you build everything that comes after it.
I’ve noticed something similar happening in software engineering. Almost every exceptional engineer I know is building some version of their own agentic development harness. Custom skills, orchestration layers, coding workflows, automated reviews, evaluation loops. Everyone seems to have a slightly different approach.
And I think it’s brilliant.
We’re watching a new rite of passage emerge in software engineering.
It’s not really about the tools
A blacksmith doesn’t forge their first pair of tongs because the local hardware store has run out. They do it because making the tool teaches them the craft.
They learn how metal responds to heat. How to shape it. Where it bends, where it breaks, and what makes a good tool different from a bad one.
The tongs are useful. But the understanding gained from making them is worth considerably more.
That’s what’s happening with agentic engineering.
You can install Claude Code or Codex today and have a remarkably capable coding agent running in minutes. The commercial tools are excellent and improving at an extraordinary pace.
Yet experienced engineers are spending their evenings and weekends building their own harnesses around them.
Not because they think they can outbuild Anthropic or OpenAI. They’re learning how the machinery works.
The craft is changing underneath us
For decades, software engineering has largely meant understanding a problem, designing a solution, and writing the code to implement it.
We’re now developing another capability: designing systems that can do significant portions of that implementation for us.
And getting those systems to work reliably is a fascinating engineering challenge.
How do you give an agent enough context to make good decisions without drowning it in irrelevant information? How do you divide work between multiple agents without introducing more coordination overhead than you remove? How do you know when the output is correct? What happens when an agent gets stuck, makes a bad assumption, or confidently heads in the wrong direction?
How do you take something that works impressively in a five-minute demo and make it dependable enough to use every day?
These are real engineering problems. They involve architecture, context management, testing, observability, feedback loops and a healthy understanding of failure modes.
The engineer building their own harness is forced to confront them.
And that’s precisely why the exercise is valuable.
We’ve always done this
This isn’t the first time software engineers have built tools to improve their own craft.
We’ve written shell scripts, built internal frameworks, customised editors, created build pipelines and developed testing infrastructure. Some of the most influential tools in software development started with engineers trying to make their own lives easier.
What’s different today is the leverage.
A useful shell script might save you ten minutes a day. A well-designed agentic workflow can change how you approach entire categories of work.
Your development environment is no longer simply helping you write code. It’s increasingly capable of planning, implementing, testing and iterating on your behalf.
That’s an enormous shift in what a single engineer can accomplish.
And I love seeing engineers embrace it with the same curiosity and enthusiasm that has always driven great engineering.
The sawhorse isn’t the furniture
There’s an important distinction, though.
The carpenter builds a sawhorse so they can build furniture. They don’t spend the next six months engineering the world’s most sophisticated sawhorse.
There’s a version of this agentic movement where engineers disappear into an endless cycle of harness development. New frameworks, elaborate agent hierarchies, constantly rewritten orchestration systems. Fascinating technical work that never quite produces anything useful for a customer.
That’s not the point.
The value of building your own harness is the understanding you develop and the capability it gives you.
You might eventually replace every component with an off-the-shelf product. That’s fine. In fact, it’s probably a good outcome.
The blacksmith doesn’t lose their understanding of metalworking when they buy a better hammer.
Likewise, the engineer who has built an agentic workflow from first principles understands what the commercial tools are doing, where their limitations lie, and how to get the most out of them.
They’ve developed judgment that survives the next model release.
Build one. Then build something with it.
If you’re an engineer who hasn’t explored this yet, I’d encourage you to.
Start with the tools available today. Pick a real problem in your development workflow. Maybe it’s breaking down a feature into executable tasks. Maybe it’s reliably running tests and fixing failures. Maybe it’s getting an agent to review its own work against a clear specification.
Build something small that makes that process better.
Use it. Break it. Understand why it failed. Improve it.
Then use it to ship something real.
You don’t need to invent a new agent framework or publish an open-source project. Your first harness might be a handful of Markdown files, a couple of scripts and a reliable feedback loop.
That’s enough.
The exercise isn’t about having the cleverest tools. It’s about becoming the kind of engineer who understands how to use them to deliver extraordinary outcomes.
A good time to be an engineer
There’s understandably a lot of anxiety about what AI means for software engineering. Which skills will remain valuable? What happens to the work we’ve spent decades learning to do? What does the profession look like in five years?
Those are reasonable questions.
But look at what engineers are actually doing.
They’re experimenting, sharing ideas, inventing new workflows, building tools and discovering entirely new ways of working. They’re approaching unfamiliar problems with the curiosity that drew many of us into engineering in the first place.
That’s not a profession standing still. It’s a profession developing a new craft.
And for those willing to get their hands dirty, it’s an incredibly exciting time to be building software.
The carpenter builds a sawhorse. The blacksmith forges their tongs. The software engineer builds an agent harness.
The tools change. The craftsmanship doesn’t.
Now go build something with it.
If your team is building its first harness and wants a second opinion on where to start, we’d be glad to help.