Building with coding agents: from brief to testing

We met on 8 September 2026 to discuss how to build software with coding agents and choose models for different stages of the work. We also discussed testing applications that change while you use them. The steps in this recap give you a starting workflow for a new project.

A starting workflow

Follow these steps when you start a project with coding agents.

1. Write a short brief with the user, the happy path, the important states, and acceptance criteria.
2. Ask an LLM to help sharpen the idea, then build a click-through frontend with fake data. The screens force you to name what the app must show and what the backend must eventually provide.
3. Get one working foundation in place under supervision. Connect the main pieces and check that the architecture runs before you give a team of PM, engineer, and tester agents a large amount of autonomy.
4. Ask a strong model to plan the work and write validation steps for each part. Use cheaper models for routine execution when the plan is clear, and let a QA agent send concrete failures back to the engineer.
5. If the app is dynamic, design a test harness that can operate the app and observe its state. A game or other interactive system can't be verified only by checking whether a button exists in the page source.
6. If repeated design iterations have made the code hard to understand, start a fresh session from the brief and rebuild the simplest working version. Compare the result with the accumulated code before you keep any changes.

Lessons from the session

We left the session with these lessons.

• Spec-driven autonomy works best after the project has a working base. If you start a multi-agent team on a broken foundation, it's likely to spend time and model quota on work that's out of scope.
• The frontend can act as a living specification when it captures the user flow before the backend exists. It makes missing states and data needs visible early.
• Use model tiering for long tasks. Spend the strongest model's time on analysis, planning, and acceptance criteria, then use less expensive models for execution and correction.
• Dynamic applications need domain-specific testing. Ask an agent to help design the testing framework when ordinary browser clicks can't exercise the important behavior.
• Switching model providers or plans during a long coding session can keep the same work moving without restarting the session.
• Encode your conventions as skills. A skill is a markdown document an agent follows. The host demoed his library-scaffolding and create-a-repo skills. He built the former by analyzing his existing libraries. Skills tuned to your personal conventions beat generic public collections.

From the live demos

The skill on screen puts pyproject.toml, a Makefile, tests, and CI publish setup into each new Python library.

The host runs agents in the OpenCode harness across many repositories. He can switch between a free tier and a paid plan when quota runs out while the session keeps working:

Next actions

Use this checklist on your next small project.

• [ ] Pick a small project you already understand and write its one-page brief.
• [ ] Build the main user flow as a frontend-only prototype. List every screen state, input, and response the backend must support.
• [ ] Add one real backend path and verify the foundation manually before delegating a larger change to an agent team.
• [ ] Write acceptance criteria and a validation step for the next task. Give the plan to a strong model and the implementation to a cheaper model only if the task is well specified.
• [ ] Create one test that exercises the behavior a real person cares about. For a game, play a round. For a document app, submit a document and check the decision.
• [ ] If the code has accumulated many patches, ask for a from-scratch implementation from the brief and compare file count, behavior, and test coverage.

Write a project brief

Write these five lines before you ask an agent to build:

• Intended user
• One happy path
• Visible states
• Acceptance condition
• Test action after the change

This gives the agent a target it can implement and gives the tester something concrete to verify.