Harness Engineering: Building Our Own Tools While Teaching AI How We Work

Are we choosing the best tools, or just getting used to their limitations?#

I've been thinking about this question quite a lot lately.

As software engineers, we spend a significant amount of time working with tools designed by someone else. We learn how they operate, adjust our processes around them, and eventually get used to their limitations.

There's nothing necessarily wrong with that. Existing tools solve real problems, and building everything ourselves would hardly be a good use of our time.

But I've always liked having control over how things work.

When I have an idea for a solution, I usually already have a pretty clear picture in my head of how I want it to behave.

I know what information should be available, how the different steps should connect, where certain decisions should happen, and what would make the experience more natural for me.

That understanding comes from my own experience, the problems I've encountered, and the way I approach engineering tasks.

And sometimes, even when a tool already exists for a particular problem, it doesn't quite match the way I see the solution.

With AI becoming part of everyday software development, I've started looking at this differently.

Why should I always adapt my workflow to an existing tool when I can design something around the way I actually want to work?

From using AI agents to designing how they work#

Over the past few months, I've been building my own local tools and workflows around AI agents.

Most of these are related to everyday software engineering activities, such as implementing tickets, reviewing pull requests, and handling other development tasks.

At first glance, these might seem like straightforward use cases for coding agents.

You give an agent a ticket, ask it to implement something, and review the result.

Or you provide a pull request and ask the agent to find potential issues.

But that's not exactly how I want these processes to work.

For me, the interesting part is everything that happens between receiving the task and producing the result.

When implementing a ticket, I want to define how the agent approaches the problem. What context should it gather first? Which steps should happen before implementation? When should another specialized agent become involved?

For pull request reviews, I have my own understanding of what deserves attention and how a useful review should be structured.

Simply asking an agent to "review this PR" doesn't necessarily capture that understanding.

So instead of relying entirely on generic workflows, I've been building my own.

I design the flows, create custom skills, write prompts, connect local tools, define the steps, and decide when different agents should be involved and how they should interact.

The goal isn't to control every line of code an agent produces.

It's to create an environment where agents can perform tasks in a way that aligns with my understanding of the problem.

And this is where harness engineering comes in.

What harness engineering means to me#

Harness engineering is becoming an increasingly interesting part of working with AI agents.

The idea is relatively straightforward.

Instead of focusing only on what we ask an AI model to do, we focus on the environment in which it operates.

An agent might be capable of writing code, analyzing a repository, or identifying problems in a pull request.

But capability alone isn't enough.

It still needs the right information, access to the right tools, an understanding of the expected outcome, and boundaries within which it can operate.

That's what a harness helps provide.

In my own workflows, I think about several connected parts.

Context: What does the agent need to understand before starting? A task description is rarely the whole story. Repository structure, project conventions, architectural decisions, and requirements can all influence the outcome. Skills and prompts: Different tasks require different instructions and capabilities. Implementing a feature, investigating a bug, and reviewing a pull request shouldn't necessarily follow the same approach. Orchestration: Which steps should happen in which order? When should a specialized agent be called? What should happen after an agent completes its part of the work? Tools: Which local utilities, commands, or integrations should be available to the agents? Validation and feedback: How do we check whether the result is correct? What happens when something fails or needs improvement?

For me, these are engineering decisions.

And they're often more interesting than the actual code generation.

An AI agent can produce an implementation, but someone still needs to understand what a good implementation looks like and how the system should work as a whole.

This is also the direction described in OpenAI's article, Harness engineering: leveraging Codex in an agent-first world, which explores the shift toward designing environments, specifying intent, and building feedback loops that help agents perform engineering work reliably.

Our experience is becoming part of the system#

One thing I've noticed while building these workflows is how much of my own experience ends up being translated into instructions and reusable capabilities.

Consider a pull request review.

After spending years working with software, engineers develop their own ways of analyzing changes.

We learn which areas deserve extra attention, which patterns have caused problems before, what makes code maintainable, and where hidden complexity tends to appear.

A lot of this knowledge isn't formally documented.

It's simply how we think.

But when building an AI-driven review workflow, we start making that thinking explicit.

We define review steps, document expectations, create skills, write instructions, and decide what the agent should investigate.

Something that previously existed mostly in our heads becomes part of a system that can be executed repeatedly.

The same applies to ticket implementation.

Over time, engineers develop instincts about how to approach an unfamiliar codebase, when to investigate further, when a proposed solution is becoming unnecessarily complicated, and what needs to be verified before considering a task complete.

By designing a harness, we can turn at least some of that experience into a repeatable process.

And I find that genuinely exciting.

We're not simply using AI to write code faster.

We're using our knowledge to design systems that can perform increasingly complex engineering tasks.

But there's another side to this that I think deserves more attention.

What happens when our knowledge becomes an AI skill?#

A discussion following my LinkedIn post brought up an interesting point.

Today, we might spend time building custom workflows, writing prompts, creating skills, and orchestrating agents around our own experience.

But what happens when those same capabilities become available out of the box?

Imagine spending weeks refining a process for implementing tickets.

You define the steps, decide what context should be collected, create specialized skills, and improve the workflow based on what you've learned.

Then, at some point, a platform introduces a new command that handles most of those steps automatically.

Something that required a custom workflow yesterday might become a simple slash command tomorrow.

I think that's a realistic possibility.

We've seen similar changes throughout the history of software development.

Things that once required custom implementations eventually became libraries, frameworks, managed services, or standard platform features.

Developers used to spend considerable effort solving problems that are now handled by tools we take for granted.

In many ways, that's how technology progresses.

We solve a problem, learn from it, make the solution reusable, and eventually abstract away much of the complexity.

AI could accelerate that process significantly.

The difference is that we're no longer abstracting only technical implementations.

We're also starting to encode parts of our reasoning, decisions, and experience into systems that can perform work on our behalf.

And that raises some interesting questions about what engineering knowledge will mean in the future.

I'm excited about AI, but I also have concerns#

I use AI. I build tools around it. I experiment with agents and genuinely enjoy exploring what's possible.

So my concerns don't come from being against the technology.

Quite the opposite.

The more I work with it, the more I appreciate its potential.

But I also find myself thinking about where this is heading.

As engineers, we're continuously sharing parts of our knowledge with AI systems.

We describe our reasoning, write detailed instructions, structure workflows, document decisions, and create reusable capabilities.

That knowledge can make our own systems more effective.

It can also make engineering work easier for other people when those capabilities are shared or incorporated into larger platforms.

And depending on where and how those systems are deployed, it raises questions about ownership, control, and the future value of certain engineering skills.

To be clear, documenting knowledge in a local workflow doesn't automatically mean that a model provider receives it or trains on it. That depends on the tools, services, configurations, and data policies involved.

But the broader question remains.

If more and more engineering knowledge becomes executable through AI agents, how does that change the role of the people who originally developed that knowledge?

I don't think anyone can answer that confidently yet.

Some skills may become less valuable because they can be automated more easily.

Others may become more important because engineers will need to design, evaluate, secure, and maintain increasingly complex AI-driven systems.

New responsibilities will likely emerge, just as they have during previous technological shifts.

Still, I don't think we should ignore the uncertainty simply because the technology is exciting.

Would AI look different if engineers made all the decisions?#

This is something else I've been thinking about.

If decisions about AI development, adoption, knowledge sharing, and automation were entirely in the hands of engineers, would the industry look the same?

I suspect it would look different.

Not because engineers would necessarily make better decisions in every situation.

We have our own biases, priorities, and disagreements.

But engineers who work directly with these systems often see practical trade-offs that aren't immediately visible in business discussions.

We think about maintainability, technical debt, security, quality, and what happens when a system fails.

We also understand how much experience can be hidden behind a seemingly simple engineering task.

At the same time, software engineering doesn't happen in isolation.

Businesses have their own responsibilities and constraints.

They need to deliver products, reduce costs, improve productivity, respond to competitors, and remain relevant in changing markets.

If an organization can perform certain tasks faster or more efficiently with AI, there's a strong incentive to explore that opportunity.

Even engineers who have concerns about the long-term implications still operate within those business realities.

And that's where I see the tension.

We might want to be more cautious about how quickly we automate certain responsibilities or how much knowledge we turn into reusable AI capabilities.

But businesses also face pressure to adopt new technology.

Not every organization can afford to ignore improvements that competitors are already using.

That doesn't mean we should automate everything simply because we can.

It means the conversation needs to include both engineering judgment and business realities.

Building our own tools is also about having a choice#

Despite those concerns, I still find the current moment incredibly interesting.

One of the things I appreciate most about AI-assisted development is how much easier it has become to experiment with ideas.

I can have a specific workflow in mind, build a local tool around it, connect AI agents, and gradually improve the system based on my own experience.

I don't necessarily have to wait for an existing platform to support the exact process I want.

I can try it myself.

That doesn't mean every custom solution is better than a mature third-party product.

There are plenty of reasons to use existing software, including reliability, support, integrations, security, and maintenance.

But the decision is no longer always as obvious as it once was.

For some workflows, a purpose-built tool might offer better control and a more natural experience.

For others, adopting an existing solution will be the more sensible choice.

And sometimes the best approach is somewhere in between, using existing platforms while building our own orchestration, skills, and interfaces around them.

The important part is having that flexibility.

I like being able to turn my own understanding of a problem into something that works.

Our own little engineering toys, built around the way we think.

Some might eventually become unnecessary because a future platform provides the same functionality.

And that's fine.

The experience gained from designing those systems doesn't disappear just because the implementation becomes easier.

But it does mean we need to keep learning and questioning where our value comes from.

What does this mean for software engineers?#

I don't believe the future of software engineering is simply about replacing developers with AI agents.

I also don't think it's realistic to assume that our roles will remain unchanged.

We're already seeing how AI changes the way we approach development tasks.

And harness engineering is one example of that shift.

Instead of spending all our time implementing individual steps manually, we can spend more time designing the environment in which those steps are executed.

That involves understanding requirements, defining processes, creating reusable capabilities, setting boundaries, and evaluating results.

But there's an important detail here.

Moving to a higher level of abstraction doesn't automatically guarantee that our work becomes more valuable or that every engineering role remains necessary.

Some responsibilities may change significantly. Some tasks may disappear. Others may become more complex.

And as the tools improve, even the workflows we currently spend time designing might eventually become standard capabilities.

That's why I think engineers need to do more than simply learn how to use the latest AI tools.

We need to understand the systems we're building, question the trade-offs, and maintain enough technical depth to recognize when an AI-generated result is actually correct.

We also need to have more conversations about the long-term implications of encoding engineering knowledge into increasingly autonomous systems.

Because we're not just using these tools.

We're helping shape what they will be capable of doing next.

Final thoughts#

I started exploring harness engineering because I wanted more control over my own workflows.

I knew how I wanted certain engineering tasks to operate, and I liked the idea of building tools that reflected that vision.

The more I've worked with AI agents, the more interesting that process has become.

I can define workflows, create skills, orchestrate specialized agents, and experiment with different approaches to engineering tasks.

It gives me the freedom to build systems around my own experience instead of constantly adapting to someone else's decisions.

But it has also made me think more seriously about what we're creating.

Today, we're building custom workflows based on our knowledge.

Tomorrow, some of those workflows might become standard features available through a simple command.

That's probably a natural part of technological progress.

And while I'm genuinely excited about the possibilities, I think it's reasonable to have concerns about what that progress means for engineers, the value of our knowledge, and the decisions being made around AI adoption.

We can't separate those questions from business needs and market competition.

But we shouldn't stop asking them either.

For me, harness engineering represents both sides of this change.

It's an opportunity to build better systems by translating our experience into tools and processes that AI agents can follow.

At the same time, it's a reminder that we're gradually turning more of our own engineering knowledge into something software can execute.

We're not just teaching AI how to complete tasks. We're teaching it parts of how we think and work.

And I think it's worth paying attention to what happens next.