Don't Let AI Make Your Strategic Code Decisions

I've been generating a lot of code using AI. I used about 400 million tokens last month, to give an idea of scale. That volume only works if you're steering it; otherwise you're generating a lot of well-intentioned wrong answers. But there is one area of code that I very intentionally do not let AI default to when building software: strategic code decisions.

Before we jump into strategic code decisions, you need to understand two critical concepts about AI. One: AI is tokens in, tokens out. The tokens you send in will influence the tokens you get as a response. Two: with a lack of tokens to push the model in a specific direction, it will gravitate to the most generic solution.

Here’s an analogy of how that plays out when it comes to cutting grass.

Scenario 1

Customer: I need a lawn mower to cut my grass. Salesperson: Here is the most common lawnmower we sell - it's an 18-inch electric push mower. Customer: But I have 3 acres of yard.

Scenario 2

Customer: I need a lawn mower to cut my grass. I have 3 acres to maintain. Salesperson: Here is a gas-powered riding lawnmower with a 60-inch cutting deck.

AI is going to generate tokens no matter what, but the customer who said "3 acres" got the right tool. Give the model your strategic decisions as context and it will generate better tokens (code).

Strategic code decisions are things like language, framework, dependencies, build vs integrate, patterns and methodologies, systems, and so on. Tactical code is everything that implements those strategic decisions; it’s the actual product functionality. This is where AI excels beyond a human more often than not. This tactical code generation layer is where AI is strongest as of mid-2026.

A lot of my recent experimentation with AI code generation has been around setting a foundational goal with really detailed definition and then deploying agents in a loop to generate the code for the software.

There are different levers you can pull to achieve better outcomes with this approach. Example: spec driven development using BMAD Method (a structured spec-driven development framework) can provide generally more coherent codebases in my experience than letting the model fall to the lowest common denominator by just having the agents loop until a vague goal is achieved by their judgement.

I think one of the reasons that BMAD Method and other frameworks like it do a better job is that they are pushing the strategic code decisions to the human layer as part of the Product Brief -> Product Requirements Doc (PRD) -> Architecture layering. You would normally complete each of those documents during the BMAD workflow.

The more detail you can provide upfront before any single line of code is generated, the better the end result when using a fleet of agents to generate it autonomously.

One thing that is interesting is that if you can get a good strategy defined for your codebase and consistently follow that strategy, it becomes less critical to micromanage every little detail with further along roadmap items because the conventions aren't just described in a spec doc. They are the reality of the existing codebase. Instead of having to describe the convention every time it needs to be applied, you can tell the agent to follow the existing conventions.

The agent sees the strategy organically when it looks at well written code. The best models now will seek out the strategy and try to follow it as part of their training. At that point, the codebase itself becomes part of your prompt.

By Josh Kimbrel · Updated June 30, 2026