A practical operating system for using AI to think, build, verify, and ship excellent software. The goal is not to generate more code. The goal is to understand the problem, choose the right tools, challenge the answers, preserve context, and repeatedly improve the work until it is useful and worth sharing.
Start with a clearly defined problem, explicit constraints, and a visible path toward verification.
Write the idea in plain language before asking for implementation. Define the goal, why it matters, the constraints, the current system, expected behaviour, likely failure cases, and what “done” means.
Use inexpensive models for quick notes, boilerplate, and early exploration. Use stronger reasoning models for architecture, systems logic, migrations, and difficult debugging. Use independent reviewers when decisions are important.
A deliberate workflow preserves context and uses different models for planning, handoff, implementation, and review.
Maintain concise architecture notes, decision logs, current tasks, known bugs, rejected approaches, prompts, and next actions. Compress context when it grows large; do not discard the decisions that make the project coherent.
Treat the chat as an engineering notebook. Brainstorm, paste logs, explain failures, compare approaches, capture ideas immediately, and prepare the next prompt instead of forcing every thought into a rigid format.
Use the fastest available tool as an idea inbox. Record the raw idea, why it matters, one plausible implementation path, and whether it belongs now, later, or probably never.
When ideas are still messy, a deliberate handoff creates clarity without pretending that the implementation should begin from chaos. A strong reasoning model organizes the problem, a human reviews the handoff, an implementation model builds against the approved specification, and a final verification pass closes the loop.
Never accept polished output as proof. Logic, tests, evidence, and independent review settle the question.
Treat every first answer as a draft. Ask whether the logic works, what assumptions were made, which edge cases were ignored, and what tests would prove the result.
Bring your own judgement. Push back. Ask for pros, cons, alternative designs, and likely failure modes. When the drawbacks are real but the idea remains strong, redesign the risky part instead of abandoning the whole concept.
Models may be outdated or incomplete. Check real APIs, libraries, licensing, benchmarks, browser support, and recent releases. Bring that evidence back into the design process.
After every iteration, ask what failed, why it failed, what changed, and what the next experiment should isolate. Persistence becomes powerful when every pass reduces uncertainty.
Finish with intention: clarity, usefulness, delight, and a release threshold that prevents perfectionism from blocking delivery.
Improve the interaction, naming, error handling, documentation, defaults, accessibility, and presentation until the result has a moment of genuine delight. The goal is not endless polishing; it is to create something people remember.
Show people what you discovered. Share the tool, effect, architecture, or insight that impressed you. Curiosity and enthusiasm can help teams survive the tedious middle of a project.
Every task needs a release threshold. Without one, “make it exceptional” quietly becomes “never ship it.” Define the standard for release, ship when it is met, and let real usage provide the next source of truth.
Make it correct. Make it useful. Make one part delightful. Then ship and improve from evidence.