Agentic software development: PRD to PR without code
- David Turner
- Jul 21
- 9 min read
Updated: Aug 25
From PRD to PR without code
The gap between a written product concept and working, tested, version-controlled code can now be closed without a developer writing a line of application code. From PRD to PR without code, automation is happening already.
To demonstrate, I created a project called 'FinFlow'. A command-line FX rate tracker: fetch live exchange rates, store them locally in a SQLite database, fire a terminal alert when a rate crosses a defined threshold. Functional enough to be real, yet simple enough that if something went wrong you'd know where to look.
The point of the exercise is the process, not the application. And the process was handled almost entirely by my team of Claude agents.
The workflow
A Claude-generated Python script ran the entire development cycle.
Here's what it did:
It read a brief Product concept, a plain English description of what the software must do, which files it must produce, and what tests must pass. That document is the only thing I wrote in the process.
It generated and sent a PRD to the Claude API. Claude returned the complete codebase, with each file wrapped in a delimiter the agent could parse. The agent wrote every file to disk.
It automatically ran pytest against the generated code.
If tests failed, it sent the failure output back to Claude: here is what broke, fix it, return everything again. Claude returned corrected code. The agent overwrote the files and ran the tests again.
Steps three and four repeated until either tests passed or a retry limit was reached.
When tests passed, the agent committed the code to a new branch, pushed it to GitHub, and opened a pull request.
I wrote the spec at the start, then reviewed and merged the PR at the end. Everything between was automated.
What makes it agentic - and why the word matters
Agentic gets applied to things it doesn't fit. Here it meant something specific: the system observes the outcome of its own actions and changes its behaviour in response.
A simple script calls an API and writes files. An agent calls an API, writes files, checks whether the result is correct, and loops back with new information when it is not. The feedback from the test runner feeds directly into the next prompt. It is not executing a fixed sequence, but rather responding to evidence.
That distinction should be made clearly. The difference between a tool that requires a human to interpret every output and one that can drive itself to a defined success condition is not a degree of sophistication, but a different category of capability.
The efficiencies - obvious and less obvious
Speed is the obvious one. Boilerplate, database wiring, test scaffolding: under a minute. A developer writing the same from scratch would spend hours on those alone before touching the logic.
The less obvious efficiency is consistency. The PRD is the single source of truth. Every file, every test, every docstring traces back to it. When requirements change, you change the PRD and regenerate. There is no drift between what the spec says and what the code does, because the code was derived directly from the spec.
There is also a forcing function on clarity that is easy to underestimate. Vague requirements produce vague code. When the agent missed the test file three times in a row, that was not a model problem, but a prompt engineering problem. The discipline of writing a spec precise enough to produce reliable output is the same discipline that produces good software requirements in any context. The agent just enforces it faster.
The limits, and where the guardrails need to be
The tests are only as good as the spec. If the PRD does not describe edge cases, the tests will not cover them. Garbage in, garbage out applies here exactly as it does everywhere else in engineering.
Generated code needs human review. The agent does not understand the code it produces. It generates something that passes the tests it was given. A subtle logic error that does not manifest in tests will not be caught. Code review before merging is not optional.
The retry loop has a cost, in that each call to the Claude API is pay-per-use. A poorly written PRD that causes repeated failures across five retries costs five times as much as one that converges first time. There is a direct financial incentive to write a good spec.
For a project this size the total cost was under a dollar, but naturally the principle scales.
Secret handling must be established before anything else runs. API keys in a .env file, .gitignore in place before the first commit, no credentials in generated code. One accidental push with a key in it and the key is compromised. GitHub will flag it, but by then it is already in the history and a crawler has picked it up.
Where the human in the loop belongs
Fully autonomous is not always the right target. For most real work, the checkpoints are as follows: before the agent runs, after generation before tests, after tests pass before merge, and when the retry limit is reached.
The PRD is the most important human contribution in this workflow. Time spent on it is not overhead - it's the source of all subsequent execution. A precise spec is the difference between an agent that converges in one pass and one that burns through retries and tokens and still misses the mark.
The pull request is the natural endpoint checkpoint. Automated tests passing is necessary but not sufficient. The PR is where judgement lives.
What this is and isn't
It's not a replacement for understanding how software works. The agent writes the code. A developer still needs to read it, reason about it, and catch what it misses. The workflow amplifies someone who already knows what they're looking at.
It' not production-ready infrastructure out of the box. The patterns - PRD discipline, automated testing, feedback loops, PR-based delivery - are sound. Applying them at production scale requires more rigour around security review, dependency scanning, and deployment gating than a weekend project demands. That rigour is not difficult to add. It just has to be added deliberately.
What it demonstrates is that the process of moving from a clear description to working, tested, version-controlled code is now automatable. Right now, with tools that cost under a dollar to run. The question worth asking is not whether this is possible. It is how long before the organisations that ignore it find themselves explaining to someone why their software delivery costs what it does.
The stack, for reference
Everything used was free or open source, with one exception. Python 3.12, pytest, Git and GitHub, SQLite, frankfurter.app for FX data - all free. The Claude API is pay-per-use and separate from a Claude.ai subscription. For a project this size: under a dollar (NB: Anthropic always charges and quotes in USD, which is why I don't quote GBP here).
Worth knowing before you start rather than after you hit a credit error mid-run and waste time diagnosing and fixing the issue. Free alternatives exist however. Ollama runs open-source models locally at no cost, Groq offers fast inference on a free plan, and swapping the API client is only a minor code change.
From prototype to product: adding a dashboard to the FinFlow agentic build
Part one closed with a working command-line FX tracker, built from a spec by an agent, tested, and delivered via pull request without a developer writing application code. The CLI fetched live GBP rates, stored them in SQLite, and fired terminal alerts when a threshold was crossed. However this was functional rather than visible, and so wouldn't meet MVP criteria in the real world (unless you're SAP of course...)
A command-line tool is not something you hand to someone and have them understand in thirty seconds. A browser dashboard is. The second phase had a clear brief: seven currency pairs on screen at once, sparklines showing rate history, 24-hour change indicators, alert management without touching a terminal.
The next question was where to start.
The problem with writing a UI spec blind
Writing a PRD for a UI without first seeing the interface is an exercise in guessing. You describe what you think you want, generate it, discover you forgot something, re-describe it, and loop. Each cycle touches requirements you thought were settled.
So build a visual prototype first. Then use what you learn to write the spec.
Anthropic released Claude Design in April 2026 as a research preview - describe what you want, get a high-fidelity interactive prototype, refine through conversation. The instinct is to treat it as a delivery tool: generate, export, ship. That is not how it turned out to be useful here.
One prompt produced a working prototype in under a minute. Dark terminal theme, currency pair cards with rate displays and spark-lines, alert panel on the right, status bar at the bottom. Closer to the finished product than anything a written description alone would have produced.
Looking at it immediately surfaced decisions the spec had not addressed. The prototype defaulted to GBP as base currency across all seven pairs - was that right, or did the dashboard need a mixed basket? The sparkline charts required stored rate history - did the existing backend support that? The alert form showed above and below direction controls - did the existing alert logic match?
Three decisions that looking at a picture answered faster than writing about them.
That's the value of using a fast AI-prototype as a tool. Use Claude Design almost as a focus or user-testing group. See which features it surfaces and decide whether they're relevant and/or feasible. As the model is trained on existing UIs, there's a good chance it will add useful features and functions to the prototypes.
What the prototype revealed
Reviewing the prototype against the actual codebase clarified what needed building and what already existed.
The rates table was already a time series. Every fetch had appended a new row with a timestamp. The sparkline data was there, waiting for a query that read it correctly. No schema changes required. The alert logic used low and high thresholds per pair - the prototype's direction controls mapped directly onto those. No mismatch.
What was missing was an HTTP layer. That meant a Flask API in front of the same database the CLI was already writing to.
Two things to build from scratch. One thing to extend and nothing to rewrite. A spec-first approach would not have surfaced the time-series question until the generated prototype came back without sparklines. Prototyping first found it before the spec existed.
The build: three phases and tests at every layer
Nothing moved to the next phase until the current phase had passing tests.
Storage first. Two new functions on the existing storage module: time-series data for spark-lines, and current plus previous rates for all seven pairs to calculate 24-hour change. Ten tests, all passing.
API second. Six Flask endpoints covering rates, history, alerts, and status. Port 5001, not 5000 (as macOS reserves port 5000 for AirPlay Receiver, which announces itself via a generic connection refused error that does not mention AirPlay) . Twenty-three tests, all passing.
Dashboard third. A single HTML file, no build step. Vanilla JavaScript, Chart.js from CDN for spark-lines, JetBrains Mono for the rate digits. The dashboard polls every thirty seconds and flashes cards green or red on change. Alert creation and deletion update in real time without a page reload.
One problem had nothing to do with code logic. Opening the HTML from disk produced a blank dashboard - a CORS violation: a page loaded from the local filesystem and a server at localhost:5001 are treated as different origins. Fixed with a single Flask route serving the HTML directly. Obvious in retrospect, not obvious in the moment.
Where the project stands
Forty-three tests across three files; storage, API, and the original CLI suite. All passing. CLI and dashboard read from the same database without duplication.
The data is ECB rates via frankfurter.app updated once per trading day. The 24-hour change indicator shows movement between sessions, not tick by tick. That's due to the data rather than the code.
The missing piece is a background scheduler. Rates fetch manually now. A process that fetches automatically on an hourly schedule - and the rates table exists, the API exists, the alert logic exists - completes the stack.
The workflow, updated
The original workflow: write spec, generate code, run tests, fix failures, open PR.
Add one step before the spec. Build a prototype. Use what you discover to make the decisions you did not know you needed to make. Then write the spec.
The prototype is not the deliverable, but the thinking. For anything with a visual surface, doing the thinking before writing the spec produces a better spec.
That sequence is not complicated, it's just easy to skip.
Conclusion
As ever the conclusion here is about the tools and process as opposed to the subject matter of the project. Armed with a Claude Pro subscription and an hour of time, it's possible for one person to build, test and design a working UI for the first version of a product they've described only in plain English. Scale this process up with the correct guardrails and policies in place, orchestrated by an engineer with the requisite technical, regulatory and product expertise, and you have a huge efficiency gain.
This means in real terms you can compress the early stages of your SDLC and achieve first production-intent prototypes ready for validation, much faster than before. It means you can compress much of the code, test and verification phases afterward too, hitting launch dates earlier.
Before jumping in with both feet though, you still need to be aware of the same risks that apply to any tool or vendor. Token costs may increase, AI models may be inconsistent in performance as updates are rolled out, test phases need to be analysed and reframed if necessary. And validation of the user-experience is still non-negotiable - AI can't begin to imagine some of the real-world use cases that people find themselves in.
Full codebase at github.com
David Turner is the founder of Kói, an independent strategic consultancy advising investors, founders, and boards on technology.
You can reach him at: enquiries@dkoi.design
© Kói Holdings Ltd 2026. All Rights Reserved.
