In the current AI discourse, particularly when AI is unreliable or misused, it’s often pointed out that AI is simply a tool. This is a fair way to think about it. Like any tool, there are things it’s good for and things it’s not. Some people are better at using it than others. Some folks may not be comfortable using it at all.
What is the function of this tool? LLMs are probabilistic text generators, but one useful way to think about them is as translators. They accept one representation — often unstructured language — and produce another, and they do so non-deterministically. Prompts are effectively instructions for how to perform that translation.
LLMs and the growing suite of utilities around them are not just a single tool like a hammer. They are better described as a collection of tools ranging from a child’s toy to a jackhammer. It takes discernment to select the correct tool and, often, skill to maximize its effectiveness.
Structure for Human Understanding
At this point, given what we’ve seen from the frontier labs, we should assume that AI will continue to improve at the task of translating, doing so more quickly and more accurately. This begs the question: what formats are we translating to and from?
In a world where translation throughput increases, we need to put a premium on clear, understandable inputs and outputs. We need structures that can be easily understood and modified by people. By optimizing for humans at these touchpoints, we give users—or sometimes just developers during implementation—a way to wrangle non-deterministic content inside deterministic containers.
A Metaphor
Think of it like air transportation. As frustrating as it might be at times, consider the structure that makes it work. What would it be like if planes could take off or land anywhere, anytime, without any rhyme or reason? Instead, we have structures for ticketing and scheduling, established airports, air traffic control operators, and dedicated security personnel. Each one weaves humans and technology together in a particular way to make the system effective.
Software already works this way. We don’t generally ask people to reason directly about bytes in memory or packets moving across a network. We introduce interfaces, schemas, APIs, design systems, and other structures that expose the parts of a system we actually need to interact with while hiding much of the complexity underneath.
Under the Hood
I think of these as surfaces in the same sense as an API surface. There may be a tremendous amount happening under the hood, but the surface is what has been intentionally exposed so that a person or another system can interact with it.
AI makes these surfaces even more important. The output of an LLM may be probabilistic, but the thing we ask it to produce does not have to be amorphous. We can ask it to translate a conversation into a known structure, stop there, inspect the result, refine it, and only then continue.
If I indicate that I want to translate a transcript into an API specification, I should expect to have: 1) a high level of confidence about what it will contain, 2) good tools for reviewing the specification, and 3) an intuitive interface for adjusting it.
The goal is not to remove the non-determinism. It is to surround it with enough structure that people can understand what happened and decide what happens next.
Selecting the Right Structure
We should be translating to and from the structures that offer the greatest leverage. That means identifying structures that are already integral to the software development process and perfecting the ways we map between them.
A transcript can become a set of personas. Personas can inform user journeys. User journeys can become a list of screens. Screens can become prototypes. Prototypes can inform architecture, and architecture can inform code.
Transcript → personas → user journeys → screens → prototypes → architecture → code
Not every structure is equally useful, though. Selecting one requires more than asking whether an LLM is capable of producing it.
Considerations
First, a useful structure should give a person the ability to inspect and refine it before the next translation happens. This does not mean making every intermediate result into a large formal document. It means creating a meaningful stopping point where the decisions introduced by one translation can be understood before they become assumptions in the next.
We should also consider how much extrapolation a particular translation requires. The capability of the translator matters here, but not in the abstract. The relevant question is whether the model is reliable enough to perform this particular hop unattended. A relatively mechanical transformation might be safe to automate and validate. A translation that introduces new product, design, or architectural judgment should probably end at an inspectable surface.
The ability to replay and evaluate the translation matters too. Replayability gives us a way to evaluate the translation itself, not just the final output. We can run the same source through a different prompt, model, or agent and compare what changed at that boundary. Otherwise, we may only discover a problem several translations later, when it is much harder to determine where it entered the system.
A known standard is useful, but being widely understood is not the same as being interoperable. Markdown is familiar to almost everyone working in software, but most Markdown documents have relatively little semantic interoperability. Other tools can display them, but they do not necessarily know what the content means or what to do with it.
An OpenAPI specification is different. There are already tools that can generate it, render it, validate it, generate clients from it, create mocks from it, and exercise an API against it. Frameworks such as FastAPI can generate the specification directly from the application, and an agent can use that same surface to test whether the API behaves as described.
In that sense, OpenAPI is not merely a standard. It is a hub. Translating into it does not give us one possible next step; it gives us many. That ecosystem creates leverage because other things already know how to interact with the structure.
The Air Transport Analogy Again
This is also where the air transportation analogy becomes more useful. An airport is valuable not only because everyone recognizes what it is, but because it connects to many destinations. When selecting a structure, we should ask how many useful places it can take us.
Transcripts offer a different example. Five years ago, recording and transcribing every meeting would often have felt excessive. Producing, searching, and using those transcripts was expensive enough that meetings were recorded selectively. Now a conversation can become a durable, searchable surface at very little cost. That surface can feed a summary, a specification, a decision log, an evaluation of how the meeting was conducted, or something we have not yet anticipated. The cost-to-leverage ratio changed.
Cost still matters. Every structure has a price: the cost to produce it, the cost to review it, and the cost to keep it useful. The right structure is not necessarily the most detailed one. It is the one whose value as a checkpoint, interface, or hub outweighs the effort required to create and understand it.
The more intentional, connected surfaces an application exposes, the stronger its mesh becomes. Requirements can be compared with an API specification. The specification can be compared with the implementation. The implementation can be compared with its tests. A transcript can be compared with the personas or requirements that were extracted from it.
More surfaces are not valuable simply because there are more artifacts. They are valuable when they give humans and agents additional places to understand the system, act on it, and evaluate one part against another. The complexity exists anyway. Intentional surfaces make it easier to wrangle and leverage.
The capability of the translator will keep changing. A single LLM call becomes an agent, an agent becomes a team of agents, and the tooling around all of it will continue to improve. That should change where we put the stopping points and which translations we allow to run unattended. It does not mean the stopping points themselves become unnecessary.
Better Models Do Not Remove the Need for Structure
There is an obvious objection here: aren’t these intermediate structures just scaffolding? If the models keep getting better, why not eventually translate directly from the conversation to the finished application?
I don’t think that follows, because translation isn’t lossless. Somewhere in most of these transitions, the model has to extrapolate. A transcript does not contain a completed set of personas. The model has to infer them. A set of personas does not contain the user journeys. Those have to be inferred too.
Even a perfect translator cannot verify an idea against information that wasn’t present in the thing it was translating. It may make a highly plausible extrapolation, but plausibility is not the same thing as intent.
Collapsing Two Types of Review
That means there are really two kinds of review happening, and I think we tend to collapse them.
The first is: Did the translation preserve what was already there? That is something we can increasingly automate. We can compare the source and output, check constraints, replay the transformation, and look for information that was lost or altered.
The second is: Is what it added actually right? That requires judgment. The input alone cannot tell us whether an inferred persona, proposed workflow, or architectural decision is the one we wanted.
Those extrapolations also compound. Personas extrapolated from a transcript become the input for journeys extrapolated from those personas. Those journeys become the input for a list of screens, which becomes the input for a prototype. An unreviewed assumption near the beginning of the chain can quietly become the foundation for everything downstream.
Review is More Important Than Ever
That is exactly the argument for putting a stopping point between each meaningful link in the chain rather than reviewing only the finished application. Each structure gives us somewhere to inspect new information before it becomes assumed context for the next translation.
I don’t think this means every intermediate artifact needs to become another document that must be carefully maintained forever. In many cases, these structures are better treated as views over the system. If one becomes stale, regenerate it from the surfaces around it.
That does put more weight on the review step, not less. When a regenerated version disagrees with the version we previously approved, the difference tells us where to look. The extrapolation is where something changed.
The durable record may be the approval, the decision, and its provenance—not necessarily a hand-maintained copy of every intermediate artifact.
Conclusion
The temptation with increasingly capable AI is to remove structure. If the model can take a paragraph and produce an application, why bother with all of the intermediate artifacts?
I think the opposite is true. Better models may reduce the effort required to perform a translation. They do not remove the need to decide whether the information added during that translation was right.
As the ability to translate improves, the structures on either side of the translation become more valuable. A transcript gives us a durable surface for a conversation. A specification gives us something to review and evaluate. An API contract gives both people and agents something they can interact with programmatically. A replayable chain of structures gives us a way to see where preservation ended and extrapolation began.
The complexity was already there. Intentional structure gives us a way to see it, wrangle it, and create leverage from it.
That is where much of the opportunity from AI comes from. Not simply asking the model to do more, but creating better surfaces for it to work across.
The magic of AI is not that structure no longer matters. It is that good structure can suddenly create leverage where very little existed before.