A 19-year-old retail cashier built a $200,000 app using AI coding tools. A solo developer shipped a production multiplayer game with code that was, by his own account, almost entirely AI-written. The question of who can build software has effectively been answered. The question most teams have not answered is: what does that code look like six months after it was generated, and who is responsible for maintaining it?
That is the code footprint problem, and it is coming for every organization that has adopted AI coding tools without first defining what they expect those tools to produce.
flowchart TD
A[Adopt AI coding tool] --> Q{Defined starting<br/>context?}
Q -->|No| N1[Model fills gaps with<br/>training-data defaults]
N1 --> N2[Mismatched code footprint]
N2 --> N3[Technical debt at AI speed]
Q -->|Yes| Y0[Starter template]
Y0 --> Y1[Explicit conventions]
Y0 --> Y2[Real code examples]
Y0 --> Y3[Explicit exclusions]
Y0 --> Y4[Scope definitions]
Y1 --> G[AI code indistinguishable<br/>from human-written]
Y2 --> G
Y3 --> G
Y4 --> G
class N3 bad
class G good
classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6;
classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9;
classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7;
classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
AI Coding Tools Are Not Neutral — They Make Structural Decisions
When you prompt an AI coding tool without giving it structural context, it fills in the gaps. File organization, naming conventions, state management patterns, error handling, dependency choices, test coverage approach — all of these get decided by the model based on its training data, not based on your project’s existing conventions.
Those decisions are often individually reasonable. They rarely form a coherent whole at the project level.
The result is a codebase that accumulates AI-generated sections written in the model’s idiomatic style, sitting adjacent to human-written sections following the project’s established conventions. Code review becomes harder because reviewers are evaluating not just correctness but consistency. Onboarding new engineers becomes harder because the codebase does not have a single, readable pattern. Debugging becomes harder because you are working across code that reflects two or three different internal decision-making frameworks.
None of this is the model’s fault. It is the predictable outcome of deploying AI coding tools without a defined starting context.
The Footprint Is Set Before the First Prompt
The developer community has started to figure this out, though the framing is usually in terms of prompting structure rather than code quality. The insight is the same: the most important thing you do with an AI coding tool is not write a good individual prompt. It is define the environment the model works within across all sessions.
The practical form of that is a starter template — and for AI coding specifically, a starter template is not just a blank project scaffold with the right folder structure. It is the full context that shapes every interaction: the conventions the AI is expected to follow, examples of how the project’s existing code is structured, explicit rules about patterns and dependencies to avoid, and scope definitions that clarify what the AI is being asked to do versus what requires human judgment.
The teams getting consistent, maintainable output from AI coding tools are not the ones using the best model. They are the ones who put work into the starting context before they scaled adoption. The model is downstream of that decision.
What Enterprise Teams Get Wrong
Individual developers and small startup teams can iterate through a messy code footprint because their codebase is small enough to rewrite if it becomes unmaintainable. Enterprise teams cannot.
When an enterprise engineering team adopts AI coding tools without defining their starting context, they generate technical debt at the speed of AI adoption. The code that accumulates does not look broken — it passes tests, it ships features, it works. But it does not fit the established architecture, does not follow the established conventions, and does not carry the documentation and structure that enterprise codebases require for audit, compliance, and maintenance.
The compounding effect matters here. A few sprints of AI-generated code that doesn’t fit the system is a code review problem. A few quarters of it is a technical debt problem that shows up on the engineering roadmap as remediation work that has to be funded. The discovery moment is usually a new engineer trying to onboard into a codebase that looks like it was written by three different teams with three different philosophies, because effectively it was.
The inverse case is worth naming, because it shows what changes when the architecture is set before the code is written. At Carvana in 2016–2017, I led a five-developer data team in Phoenix, supporting the company through the run-up to its IPO. We were responsible for parsing millions of vehicle records every day across eight applications, feeding inventory and pricing data to external partners and internal stakeholders. By any reasonable measure of team size, we should not have been able to keep up with what we were being asked to produce.
What made it work was that the event-driven architecture was defined before anyone wrote a feature against it. The shape of the data pipeline, the contracts between services, the conventions for how records moved through the system — all of that existed as a deliberate design before development started. Five developers operating inside a well-defined architecture out-produced larger teams I have seen working without one. The same logic applies directly to AI coding tools. A small team with a clearly defined code footprint will out-produce a larger team that is generating code at speed into an undefined structure, because the smaller team is not spending its review cycles cleaning up mismatched output. The architecture decision precedes the productivity gain, not the other way around.
What a Useful Starter Template Actually Contains
The minimum viable starter template for AI-assisted coding on a real codebase has four components.
Explicit conventions written as instructions. Not example files that the AI may or may not interpret — written rules about naming patterns, error handling approaches, logging standards, state management decisions, and any other patterns the team has committed to. The AI will follow explicit instructions more reliably than it will infer conventions from file examples.
Real code examples from the project. The model should see how the project already does things: how authentication is handled, how API calls are structured, how tests are written. The goal is for the AI to extend existing patterns rather than invent new ones. A model that has seen three examples of how the project writes a service layer will write a fourth service layer that looks like the first three.
Explicit exclusions. Rules about what not to generate are as important as rules about what to generate. What dependencies are not approved? What architectural patterns has the team decided against? What approaches are technically valid but not appropriate for this project? The AI will not know these things unless you tell it. Without exclusions, it will make reasonable choices that happen to conflict with decisions the team made months ago for reasons that are not visible in the current codebase.
Scope definitions. What is the AI being asked to build, and what should it flag for human review? The code that benefits most from AI generation is code that follows established patterns within defined scope. Code that requires architectural judgment, security review, or decisions that affect system-wide conventions should be handled differently. Scope definitions prevent the AI from making consequential structural decisions quietly.
The Practical First Step
Before your team scales AI coding tool adoption onto any production codebase, answer two questions in writing: What should the code look like when the AI is done? What patterns and conventions does the project already use?
If those questions take more than a few hours to answer, you have a documentation problem that predates AI adoption — and that problem will get worse when AI starts generating code into the undocumented gaps.
The organizations getting durable value from AI coding tools are the ones that treated the starting context as the real deliverable. The tools are capable. What they produce is determined by the structure you put around them before they start.
A fractional CTO engagement typically includes a review of how engineering teams are structured for AI tool adoption — not just which tools, but what governance is in place for what those tools produce. If your team has adopted AI coding tools and you are not sure what the code footprint looks like at the project level, that is worth a direct conversation.
