My Current Approach to AI-Augmented Development
A snapshot of how I'm building app-scale software with AI right now, and the mindset behind it
This is the development process I’m using right now for AI-augmented work. I tune it constantly, so treat it as a snapshot. It works for me at my current scale, and parts might work for you. Offered as building blocks, not a complete blueprint; we’re all in different circumstances.
Two caveats up front. First, this is app development, not a large distributed system. In theory a big system breaks into cohesive modules, and an agent could own one module and its contract with the others, but I haven’t validated that at scale. The second: Rust is a newish stack for me, which shapes much of what follows.
Here’s what’s working for me:
Steer with directives. A solid set of agent files (
CLAUDE.md) for the programming language does more for me than any single prompt.
A sample of my current Rust directives
Rust data modeling
Ownership forms a tree/DAG, never a cycle. One clear owner per value.
For references between values (or any logical cycle): use
slotmapkeys, orVecindices only if nothing is ever removed....
Full set in this gist.
Limit third party dependencies. Add a clause to your agent file: be conservative with third party dependencies. Weigh a few options, favor the well-maintained ones, and ask before adding.
Make the test suite your source of truth. If you’re not going to review and gate the functional code line by line, fixate on the tests. It’s the closest-to-code abstraction I have for gauging whether the implementation is correct. Telling the agent to “create tests” isn’t enough; left alone it will write tests that pass without proving much. So I give it a TDD directive and name the anti-patterns to watch for. Over-mocking is the big one: mock enough of the surrounding code and you stop testing your logic and start confirming that the mock framework returns what you told it to. A test suite I trust, plus a current frontier model with good steering, gets me solid results at app scale.
Build kernel-first. Build bottom-up. Start with the data structures, and then the business logic to manage them. No UI. This narrows scope and makes the conversation with the model clearer. Keep the UI decoupled from the kernel, so more of the system is testable without it. This is where SWE fundamentals pay off: dependency injection, decoupling, testable seams.
Pause at the end of each stage. Ask the agent how to smoke test what you built. Dig into anything that doesn’t sit right, and later have it build HTML walkthroughs. Have it review the session’s changes for business logic that landed in more than one place; that scattering usually signals a cleaner module boundary or an extracted method. Before the next stage, have it curate the docs: fix inaccuracies, consolidate duplication, sync the agent files.
Scope milestones to a session. I work toward an early MVP in a series of discrete milestones, one milestone per session. If I’m reaching for
/compact, the milestone was too big.
Underneath these tactics is one idea: keep the system legible enough that you and the agent share a picture of what it’s actually doing. As complexity climbs, complete, accurate, actionable instrumentation matters more, so lay these foundations early.
The part I’d underline is patience: think about your actual motivation. Mine is simple: get better at reading and interpreting Rust, and learn to spot the anti-patterns and rough edges I’m sure are sitting in this codebase. Building something real that I plan to rely on makes those lessons stick. So I take the occasional “no new features” day to dig into one component, or improve the test suite. Refactoring for understanding counts as progress.
There’s a lot of pressure to treat velocity as the only metric, to produce more code, faster. Some of that comes from leadership, and if that’s your mandate, I feel for you; that’s a genuinely tough spot. But a lot of it is ambient: feeds full of confident takes and flashy demos that make careful work feel like falling behind. Elena Verna calls that AI confidence theater, and much of the certainty is performance. If you get time to work with AI on your own terms, deliberate work isn’t falling behind. It’s how you end up understanding what you built.
I am actively iterating on this approach on B2, my effort to build a personal knowledge management app.