Building Software With AI

AI can make code cheaper to generate. It does not make engineering judgment cheaper.

This is my working guide to building software with AI. I use AI coding tools to get to runnable versions faster, but I still want the problem, constraints, architecture and definition of done to stay explicit.

Start with the problem, not the prompt

Before asking AI to build anything, I try to compress the work into four things: the problem, the relevant context, the constraints and what “done” means.

Problem: What is actually broken, slow, repetitive or missing?
Context: What does the current system already do?
Constraints: What must not change?
Done: How will I judge the result?

Field note: Vibe Coding Is a Mirror for How Clearly You Think

Make the problem smaller before the architecture gets bigger

A complicated system can contain a narrow problem. I often get more leverage from stating that problem clearly than from jumping straight to a new service, cache, database or framework.

Field note: If I Can’t Explain the Problem in One Sentence, I’m Not Ready to Build

Start product work from repeated friction

Features are easier to judge when they answer a named friction. This is the pattern behind several small tools I keep returning to: notice repeated friction, make the smallest useful intervention then see whether the friction actually disappears.

Field note: Most Product Ideas Start in the Wrong Place

Treat generated code as a proposal

Generation can be fast. Acceptance should stay expensive. I still want to inspect boundaries, failure modes, hidden complexity, tests and behaviour outside the happy path.

Product architecture includes data choices

When AI is inside a product, storage, source traceability and local-versus-cloud choices become part of the user experience rather than invisible implementation details.

The decision rule I keep using

Use AI to make experiments cheaper. Keep the important engineering decisions inspectable.