On this page
There’s a genre of AI demo where an agent builds a todo app from one sentence, and everyone claps, and nothing is learned. This is not that. This is what happened when I pointed Claude Code at an empty directory with one long prompt describing a vision — a self-improving analysis and trading agent for XAU/USD (gold) — and let it run for hours, autonomously, to see what a real greenfield session produces.
The session transcript ended up at tens of megabytes. Here’s the honest accounting.
The prompt was the engineering
Calling it “one prompt” undersells the prompt. It carried the vision (what the system is for), the constraints (the instrument, the data source it would eventually attach to), and — implicitly — permission to make decisions without me. The single biggest factor in how the session went was what that prompt did and didn’t pin down. Greenfield autonomy doesn’t remove design work; it front-loads all of it into the brief.
What it did first surprised me: research
Before writing code, the agent spent real time in a research phase — working through the domain: how gold trades, session structure across Asia/London/New York, what an analysis platform for this instrument needs to model. Then it started building, and the research visibly shaped the code that followed.
That ordering is worth stealing even when humans build. The worst greenfield codebases are the ones where domain understanding arrived after the module boundaries were set. Here the boundaries came out of the research.
What a multi-hour autonomous session produced
By the end there was a real Python package — src/gx/ — not a script pile:
- Core domain modules for the unglamorous foundations: the instrument’s specification, units and conversions, and the trading calendar. The agent built the boring bedrock first, unprompted — which is exactly what a disciplined human would do and exactly what a rushed one skips. Getting units and sessions wrong is how trading systems produce confident nonsense, and the agent treated them as first-class.
- A strategy family, not a strategy. The first concrete strategy was built around the Asia-session range — as a family of variants under a shared structure, so the strategy layer had a shape other strategies could slot into.
- A fast test suite. Tests came along with the code, not after it, and they were quick enough to run constantly — which is what made the long autonomous stretch safe to leave alone. Every few minutes, the agent was re-verifying its own work.
- ADRs — written decision records. The agent documented its own architectural choices as it made them: what was decided, what was rejected, why. In a session where I wasn’t watching every step, the ADRs were how I audited the thinking afterwards. For autonomous work, decision records aren’t documentation hygiene; they’re the accountability mechanism.
- A
justfilewiring up the developer workflow — test, lint, run — so the project was operable, not just present.
What held up, and what needed me
Held up: the skeleton. The package structure, the domain foundations, the test discipline, and the decision records were genuinely good — comparable to what a careful senior engineer would lay down in the first days of a project, compressed into hours. Weeks later, the structure was still the structure.
Needed me: direction and taste. Autonomy drifts — not into nonsense, but into plausible elaboration: another variant here, another abstraction there, each locally defensible, collectively pulling toward a bigger system than the vision required. The corrective wasn’t reviewing diffs line-by-line; it was periodically re-asserting what actually mattered and letting the agent re-align. The agent optimizes the brief. Only I know when the brief itself has gone stale.
And judgment about markets stayed entirely on my side of the table. The agent can build the machinery around a strategy; whether the strategy premise deserves machinery at all is not a software question.
Where this mode is appropriate — and where it isn’t
After this session I have a clean rule.
Autonomous greenfield is appropriate when the cost of a wrong decision is a rewrite you can afford. An empty directory is the safest possible blast radius: no users, no data, no colleagues, no production. The worst case is deleting a folder. In that setting, hours of autonomous building is an extraordinary deal — you’re buying a full, coherent, tested first draft of a system for the price of one well-written brief and a review.
It is not appropriate for production changes. Existing systems carry constraints that live outside the repo — operational realities, customer promises, the reasons things are the way they are. An autonomous agent in that setting optimizes what it can see, and what it can’t see is precisely where incidents come from. My production workflow is the opposite of this post: tight review, adversarial checking, small steps.
The mistake people make is treating these as one question — “can AI build software autonomously?” It’s two questions. In a blank directory, yes, startlingly well. In a live system, the constraint was never typing speed.
The takeaway
One prompt really did become a structured, tested, documented platform foundation in an afternoon. The magic wasn’t the autonomy — it was that the agent, left alone, defaulted to discipline: research before code, foundations before features, tests alongside everything, decisions written down. That’s a better default than most codebases I get called in to rescue.
The vision still has to be yours. The taste still has to be yours. But the blank-page phase of a project — the weeks of scaffolding between idea and first real feedback — has quietly stopped being expensive. I don’t start greenfield projects any other way now.