AI engineering sounds fancy. New terms are everywhere: agentic development, AI-native engineering, spec-driven development, and now AI harness engineering. Underneath all the terminology, though, something genuinely useful is happening. AI can now help with requirements, challenge a PRD, explore UX ideas, reason about architecture, create implementation plans, write code and validate the result.
The obvious question is what AI can do. The more interesting question is whether the way we build software is ready for it.
The workflow is changing
A workflow we've been exploring breaks development into five stages: requirements, refinement, planning, build and validation. The stages themselves aren't new, but AI can now participate in each one. It can take existing product inputs, help clarify the problem, question assumptions, identify gaps in a PRD and then turn a well-defined requirement into a plan and eventually implementation tasks.
This puts more emphasis on the quality of the requirements. A human involved in a project might understand what “improve the experience” means because they've had several conversations about it. An agent doesn't have that shared history. It needs the problem, scope, constraints, edge cases and expected outcome to be explicit. That doesn't mean writing enormous specifications; it means using AI to help make the requirements precise before we start building.
AI can actually be a useful, slightly annoying reviewer here, asking what happens when something fails, whether a requirement is testable, whether two parts of the document contradict each other and what we haven't considered yet. It can also help compare different versions of a PRD or have one model review another's output, making gaps easier to spot. The important part is that AI is helping us uncover ambiguity, not making the decisions for us.
Maybe coding isn't the bottleneck
This becomes more interesting when we look at where teams actually spend their time. Complex work can involve several rounds between product, UX, requirements and engineering before development can properly begin. That's often necessary, but it can also create significant bottlenecks. If an AI agent can produce a working implementation quickly, waiting two weeks for a requirement to be clarified becomes a much bigger problem than it used to be.
This suggests that engineers need to be involved earlier rather than receiving requirements only once they're considered finished. UX needs to be part of the conversation early too. A rough prototype or wireframe can expose gaps in a requirement much faster than another round of discussion, and AI makes creating those lightweight prototypes much cheaper. Requirements, UX and technical design can become an iterative loop rather than a series of handoffs.
More documentation isn't always better
The instinct with AI is often to give it more documentation: more PRDs, more architecture diagrams, more wiki pages and more context. But if several documents describe the same capability differently, we're not really giving the agent better context; we're giving it more ways to get confused.
What the agent needs is a way to navigate the system. A clear project structure, focused documentation, useful agent instructions, architecture decisions that explain why something exists and a well-organised codebase can be far more useful than one giant specification. The goal isn't to give AI everything we know. It is to make it easy for AI to find what it needs when it needs it.
The ticket might be the problem
AI also makes me question how we slice work. A ticket that takes weeks or months is difficult for an agent to reason about, and arguably isn't a particularly useful unit of work for humans either. “Build authentication” is very different from breaking the problem into password reset, token validation, password updates and the associated tests.
That doesn't mean turning every feature into dozens of tiny tickets. We just need work that has a clear purpose, manageable scope and a definition of done. If something takes months, it might be a project hiding in a Jira costume.
At the same time, not everything needs the full AI lifecycle. A large feature may benefit from structured requirements, refinement, planning and validation, while a small BAU change might only need a prompt and a developer. If we apply the same process to everything, we risk replacing one form of bureaucracy with another. The workflow should match the complexity of the work.
The agent needs to see the real system
There is also a fairly fundamental requirement: the agent needs to understand the real system. Giving it a PRD without access to the relevant codebase means it is still making assumptions. With the code, it can find existing patterns, understand constraints, reuse functionality and spot when a proposed solution doesn't fit.
Of course, giving AI access to source code introduces security, licensing, privacy and organisational considerations, so AI adoption isn't simply a matter of choosing the right model. Some of the biggest barriers have nothing to do with the model at all.
And once multiple developers and agents are working in parallel, things get even more interesting. Each agent has its own context and can make decisions based on what it currently sees. One agent can change something another doesn't know about, or two agents can make perfectly reasonable decisions that don't work well together. This makes good engineering practices even more important: small changes, clear boundaries, good tests, frequent reviews and consistent project rules.
So, are we ready?
Probably not completely, and that's fine. We don't need to jump straight into autonomous software development. We can take real pieces of work, try these workflows, see where they break and improve the process as we go.
Because AI isn't just changing how quickly we write code. It is exposing everything around the code that slows us down: unclear requirements, oversized tickets, late UX involvement, documentation drift, handoffs, access restrictions and decisions that take days to make.
That's why I think the idea of an AI harness is bigger than prompts and agent configuration. The harness is the environment we create around the AI: how we define work, how product, UX and engineering collaborate, how knowledge is structured, how repositories are organised, how work is validated and what access the agent has.
The AI might be the new part, but the way we work around it is what will determine whether it actually makes us faster.
AI engineering is easy. Changing how we work is hard.
Top comments (6)
This is a great point about how AI is exposing the real bottlenecks in software development rather than simply making coding faster. The emphasis on requirements, context, validation, and giving agents access to the real system is especially important. It also aligns with what GeekyAnts has been emphasizing around AI product engineering: the value isn't just in adding AI to development, but in building the right engineering environment around it. The idea of an AI harness as the layer connecting requirements, code, knowledge, and validation is particularly interesting. That's likely where a lot of the real productivity gains will come from.
Thanks! Yeah, I think the really interesting part is what happens when the harness becomes more than just a layer around the agents and starts shaping how the whole engineering workflow works. That’s probably where we’ll see some of the bigger changes.
Reading this article just made it clear for me that AI just exposes the bottlenecks we had before. I also agree that we are still in the process of figuring things out. Best practices are still being explored in this new age of AI.
Thanks, Elmar! That’s been my biggest takeaway too. I think we’ll see quite a bit of experimentation over the next couple of years before some of these practices become more standardised. It’s a pretty interesting time to be figuring it out.
This actually echoes something @julies1 said in another discussion we were having on: Too cheap to be good? Think again.
I think your article does a very good job of showing both sides of AI engineering: how much AI can contribute, but also where its limitations become apparent.
There is perhaps one point I'd put a little more emphasis on, though: the human is still the inventor.
AI can implement a solution, refine it, question it, and even help verify it. But it doesn't originate the need, nor — at least for now — the conceptual leap that turns a problem into an idea for a solution.
That's increasingly how I see my own role: I invent, conceptualize the problem and the solution, define the broad architecture and constraints, and let AI turn that into working code. Then I review and test what it produced.
So perhaps the real shift isn't that AI replaces the programmer, but that it changes what being a programmer means. The implementation becomes less central, while understanding, invention and architecture become more important.
Thanks, Pascal! I think that’s where it gets especially interesting. If implementation becomes cheaper, the value shifts towards deciding what’s worth building in the first place. That probably also changes how we think about the role of engineers and where we bring them into the process.