From Prompt to Production: A Day With Shelled
A walkthrough of a single working day where a developer hands goals to a team of coordinated agents and reviews finished, tested pull requests instead of writing every line by hand.
By The Shelled Team
What it actually feels like to build with a coordinated team of agents, from the first prompt of the morning to the last merge of the night.
By The Shelled Team · July 2026
9:12 AM — one prompt, a plan
The day starts with a sentence, not a file. You describe the outcome you want — "add saved searches to the dashboard, with per-user persistence and tests" — and the Planner agent turns it into a set of concrete units of work. It reads the existing code first, so the plan references your real components, your real data layer, and your real conventions instead of a generic template.
You skim the plan the way you would skim a colleague's design note. You reorder two steps, delete one you don't want, and approve the rest. Nothing has been written yet; you are still cheap to change your mind.
9:40 AM — parallel work, one diff
Once the plan is approved, the Builder agents start in parallel. One is writing the migration and the query layer, another is building the UI, a third is wiring the server action. Because they share the plan and the same orchestration hub, they are working against a common contract rather than guessing at each other's interfaces.
You are not watching a chat scroll by. You are looking at a live view of tasks moving from in-progress to ready-for-review. When the work converges, it converges into a single pull request — not four competing branches you have to reconcile by hand.
11:05 AM — the tests come for free
The Tester agent doesn't wait to be asked. As each unit of work lands, it generates and runs tests against it: the happy path, the empty state, the unauthorized user, the duplicate save. When something fails, it doesn't silently patch over the failure — it reports it, links the failing assertion to the code that caused it, and proposes a fix for you to accept or reject.
This is the part that changes the texture of the day. You spend your attention on whether the behavior is correct, not on typing out the scaffolding to check it.
1:30 PM — review, not archaeology
After lunch you open the pull request. It reads like a good human PR: a summary of what changed and why, the plan it came from, the tests that ran, and the decisions the agents made along the way. Each file has context attached, so you are reviewing intent, not reverse-engineering a wall of diffs.
You leave two comments. The Reviewer agent picks them up, applies the changes, re-runs the tests, and updates the PR. You didn't switch branches, you didn't pull anything locally, and you didn't lose your place.
4:00 PM — the long-running task
The afternoon's job is bigger: migrate an old settings module to the new pattern across dozens of files. This is the kind of task that used to eat a whole day of mechanical edits. You hand it off and go do something else. It runs durably — it survives a restart, it doesn't need you babysitting a terminal, and it checks back in when there's something worth your attention.
When it finishes, it has done the boring 90% correctly and flagged the ambiguous 10% for you to decide. That ratio is the whole point.
6:20 PM — merge
The last thing you do is merge. Everything that reaches this point has been planned, built, tested, and reviewed, with a human — you — in control of what actually ships. You didn't write most of the lines. You made most of the decisions.
What changed
The old loop was: think, type, run, debug, repeat, mostly alone. The new loop is: describe, review, decide, merge — with a team of agents doing the work in between and a single reviewable artifact at the end. Shelled doesn't remove you from the process. It removes the parts of the process that were never the interesting part.