Intent Engineering: The Coding Skill AI Agents Still Can't Replace
As AI coding agents improve, intent engineering, not prompt tricks, is becoming the skill that determines whether their output is actually useful.
What is intent engineering in AI coding?
Intent engineering is the practice of making sure an AI coding agent understands what you actually want to build, not just what you typed into a prompt. As coding agents get better at writing correct, clean code, the bottleneck shifts away from syntax and toward communication. The agent can produce working software from almost any instruction. Whether that software matches what’s in your head is a separate problem, and it’s one that doesn’t go away as models get stronger.
This distinction has become urgent because of a viral GitHub repository called “Reverse Engineer Anything,” which uses an MCP (Model Context Protocol) server and a well-built agent harness to let coding agents recreate existing applications with striking accuracy. The project has been held up online as proof that AI has basically solved software engineering. That reading misses what’s actually going on, and understanding why matters for anyone deciding which skills are still worth developing.
TL;DR
- Agents can’t read your mind, no matter how capable the underlying model gets, so someone still has to translate a vague idea into something concrete enough to build against.
- Reverse Engineer Anything works so well because the target application itself is the specification: the agent can constantly check its output against a real, running reference, which removes almost all ambiguity.
- Most real-world coding tasks don’t come with that kind of reference, which means the person requesting the work has to build one, through planning documents, examples, or visual references.
- Becoming a “meat proxy”, forwarding a request straight to an agent and relaying its output without review, adds no value and leaves you responsible for mistakes you never caught.
- Harness engineering, the scaffolding of questions, validation steps, and reference material around an agent, matters more as models get stronger, not less, because it’s the mechanism that keeps powerful agents aimed at the right target.
- A simple test for whether a skill is still worth learning: ask if doubling the power of the next model would make that skill matter more or less. Skills tied to communicating intent pass that test; skills tied to syntax or rote prompting generally don’t.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Why does Reverse Engineer Anything work so well?
The repository lets someone point an agent at an existing piece of software and have it rebuild a working version, using an MCP server and a carefully designed harness around the coding agent. The quickstart is genuinely simple, which is a big part of why it went viral.
But the simplicity comes from a specific property of the task, not from some general leap in agent capability. When you reverse engineer an application, the application itself is the intent. There’s no ambiguity to resolve because the finished product already exists. The agent can run its in-progress build next to the original, compare behavior and features, and get a reliable, repeatable signal on whether it’s done. That tight feedback loop, not just raw model intelligence, is what makes the task tractable.
Most software isn’t like this. Most of what gets built starts as an idea in someone’s head, a half-formed feature request, or a ticket written by a teammate who didn’t specify edge cases. There’s no reference app sitting there to diff against. In that far more common situation, the agent has nothing reliable to validate itself with unless a person supplies it.
Why doesn’t better AI eliminate the need to communicate intent?
Because intent isn’t a technical problem, it’s a human one. A more powerful model can write cleaner, more correct code from the same prompt, but it can’t infer requirements that were never communicated. If a bug fix needs to account for a specific edge case that only makes sense given business context, or a feature needs to feel a certain way to users, no amount of raw model capability substitutes for that information actually reaching the agent.
This is the trap of becoming what’s sometimes called a “meat proxy”: taking a request, forwarding it to a coding agent with no planning or context, and then relaying the output back without real review. In that scenario, the agent is doing all the thinking, but the human is still the one accountable for the result. If the output misses the point, that’s not a model failure. It’s a failure to communicate intent in the first place, and the responsibility for the output still sits with the person who shipped it.
The deeper problem is that this failure often isn’t visible on the surface. The code runs. It looks reasonable. It might even pass tests. But it solves the wrong problem, or solves the right problem in the wrong way, because the person who asked for it never did the work of making their intent concrete.
How do you build a harness for communicating intent?
The practical answer is: give the agent something to validate against, or build that something yourself if it doesn’t already exist.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
Reverse Engineer Anything gets this for free because the target application is the reference. In normal development, you have to construct the equivalent. That can take the form of a detailed planning document (sometimes called a PRD), a set of examples, or a visual reference the agent can compare its output against.
A concrete illustration: building a game with an autonomous coding pipeline (what’s referred to in the source material as a “software factory”) that takes a planning document and splits it into tasks the agent executes one at a time. An initial 2D version of the game turned out well as a proof of concept, but it wasn’t what was actually wanted. The original intent was a 3D game, and that intent was never successfully communicated up front, because describing 3D visual style in text alone proved difficult without a design background to draw on.
The fix wasn’t a better prompt. It was borrowing the visual style of an existing game (in this case, a Zelda title with a distinctive semi-3D look) as an explicit reference, then structuring the build process so the agent compared its output against that reference repeatedly during development. That single change, adding a concrete reference and a validation loop around it, succeeded where several earlier attempts at describing the same intent in words had failed. The model being used was a current top-tier LLM with an elaborate harness already in place. The missing ingredient wasn’t model power. It was a reference to communicate intent against.
Is prompt engineering still worth learning?
Less than it used to be, and that gap will likely keep widening. Prompt engineering, in the narrow sense of finding clever phrasings or rule files to coax better output from a model, is the kind of skill that erodes as models improve. A more capable model needs less linguistic massaging to understand a well-specified request.
Intent engineering is different. It’s not about phrasing, it’s about specification: making sure the thing you want is defined clearly enough, with enough reference material or structured planning, that any sufficiently capable agent could execute on it correctly. That skill doesn’t erode as models improve. If anything, it compounds, because more capable agents can act on well-specified intent with less hand-holding and bigger scope, which raises the stakes of getting the specification right.
A useful way to sort which skills are worth your time: imagine the next model release doubles in capability. Does the skill in question become more valuable or less? Memorizing syntax, hand-writing boilerplate, or crafting prompt-phrasing tricks tend to matter less as models get stronger. Planning, specifying requirements clearly, choosing and building references, and designing the validation loop around an agent tend to matter more, because they’re exactly the inputs a more capable agent needs in order to aim its extra capability at the right target.
Frequently Asked Questions
What does “intent engineering” mean in the context of AI coding agents?
It refers to the practice of clearly specifying what you want an agent to build, through planning documents, examples, or reference material, rather than relying on a vague prompt and hoping the agent infers the rest.
Why did the “Reverse Engineer Anything” repository go viral?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
It lets coding agents recreate existing applications with an unusually simple setup, using an MCP server and a well-designed harness. It got attention because it’s easy to use and the results look impressive.
Does Reverse Engineer Anything prove AI agents can now build anything?
No. It works well because the application being reverse engineered is itself the specification, giving the agent a perfect, constantly checkable reference. Most development tasks don’t come with that kind of built-in reference, so the comparison doesn’t generalize.
Why can’t a more powerful AI model just infer what a developer wants?
Because intent often depends on context that was never communicated, like business logic, edge cases, or stylistic preferences. A stronger model writes better code from the same input, but it can’t recover information that was never provided.
How do you know if a coding skill is still worth learning as agents improve?
Ask whether a significantly more capable future model would make that skill matter more or less. Skills centered on specifying intent and validating agent output tend to matter more over time, while narrow prompting tricks tend to matter less.
