The prompt gets shorter as the factory gets better
When the code, the docs, the decisions and the checks all point an agent the same way, you stop briefing it like a new hire. You name the business problem, and sometimes you just type “ship it”.
For the last six months most of my work has gone into building the factory: the guardrails, the automations and the checks that keep an agent doing what we want. When people talk about constraining an agent, they usually mean one of two things. The first is the sandbox, keeping an agent from damaging your own workstation. That matters and it needs care, but it is not what this post is about. The second is how the agent knows what it is supposed to do, and that kind of constraint changes how you talk to it.
On the codebases where the factory runs well, my prompts have gotten very short. I no longer explain the work the way I would to a mid-level engineer. I talk to the agent the way we used to talk to Google: a couple of keywords, a phrase. When I type, it is sometimes just “ship it”, and sometimes just 🚢.
Precedent is a constraint
The constraint I mean is precedent. The codebase, the documentation, the architecture decision records (ADRs), the infrastructure, the deployment pipelines and the checks they run all describe the same way of working. An agent that reads all of it would have to go against a lot of precedent to do something you would not expect.
I think of it as social pressure. Everything the agent reads pushes it toward doing what you want, the same way a new engineer picks up how a team works from its code, its docs and its reviews.
In the repository behind this site, that pressure is concrete. The manual at the root says main is production and that work happens on a branch and merges through a pull request. The shared settings deny an agent a push to main. The CI gate runs the same check an agent runs before it pushes, and branch protection will not merge without it.
The ADRs record why the larger decisions were made, such as keeping both of our sites in one repository, so an agent that wonders whether a decision still holds can read the reasons instead of guessing. No single file there tells the agent everything, but together they agree, and an agent that reads them has very little room to wander.
From a brief to a search box
When that pressure is missing, context engineering means precise, detailed language. Make this change, in this module, in this way. Watch this deployment and tell me if this step fails. Tobi Lütke described context engineering as “the art of providing all the context for the task to be plausibly solvable by the LLM”, and early on, the prompt is where all of that context has to live.
Once the factory is humming, the repository holds the context and the prompt does not have to. This post is an example. It started as two words, “New blog post”, and a voice note. I did not say to make a branch, mark the post as a draft, write the social text, storyboard three scenes or open a pull request. The site’s manual and its blog workflow say all of that, so the agent did it.
Agents who have been here for years
The change is in who I am talking to. On a codebase without that precedent, every agent is a brand-new engineer, and I have to explain what we are working on and what we are building. On the codebases where the factory hums, the agents act more like engineers who have built the software for five or ten years. They know its features, how it behaves and where things live.
So when we add a set of features, I explain the business problem, and only the business problem. I do not explain anything about the code. We do not talk about CI/CD, databases or performance, and we do not talk about infrastructure either, because other agents are responsible for it. When a feature needs a new subdomain, those agents set one up.
The words moved into the repository
The words still matter. They used to go into the prompt, written fresh for every task. Now they live in the repository, written once and checked on every change: the docs, the decisions, the pipeline and its checks.
That changes where a person’s time goes. If I do not have to explain the code, the infrastructure or the deploy, I spend the conversation on what should exist and why: who will use it, what it has to do, and how we will know it works. That is the most senior work in the factory, and it is the work that gets the most of my attention now.
Bring us the business problem
We have more than one factory running like this now, and we want more real problems to put through them. That is what our design partners bring. You explain the business problem in your own words, we write the requirements with you, and the factory builds it. If there is a problem you would use software for every week, tell us about it.