The tech industry has always been about buzzwords; IoT, web3, blockchain, the metaverse, LLMs, generative AI, you name it. Many of these have come and gone, some are here to stay, and many more will come.
Beyond all the regular excitement around LLMs and agentic coding tools, I'd like to walk through one term I've been hearing more and more over the last few weeks on social media, at work, and through friends in the industry. That term is "Harness Engineering." Like a lot of others, I first saw it in a recent blog post from OpenAI, which I'd recommend reading if you haven't already to get an idea of where the industry is currently heading. To give you the gist of it, here is the opening passage of the blog post:
Over the past five months, our team has been running an experiment: building and shipping an internal beta of a software product with 0 lines of manually-written code.
The product has internal daily users and external alpha testers. It ships, deploys, breaks, and gets fixed. What’s different is that every line of code—application logic, tests, CI configuration, documentation, observability, and internal tooling—has been written by Codex. We estimate that we built this in about 1/10th the time it would have taken to write the code by hand.
At first glance, nothing too revolutionary here. Not exactly a new concept by today's standards, and we already have a buzzword for this: "vibe coding"! So why do we need a new one?
*vibes intensify*
Any software engineer can tell you today that vibe coding is great for personal projects and internal tools, but not a serious strategy for developing consumer-facing, secure, production-ready applications that can scale. Anyone can vibe code, so what's the difference this time? Let's try to unpack it.
Where We Are Today
Most engineers these days have used agentic tools to varying degrees of success. At first, this came in the form of simple experimentation with Copilot and autocomplete, but since the release of Opus 4.5 from Anthropic late last year and the rise of agentic-driven development with CLI tools like Claude Code, the practice of programming has changed completely.
If you've been using these tools and benefitting from them, you're already on the curve. What used to take you days to design, implement, and test thoroughly can now be done in a matter of minutes or hours.
That being said, speed does not equate to correctness. While powerful, the agents still need constant attention and direction - especially when working in existing codebases. You still call the shots; you have to, in order to avoid introducing bugs, degrading performance, or causing incidents.
Depending on the nature of your work, you may have noticed a gradual sense of leniency or trust towards the code produced by an agent. More and more, you leave your IDE or text editor closed, coding solely through the agent. If you're working in a codebase or a programming language you've never learned yourself, you trust the agent is using the appropriate best practices. You may have even taken it a step further and now trust the agent with reviewing its own work.
You get the point.
More and more, the practice of programming is becoming hands-off. Every engineer has a deep desire to automate everything manual they do, and with every new CLI tool or MCP server that becomes available, you might be investing a few more minutes every day prompting an agent to generate some skills for you to automate another portion of your work. Be it using the GitHub CLI to automatically create or review pull requests, the Atlassian MCP to update the current state of your Jira tasks based on work you've done through the agent, the Chrome DevTools MCP to automatically test changes made on your web app, and endlessly more.
With all these tools and workstreams, you may have noticed that despite the unique ability for an agent to do your bidding asynchronously, your mental bandwidth and your limits on context-switching quickly become the bottleneck slowing you down. With that, you may have also started researching about agent orchestrators, Gastown being a popular example from recent memory.
All of this naturally begs the question, if we can eventually automate every aspect of the job, what work will there be left to do? Assuming frontier models continue improving at the rate they have been, trust in their output passes a critical threshold, and the ability to verify their output without uncertainty is fully automated, what will happen to the profession? Is there still even a need for an engineer to be pulling the strings? Are engineers on the way out?
These are questions many have had over the last few years, and they are not just specific to software engineering. I won't pretend to have all the answers, but in this case I think there's a lot to suggest the opposite outcome: engineers are very much on the way in.
Harness Engineering?
So... what exactly is Harness Engineering? If vibe coding is the practice of using AI-generated code with a minimal understanding of the underlying logic, then in the silliest terms, Harness Engineering is "good vibes only"-driven development. It's the result of asking the question: "What if we let agents independently write and review all the code?"
thank you reddit for this masterpiece
At first, a question like that might get a reaction from a seasoned engineer. Letting an agent independently introduce changes with minimal human intervention, especially in an existing codebase, is almost guaranteed to degrade quality or introduce bugs in some certain way. That's not what's really being asked though. The point is: what infrastructure, tooling, or systems would you need to put in place to allow agents to reliably write all the code in your codebase? This is the essence of Harness Engineering.
If you take the question to heart, you might already have a good idea of what is currently preventing you from doing this. It could be the parts of your workflow that have not yet been automated; for example, maybe you have to:
Manually deploy each of your changes to a sandbox environment to test them before merging.
Review code intently to catch “AI slop” and hallucinations from the agents, make sure they’re not editing irrelevant files, and, more importantly, not introducing new bugs or regressions.
Work sequentially because, for large projects spanning multiple services or layers, you don’t trust the agent to implement all required changes across the system from a single instruction, so you monitor and guide it every step of the way.
Explicitly tell an agent which architecture to use (for example, when dealing with legacy logic alongside newer frameworks that have been migrated to).
Abide by a spending budget, since agents are expensive to run, and tightly supervising them rather than letting them loose burns fewer tokens and saves the company money.
These are only a pieces of the puzzle, but they paint a vivid picture of the type of challenges that come with attempting to do this at scale in a production environment. Some issues are solvable through process and workflow changes, others will require infrastructure, tools, and frameworks that don’t yet exist. The OpenAI team goes through some of these challenges in more detail in their blog post.
"ok claude, create a $1bn SaaS company for me, make no mistakes"
The solutions to these problems go beyond just “prompting harder”. They involve designing additional guardrails that every agent change must pass through, on top of the CI checks that may already exist in a repository: change isolation, policy enforcement, stronger static and dynamic analysis, canary deploys, blast-radius limits, observability and feedback loops for agents, and automatic rollback rules - all tuned to increase how much you can safely trust agents to run on their own.
These challenges are ones that senior engineers at most, if not all, large tech companies are now trying to address in some capacity in 2026. The potential benefits are clear: while individual engineers are seeing big productivity boosts from agentic coding tools, teams are still constrained by the number of engineers they have and the amount of work each person can take on at a time. You can’t do everything. No matter what tools we currently have access to, we’ve all had to recently negotiate and de-scope work with stakeholders due to time constraints, on-call issues, and bandwidth.
Put simply, a software company that has the necessary tooling to let an agent (or, more accurately, a swarm of agents) introduce new features and improvements without direct engineer intervention will be able to deliver more value to its customers, and faster, than a company that does not.
So…the question still stands: what do engineers do in an environment where agents, not humans, are building all the features?
Building Software in 2029
Now, the necessary disclaimer: I'm not clairvoyant, I'm not a time traveler, I could be wrong, I've been wrong before (many times), I'm not an industry expert, but I do like throwing random numbers around!
That being said, why 2029 and not 2032, 2038? Simply put, the pace the industry has been moving at in the past year alone has been staggering. At the risk of sounding like an “AI bro”, for better or for worse, the art of programming is a dying one. The things (in my opinion) keeping it alive and kicking today are the non-deterministic nature of LLMs, the quality of frontier models, and the lack of widely available production-ready tooling for agent orchestration.
Given that we've already hit multiple inflection points with frontier models, it's naive to think they won't continue to improve. They will remain non-deterministic by nature, but through tooling, better automated context management, and process improvements, the rate at which they make mistakes will inevitably go down. On the agent orchestration side, we've already seen a number of tools surface (LangGraph, CrewAI, Gastown), and over the next few years tools like these will keep improving and becoming more widely adopted.
In three years, the profession will probably look a lot different than it does today, in the same way it looks very different today than it did three years ago. We can probably expect to have seen more of the tech layoffs we've already been seeing these last few years as large companies gravitate toward leaner structures. Despite this, I believe the overall demand for software engineers will actually increase, not decrease (assuming the world is still in one piece by then). To survive, companies need to constantly innovate, and for software companies to innovate, they need software engineers.
The only thing that will change over time is the same thing that has always changed for engineers since the beginning: the type of problems they set out to solve.
Being Prepared
Over the next few years, the profession is likely to go from “person who writes code” to “person who makes it safe and effective for agents to write the code.”
What are some goals to set this year to get ahead of the curve? At risk of stating the obvious, I'll share some personal ones: try to lean more into using agents for everything. Delegate more of your day-to-day work to them: features, refactors, tests, docs, migrations. This gives you a good idea for where they help, where they break, and what’s missing in your setup.
Second, try out building bigger units of work with an agent orchestrator instead of just one agent. Use a swarm/team of agents to build something non-critical with minimal intervention at work: an internal tool, a workflow helper, or a small experimental project. Pay attention to where things get stuck (handoffs, context, permissions, observability) and treat those as gaps in your current workflow that Harness Engineering needs to close.
Third, get very good at workflow and production thinking. In a world where agents generate all the code, knowing how deployments, observability, incidents, and data pipelines work matters more than anything. A useful question to ask yourself: “What would have to change in this pipeline so an agent could safely run it end-to-end?”
Finally, don't limit yourself to being someone who writes code. If you instead see yourself as someone who solves problems and shapes systems, agentic tools end up being more of a tool than a threat. Invest in taste and judgment. Your edge is not out-coding an agent; it's knowing what's worth building, which architecture won’t age badly, and when a change will break prod or expose customer data. That’s part of Harness work too: defining what “good” looks like so any subsequent tooling you build or implement has something concrete to aim for.
Most Importantly
Live, laugh love, have fun!
lost credibility? probably. make it in anyways? absolutely.
The same things you enjoyed about programming when you first learned it, you will also enjoy about working with agents moving forward. The problem solving, the constant influx of new things to try out, the endless need to optimize - it's all still there! While coding agents have definitely democratized programming, the technical skill behind engineering is still as important as ever (even moreso now!).
Happy Hacking!