A UFO lands outside the office.
Out steps the best software engineer you will ever meet. They know every language, framework, database, cloud, protocol, and architectural pattern. They can read an unfamiliar system, debug from a trace, design an interface, and reason about failures you have not seen yet.
You sit them in front of a computer.
They know nothing about your company.
They do not know what you sell, who uses it, which parts of the product matter, why the architecture looks strange, what happened during last month’s incident, or what you mean when you say the experience should feel simple. They have never met your customers. They do not know which constraints are real and which are historical accidents.
They are extraordinarily capable and completely new.
Luckily, they speak English.
This is the mental model I now use for frontier coding agents. The model does not arrive as an intern waiting to be taught how to program. It arrives as an impossible engineer who can work almost anywhere and has just arrived here.
The practical question is no longer how to make it capable. It is how to give it enough of my world to build what I mean.
The metaphor is deliberately generous. Models still miss things, reason badly, and write the wrong code. I use it to separate two problems that are easy to confuse: knowing how to engineer software and knowing what is true here.
Give the engineer something real
Suppose I ask the engineer to add CSV import to a customer-management screen.
They can build a parser before I finish explaining the task. They know file uploads, background jobs, validation, transactions, progress reporting, and accessible error states. If I say only “build a CSV importer,” I will probably receive a competent version of the wrong product.
The real task sits elsewhere.
Operations receives files from five partners, and none uses the same headers. Some customers already exist. A duplicate email should update one field but must never replace another. A file with one bad row should import the valid rows, then give the operator a corrected file to download. Most files contain five hundred rows; one partner sends two hundred thousand. Only account administrators may run the import, and every change needs an audit trail.
The interface should not celebrate a successful upload. It should help an operator recover from an imperfect one.
None of those facts teaches the engineer how to program. Together, they determine what should be programmed.
I do not need to explain all of them from memory in a giant prompt. I can show two representative partner files, the current customer model, an earlier support ticket, the permission rules, and the existing audit-log pattern. I can explain who performs the work and what goes wrong today. I can point to a neighboring import flow whose restraint and recovery behavior I want to preserve.
That collection is a small world in which the task begins to make sense.
The engineer may have access to a much larger environment: code, tests, screenshots, data, logs, decisions, and the running product. The small world is not a fence around that environment. It is the coherent place I ask them to start. English connects those pieces to my intent, and investigation tells us where to look next.
Luckily, English is enough to begin
I do not need a perfect specification before the conversation starts. I often begin with the messy version: who has the problem, what I have noticed, what I want to become possible, and which parts I still do not understand.
Then I ask the agent to investigate.
Which component owns this behavior? What assumptions do the tests reveal? Does the current data model support partial success? Where are permissions enforced? What happens when the background job dies after importing half the file? Which decision would change if the largest file were ten times larger?
The engineer can inspect the system and return with a better map. I can correct what it misunderstood, answer the questions only I can answer, and find the source for a fact I do not trust myself to summarize.
This dialogue matters more to me than a polished opening prompt. A capable engineer does not need every instruction at once. They need a way to notice what is missing and ask for it before the missing information hardens into code.
English is useful here because it carries more than requirements. I can explain why an apparently reasonable design feels wrong. I can compare two experiences, name a trade-off, reject an abstraction, or say that the dangerous action should feel dangerous. The agent can reflect that back in different words until we know whether we mean the same thing.
The conversation builds the world.
The codebase should welcome a new arrival
I should not have to carry the whole world into every conversation. The codebase can explain much of itself.
In What an AI Agent Should Find in a New Component, I argued that a component should answer four questions: what it owns, how to work there, how to verify a change, and where the tricky context lives.
The engineer from the UFO makes the reason concrete. A clear boundary gives the newcomer somewhere to begin. A short local guide names the working commands and invariants. Tests show which behavior matters. Fixtures provide examples of the world the code expects. Decision records explain why the obvious design lost.
The repository is not the smallest sufficient world. It is the surrounding terrain. A navigable codebase lets the engineer begin with a small map, then move outward without requiring me to anticipate and narrate every dependency.
Build the smallest sufficient world
The phrase helps me resist two opposite mistakes.
The first is giving the engineer too little. “Build a CSV importer” names a feature, not the work. The engineer must invent the user, the failure behavior, the scale, the constraints, and the standard. A strong model can fill those blanks convincingly, which makes the omission harder to notice.
The second is confusing access with orientation. I do not need to hide the rest of the repository or revoke access to connected systems. But dumping every product document, years of tickets, and all of Slack into the opening context does not create clarity. The engineer can have keys to the building and still benefit from being shown the right room first.
I start with what can change the shape of the solution:
The person and problem behind the request
The relevant part of the existing system
Real examples of inputs, failures, and desired behavior
Constraints and decisions the code cannot explain alone
A standard for what good looks like
Evidence that will tell us whether the change works
Then I let the engineer explore. The smallest sufficient world is not a package I can calculate perfectly before the task begins. It is an initial place to stand. The world expands when investigation reveals a dependency, a contradiction, or a question whose answer could change the design.
Before implementation, I want the agent to tell me the world back: the outcome, the current behavior, the likely change boundary, the constraints, the unresolved questions, and the evidence it plans to collect. That is my stopping rule. If it can give an accurate account, the world is sufficient to begin. If the account is wrong or disputed, it also tells me what is missing.
The agent will not always notice the missing piece or ask the perfect question. That is why the playback matters. More code will only make a misunderstanding expensive.
Why my setup became smaller
For a long time, I built more machinery around my agents. I accumulated skills that described recurring workflows and MCP servers that connected external systems. Before starting, I thought about which instructions to load and which tools might make the model stronger.
I reach for far less of it now. I use almost no MCP servers and far fewer skills. Most of the time, I start with a strong model, a repository, a terminal, a browser, and a conversation. That is not a tool-free environment. It is already a remarkably capable one.
The change was not a verdict on MCPs or skills. I had simply been preparing the engineer before I had prepared the work. Another tool could open another door. Another skill could describe another procedure. Neither necessarily told the new arrival which customer was waiting, what had broken, why it mattered, or which constraint should change the design.
Now I begin with the world. If essential live information sits behind an MCP server, that server may be the right door. If a dangerous operation must follow the same local sequence every time, a skill may be the right manual. I add either when it carries something this task actually needs, not because an agent ought to have an impressive collection of tools.
This is personal and task-dependent. A regulated team, a smaller model, or an unfamiliar live environment may need more explicit machinery from the start. My experience is narrower: as frontier models became better general engineers, and as I became better at working with them, I got more value from improving the world I showed them than from expanding the setup around them.
The engineer has arrived
The next time I start a session, I try to forget that I am configuring software.
I imagine that the best engineer in the world has just arrived from somewhere else and taken the chair beside me. They do not need a lecture on loops, APIs, databases, or distributed systems. They need to meet the user, see the failure, understand the existing system, learn what must remain true, and know how we will recognize success.
They can read the code. They can use the tools. They can ask questions.
Luckily, they speak English.
My job is to give them the smallest sufficient world, then let them build.