The Craft of AI
How we shipped a full product in 8 weeks
Architecting a software factory with engineering best practices
By Luke Lin · · 6 min read
In mid May, Moda’s venture studio made the first commit on a new product. By early July our first design partner was using it. That’s about 8 weeks, with one engineer and PM shipping a full product to an end user. Later, we brought on a 2nd engineer to accelerate the work.
We wrote our engineering process down as skill files and deployed it as a shared engineering agent the whole team uses. Now, we ship quickly and confidently, knowing that we have all the checks in place to avoid slop and tech debt.
Before: individual setups and no shared definitions
Before this project, each engineer on the team had their own Claude Code setup, with different skills and different workflows. Our agentic engineering best practices lived inside individual orchestrated sessions, with no standard on quality or process.
We saw increases in our team velocity, but we also noticed some meaningful limitations.
Quality depended on the person. Output quality depended on who was at the keyboard, with their definitions of quality and what they thought was sufficient in terms of reviews and checks.
Review bottlenecks from disparate processes. Because everyone had their own process, we noticed a bottleneck at the review stage, where we still had to enforce our level of rigor and quality before merging code.
Limited PM involvement. Our PM (it me) could contribute code, but only for offline pieces like eval suites, where a mistake wouldn’t reach the user.
We had solid practices scattered across the team, but we hadn’t defined the agentic engineering practice we wanted to follow as a team. When we defined that as a shared skill, it allowed us to all work in a more coordinated way both from our terminals and from deployed agents.
After: codified agentic engineering
So we codified the team’s practices into two roles inside one shared agent: a planning role and a build role. Each one draws on a shared library of skill files and deterministic workflows, and picks from it depending on the job.
Plan. The planning role goes through a deterministic process that produces a high quality technical design and implementation plan that the engineer can approve.
It researches the codebase, outlines the changes required to meet the spec from the engineer, hunts for edge cases, and writes a plan that’s both human readable and sufficiently detailed for implementation agents.
Every phase of the plan ends in a proof-of-work gate to eliminate hallucinations. Before approval, the plan is reviewed from several independent adversarial angles, before final human signoff.
At the end of the phase, we have a high quality design document checked into source.
An example of how I plan new features with Baohua, using our skills
Build. The build role takes the approved plan and goes through another deterministic process, mimicking the entire software development lifecycle, complete with checks and balances specifically designed to reduce the types of problem AI creates when coding.
- Scope and design. Read the plan and restate the acceptance criteria. Any ambiguity gets resolved first, before code is written.
- Worktree and setup. Automatically branch from a fresh main into an isolated worktree. One unit of work gets one branch and one PR.
- Checklist and itemized breakdown. Break the work into a checklist and commit it before starting, so a session that dies loses the item it was on and keeps the rest.
- Implement and write code. Write code. Survey the touched code before editing it. For a bug, find the root cause and write the failing test first.
- Test the outputs. Run the unit tests suite and add tests for the new logic. Every suite must be green before the next stage starts.
- Verify the impact. Drive the affected flow in a browser end to end and observe the changed behavior directly. Record the flow for proof of work.
- Document the work. Update every doc to ensure there aren’t any stale references or out of date collisions, on the same branch and in the same PR.
- Complexity review. One of the most important steps. Review the changes and make sure the work did not add complexity unless it was absolutely necessary.
- Adversarial review. Standard adversarial code review from a high reasoning agent. Fix every blocking or major finding and re-run the affected tests.
- Land the PR. Open the pull request with the test evidence, the complexity verdict, and the review verdict attached. Resolve merge conflicts and CI issues automatically.
How I use build to quickly deliver features now, with Baohua
How we use it
These agent roles live in our moda-skills repo, where they feed both our deployed agents and as skills we can utilize in any terminal session.
Planning in the terminal: We do most of our planning in the terminal so that we can have interactive discussions with high level reasoning agents.
Building via deployed agents. We have a deployed engineering agent on Bobi, our open source framework for event-driven agents. The deployed agent picks up work in real-time via webhooks when we approve the design and it goes through the entire build process, resulting in a landed PR.
This allows us to plan features interactively, dispatch an autonomous agent to handle the engineering work, and come back to a PR that we can review and merge.
The impact
Since we’ve started building like this, our product and engineering team has transformed how we get products built.
Overall velocity went up. The team landed around 300 commits in the first month with just one engineer and PM, and we delivered a fully built product within 2 months to our first design partner. We’ve achieved velocity gains without losing out on quality.
Our PM submits work. As the PM, I went from offline eval suites to shipping UI features and bug fixes end to end. This is because I’m now confident that the engineering agent I dispatch will go through the same rigor as my CTO’s agent.
We manage engineering from Slack. We create issues, review them, and have an engineering agent do the work, and we manage all of it from Slack. We hand off work in a thread and the results get reported back in that thread. This lets us run and track several builds in parallel from one place.
Our CTO put it this way:
Establishing our best practices as a common deployed agent allowed our entire team to contribute to the codebase with confidence that we weren’t shipping slop, but actually balancing velocity with quality.
What’s next
The product we built is in validation with its first user cohort, and we keep refining the planning and execution agents as new kinds of work appear.
Other projects, like Baohua, also build new features and manage the software using these same agent teams.
Today the system covers engineering. It picks up at an issue and ends at a pull request.
Next, we’ll connect it to the other parts of the product development process, like PRD management and design. We’re excited to see how this same paradigm scales beyond software factories into product factories.
KEEP READING
