CLARITY
Can we explain it?
The problem, the proposed behavior, the interfaces and key limitations should be understandable beyond the person who wrote the code.
HOW WE THINK ABOUT BUILDING
Build thoughtfully.
Review deliberately.
A good development process helps people understand what they are making, why it matters and how they know whether a change is ready.
Our approach is designed to stay proportional to the problem: rigorous when risk demands it, lightweight when a smaller check will do.
OUR WORKING CYCLE
Five steps. One continuous learning loop.
The order is simple; the thinking behind each stage is what matters.
01 / DISCOVER
Understand the real task.
Clarify what users are trying to accomplish, the context around the problem and why existing tools are insufficient. Avoid choosing a technology before the need is understood.
02 / FRAME
Make scope and uncertainty explicit.
Define a small useful outcome. Record important assumptions, dependencies and the conditions that would change the plan. Separate requirements from nice-to-have ideas.
03 / BUILD
Create a reviewable candidate.
Implement clear modules, protect existing behavior and keep a consistent boundary around what is being changed. Favor small, understandable decisions over needless complexity.
04 / VERIFY
Test against the real question.
Use focused verification, representative edge cases and broader regression where relevant. Distinguish actual evidence from assumptions or untested expectations.
05 / REFINE
Decide what comes next.
Accept, repair or pause. Preserve useful context so the next cycle builds on what was learned, rather than repeating decisions from memory.
THE ROLE OF AI
AI is a collaborator, not a substitute for judgment.
AI can help structure ideas, propose code and review alternatives. It can also be confidently wrong. We treat generated output as a candidate to inspect, not a result automatically ready for use.
- Keep humans responsible for scope and acceptance.
- Check outputs against source information and defined behavior.
- Use tests where mistakes would be consequential.
- Preserve uncertainty when evidence is incomplete.
EVIDENCE-LED DELIVERY
01Written intent
02Identifiable implementation
03Relevant tests and observations
04Explicit acceptance or revision
Appropriate controls depend on the risk and complexity of the work.
WHAT WE LOOK FOR
Useful signs of progress.
EVIDENCE
Can we test it?
Important claims should connect to a validation method. A green build is useful, but it cannot answer questions the checks never asked.
CONTINUITY
Can we improve it?
The system should remain maintainable. Changes should be small enough to review and documented enough to learn from.
QUESTIONS WE HEAR OFTEN
Thinking about the tradeoffs.
Is a structured process too heavy for a small team?
It can be if every step creates paperwork without helping a decision. We prefer controls scaled to the impact of a mistake, with lighter checks for low-risk work and deeper review when stakes increase.
Does using AI eliminate the need for software tests?
No. Faster code generation can increase the amount of behavior changing in a short period. Tests, review and careful acceptance become more important, not less.
When should a project stop and reconsider?
When the original need is no longer clear, important assumptions have failed, or a change cannot be evaluated responsibly with the available evidence.
IDEAS IN WRITING
Read deeper into the practices.
Our insights section includes original notes on reliable AI products, recoverable automation and practical engineering checkpoints.
Beyond prototypes
Building AI products for real-world conditions.
Read note ↗Resilient systems
Working with failure instead of ignoring it.
Read note ↗Quality gates
Keeping verification proportional to risk.
Read note ↗SEE IT IN CONTEXT
Explore current project directions.
Find out what we're building and studying through these methods.