Savviety

Method

How I build with AI.

Building platforms and leading delivery taught me to work through unclear requirements and explain my choices. I use those habits throughout a build with AI, checking the result as well as the plan.

  1. 01

    Start with the problem and its constraints.

    “Define the result before directing the implementation.”

    I write down what the software needs to do and how we'll check it. That means identifying what's still uncertain and defining a scope we can verify. The requirements and plan in opening-dojo show how I did this for a build using AI agents.

  2. 02

    Make the architecture decisions explicit.

    “Boundaries determine how a system behaves under pressure.”

    Each part of the system needs a clear job. I work out where the data goes, which dependencies it needs, and what happens when a service is down. In kb, note capture runs locally, separate from retrieval, so it works without the search server.

  3. 03

    Test against your own confirmation bias.

    “The person who wrote the code wrote the expectations.”

    The tests I write can share mistakes with the code I write. I check those expectations against independent implementations, property-based invariants, and adversarial inputs. In savviety-instinct, that found three bugs the original expectations missed. I care more about which failures the tests catch than how many tests there are.

  4. 04

    Direct delivery and verify completion.

    “Responsibility stays with the engineer directing the work.”

    I put tasks in order, direct the agents, and review what they produce against the requirements. The workflow can stop at a failed gate and records any human override. In ccx, a report of completed work must include commit or test evidence so someone can check it.

  5. 05

    Understand behavior before changing the system.

    “A rebuild needs an explicit account of what to preserve and what to fix.”

    Before a major change, I audit the code and test how it behaves. I did that before rebuilding gorules as rustrules. A repair or replacement needs a reason: which defects need fixing, what migration will cost, and which behavior should stay the same.

You can follow these decisions in the project code, architecture, and delivery records.

See the work