A manifesto for building with AI
Understand before
you accelerate.
AI helps us write code faster. Understanding helps us build the right thing. A shared approach to planning, reviewing, and delivering software with intention.
The order matters.
- 01
Understand
The outcome. The context. The unknowns.
- 02
Decide
Shared evidence. Clear responsibility.
- 03
Build
AI-assisted. Human-owned. Verified.
Time reserves attention. Evidence establishes readiness.
01 / The manifesto
A shared way to work.
Faster implementation makes understanding more valuable. These are the principles we choose to work by.
- 01
Start with the outcome.
Understand who benefits, what needs to change, and how success will be recognized. Make the problem clear before choosing a solution.
- 02
Connect purpose and implementation.
Bring the business goal and the technical plan together. Make scope, behavior, dependencies, and acceptance examples explicit.
- 03
Make understanding visible.
Explain the plan in your own words. Compare interpretations, test critical assumptions, and use evidence to reveal gaps before they become rework.
- 04
Match review to risk.
Keep simple changes lightweight. Give consequential decisions the attention and expertise they need. The process should help the work move.
- 05
Let AI assist. Keep people accountable.
Use AI to explore, draft, and implement. People verify important claims, own decisions, and remain responsible for the result.
- 06
Resolve blockers before moving forward.
Record concerns and obtain informed consent on the current plans. Readiness means enough evidence to proceed, with no known material blocker.
- 07
Learn from what you deliver.
Validate behavior, inspect rework and waiting, and improve the next plan. Revisit affected decisions when new evidence changes the picture.
Three different questions
Time spent is not proof of understanding.
Review effort
How much attention do we need?
Reserve and record time for reading and review. It consumes real team capacity.
Readiness
Do we understand enough to begin?
Look for compatible interpretations, testable examples, evidence, and resolved blockers.
Delivery forecast
When might we deliver?
Use comparable delivery history, available capacity, queues, and dependencies.
Review minutes do not convert into coding hours or a delivery date.
02 / In practice
From a request to a result.
A practical loop, scaled to the change. Start with two short plans, then use evidence to move forward.
What and why
The user outcome, boundaries, business rules, and concrete acceptance examples.
How it will work
Software Specification and Design: behavior, dependencies, failure scenarios, tests, and recovery.
- 01
Define & classify
Clarify the outcome and boundaries. Identify the risk and the perspectives the review needs.
- 02
Design & verify
Prepare a proportional technical plan. Gather evidence for important claims and unknowns.
- 03
Read & explain
Protect reading time. Review independently, explain the plan in your own words, and compare interpretations.
- 04
Resolve & consent
Resolve contradictions, update both plans, and record consent with any remaining concerns.
- 05
Build & validate
Pull work when capacity exists. Build with AI, review the code, test, and verify delivery.
- 06
Measure & adapt
Inspect rework, missed blockers, and waiting. Use what you learn to improve the next cycle.
How much review is enough?
Match depth to risk. Unknowns may need a timeboxed prototype whose evidence goes back into the plan.
- Trivial
- Copy or layout changes: an independent check.
- Low
- The owner, implementer, and reviewer; short plans and asynchronous review.
- Standard
- Product, implementer, peer, and QA perspectives.
- High
- Standard review plus relevant specialists, especially for payments, permissions, migrations, or sensitive data.
What does “ready” look like?
Check six dimensions: goal, scope, behavior, dependencies, risk and recovery, and verification.
- Red
- A blocking gap. Resolve it; never average it away.
- Amber
- A recorded concern. Give it an owner and a response.
- Green
- Sufficient evidence to proceed in this dimension.
Proceed with current plans and no unresolved blockers. A material discovery reopens only the affected decisions and participants.
A small example: a refund
“Refund requested” and “refund completed” describe different states. If the provider times out, it may still have processed the request.
Keep the refund pending until the provider confirms completion.
- Normal
- Confirmation of completion updates the refund status.
- Duplicate
- Repeated requests cannot refund twice.
- Timeout
- Keep it pending and reconcile the original request.
Start small
Try it. Learn. Keep what helps.
- 01
Calibrate
Look back at 5–10 completed tickets.
- 02
Observe
Try the review without blocking delivery.
- 03
Apply
Use the readiness gate for standard and high-risk work.
- 04
Simplify
Inspect outcomes and remove unnecessary steps.
Go deeper
The ideas behind the manifesto.
Explore the Understanding Estimation series by Carlos Santana Roldán.
Understanding Estimation for the AI Coding Era
Rethinking planning when AI changes implementation effort.
LinkedInPart 02From Review Time to Readiness
Making understanding visible through evidence and informed consent.
LinkedInPart 03From Readiness to Team Delivery
Connecting readiness with capacity, delivery, and learning.
LinkedIn



