From Up-Front Design to Iterative Design
Move from heavy up-front design to fast AI-assisted loops where structure is discovered through small implementations, reviews, and refactoring checkpoints.
Key takeaways
- Move from heavy up-front design to fast AI-assisted loops where structure is discovered through small implementations, reviews, and refactoring checkpoints.
- Use this chapter as a first-pass operating checklist before changing systems, data, permissions, or customer-facing workflows.
- Validate platform-specific details against current official docs or internal policy before rollout.
"Design enough before you implement" was sound advice because implementation used to be expensive. Agentic coding changes the cost model. When implementation and rework become cheaper, design can become more iterative.
Why Big Design Up Front Made Sense
| Era | Implementation cost | Change cost | Best design strategy |
|---|---|---|---|
| Waterfall | Very high | Extremely high | Heavy up-front design |
| Agile | Moderate | Manageable | Enough design, then iteration |
| Agentic coding | Low | Low for many code-only changes | Minimal design, fast validation loops |
Observation-based model
These are conceptual weights, not universal percentages. The useful insight is the direction of the cost shift.
Feedback Loops Matter More Than Documents
For an order notification system, a traditional design may introduce interfaces, strategies, formatters, factories, queues, and retry abstractions before the first real use. A lightweight agentic loop might begin with:
When an order status changes, send email and Slack notifications. Retry failed sends three times.
Keep the structure easy to extend with new channels later.The first generated version may have three files. After review, you can ask for a channel registry, error logging, delivery history, or transactional boundaries. Structure emerges from validated pressure instead of imagined future needs.
YAGNI gets stronger
If adding the missing abstraction later is cheap, creating it before the need is proven becomes harder to justify.
When Up-Front Design Still Wins
Iterative design is not universal.
| Criterion | Up-front design fits | Iterative design fits |
|---|---|---|
| Blast radius | Cross-team public interfaces | Internal implementation |
| Failure cost | Security, payments, healthcare, compliance | Routine business logic |
| Requirement stability | Legal or standards-driven requirements | Product behavior likely to change |
| Rollback cost | DB schema, public API, data migration | Code-only changes |
| Coordination | Multiple teams must agree first | One team can iterate safely |
Document vs Prototype
| Item | Design document | Working prototype |
|---|---|---|
| Ambiguity | Natural language can be interpreted differently | Code reveals actual behavior |
| Edge cases | Imagined | Discovered by execution |
| Team communication | Text explanation | Demo and tests |
| Maintenance | Must stay in sync with code | Code and tests are evidence |
| Initial cost | Can be high | Often cheap with AI |
This does not mean documents disappear. It means documents should capture intent, constraints, and decisions, while prototypes test whether the design survives contact with code.
A Lightweight Iterative Design Loop
- Write the intent in one paragraph.
- Add hard constraints and non-goals.
- Ask AI for a minimal implementation plus tests.
- Run the tests and inspect the shape.
- Add one design pressure at a time: extensibility, observability, performance, or safety.
- Stop when the structure fits the current risk.
Next
Read Prompts Are Design Language to turn this loop into repeatable prompts.