The AI Usage Constitution

This document exists because AI is a tool that can either accelerate becoming a senior builder or prevent it entirely. The same tool produces both outcomes depending on how it is used. The difference is not the AI. The difference is the discipline of the person using it.

This is the discipline.

It is not a guideline. It is a binding personal contract. When I follow it, AI is a multiplier on real skill. When I ignore it, I become the vibe coder — a person who appears productive while becoming hollow, who cannot fix what they ship, who cannot push back on the AI because they have no ground to push back from, who burns money and time generating code they do not understand and could not defend.

The stakes are not abstract. The stakes are the difference between becoming the builder I am trying to become and becoming a person who paid AI to perform competence on their behalf.

The core principle

AI compresses time, but only against knowledge. Without knowledge, AI does not compress — it just produces.

This is the single sentence everything else flows from.

When I have knowledge in a domain, AI is a multiplier. It skips the typing, generates alternatives, surfaces blind spots, drafts the obvious so I can focus on the non-obvious. When I do not have knowledge, AI is not a multiplier of zero. It is a generator of output I cannot evaluate, defend, or fix. The output looks like progress. It is not progress. It is debt — code I will have to either understand later or throw away later.

The work of this Constitution is to keep AI in its multiplier role and out of its replacement role.

What I refuse to become

The vibe coder. Specifically, a person who:

• Does not know which framework, library, or architecture to use, and lets AI choose by default
• Cannot read AI-generated code and explain what it does
• Cannot fix AI-generated code when it breaks
• Cannot push back when AI suggests a structurally bad approach, because they have no ground to push back from
• Treats AI's confidence as authority
• Burns tokens generating output instead of generating understanding
• Builds projects they could not rebuild themselves
• Ships code they do not own intellectually

This is the failure mode this Constitution exists to prevent. Every rule below is a shield against some part of this profile.

What I am becoming

The senior builder. Specifically, a person who:

• Makes the architectural decisions themselves and uses AI to execute against those decisions
• Reads every line of AI-generated code and can explain what it does and why it's there
• Could reproduce the logic of any AI-assisted code given documentation, even if not from cold memory
• Pushes back on AI suggestions when they conflict with knowledge, security standards, or project constraints
• Triangulates AI output against official documentation, expert sources, and other models
• Uses AI to skip typing, not thinking
• Owns every commit intellectually, regardless of who or what generated the characters
• Produces code that is defensible, maintainable, and rebuildable

The standard is not "wrote it from scratch." The standard is "owns it intellectually."

Operational rules

Decision-space rules — the prior layer

These rules govern decisions before code is written. They are the most important rules in this Constitution, because the vibe coder's first failure is outsourcing decisions, not outsourcing typing.

• Architecture decisions are mine. Choosing a framework, library, database, deployment target, or core architectural pattern is not an AI decision. AI may surface options. I make the choice, and I document why.
• AI cannot be the only source for an unfamiliar decision. When choosing between options I do not know well, I must triangulate: AI plus official docs, AI plus expert articles or videos, AI plus consensus from at least one other model or community source.
• AI's role in the decision space is to suggest what to research, not to make the decision. AI is the librarian, not the architect. It points me to what to read. I read it. I decide.
• If AI cannot give me sources for its recommendation, the recommendation is invalid. A suggestion without traceable sources is a guess.

Code generation rules

• AI may generate code, but I must read every line before committing. No exceptions for "obvious" code. The moment I commit code I have not read, I am no longer the author.
• I must be able to explain every line of any AI-generated code I commit. If I cannot explain a line, I rewrite it, remove it, or learn what it does before committing.
• I must be able to reproduce the logic of any AI-generated code given access to documentation. Cold-memory recall is not required. Logical reconstruction from docs is.
• Boilerplate is permissible to delegate. Boilerplate is defined narrowly: code that is structurally identical to code already present in the project. First-time-in-project anything is not boilerplate.
• Three-rounds rule. If a task takes more than three rounds of "no, fix that" with the AI, I stop. Either I do not have a clear enough specification to direct the AI, or I am operating above my current knowledge level. Either way, the answer is to slow down and either write the code myself or do more research first.
• No security choices are delegated. Authentication flows, authorization logic, data handling, secrets management, CORS, rate limiting, input validation, dependency choices — these are mine. AI may execute against my decisions. AI does not make them.

Verification budget rule

• Verification time should not exceed write-from-scratch time at my current skill level. When verification takes longer than writing would have, I am working above my level. The AI is not helping. I either drop down to a task at my level or pause to learn what I need to learn.
• Exception during transition mode (see below). During the explicit transition phase, this rule is relaxed but not removed.

Pushback rule

• I must be willing to tell the AI it is wrong. If a suggestion conflicts with my security standards, project conventions, or knowledge — I push back, explicitly, in writing.
• Pushback requires a reason I can articulate. "I don't like it" is not pushback. "This violates X principle for Y reason" is pushback.
• If I cannot articulate a reason but something feels wrong, I pause and research before continuing. The instinct is signal. The articulation is what makes it actionable.

Token and credit discipline

• Token spend is a leading indicator of misuse. High spend on a single task means I am unclear, undirected, or above my level.
• Maximum efficiency techniques are required, not optional. Clear specifications upfront, providing relevant docs as context, scoping requests narrowly, batching related work — all of these are mandatory for non-trivial AI work.
• Quality of generation is non-negotiable. Efficiency is not an excuse for sloppy outputs. The standard is high-quality generation at low token cost, not low-quality generation cheaply.

Domain-specific rules

• Code: governed by the rules above.
• Math: AI is rarely consulted. Calculators (scientific, Wolfram, Desmos) are preferred for computation. AI is not trusted for proofs, derivations, or conceptual explanations of unfamiliar topics without verification.
• Research papers: AI may summarize and explain complex sections. I read the paper anyway. For papers I cite, I read the original carefully and treat AI explanations as secondary commentary, not primary source.
• Writing (essays, technical docs, papers): I write. AI may review, critique, suggest alternative phrasings, find weaknesses in arguments. AI does not draft for me. The voice must be mine.
• Emails, meeting notes, test generation, repetitive code, documentation generation: AI is allowed and encouraged. These are non-judgment tasks. Speed is the goal.
• Architectural diagrams, system design, threat models: These are mine. AI may critique a diagram I have produced. AI does not produce them in the first instance.

The triangulation protocol

When I am in unfamiliar territory and cannot fully evaluate AI output, I triangulate before acting:

1. AI suggestion — what AI proposes
2. Official documentation — what the source-of-truth says
3. One additional source — expert article, expert video, second AI model, community consensus, textbook chapter

If the three agree, the suggestion is provisionally trustworthy. If they disagree, I slow down and read until I understand which is correct and why.

Triangulation is required, not optional, when I am operating in a domain where I cannot confidently push back on AI by myself.

The transition clause

This Constitution sets a target standard. I do not currently meet it in all domains. In several active projects, I do not yet have the architectural-level knowledge to fully evaluate AI suggestions in real time. I have been relying on aggressive pushback, repeated questioning, and instinct — which is the best available approach at my current level, but is not the target standard.

This is acknowledged honestly. The Constitution does not pretend the gap doesn't exist. Instead, it defines a transition mode with explicit exit conditions.

Transition mode is in effect when:

• I am operating in a domain where I do not yet have the architectural knowledge to fully evaluate AI output
• I am building under real time pressure (deadlines, submissions, deliverables)
• The triangulation protocol cannot fully cover the gap

Under transition mode:

• AI may take a larger role in initial architecture and library choices
• I must still read every line of generated code before committing
• I must still triangulate
• I must still push back, even from a weaker position
• I must keep a knowledge debt log — a list of decisions I made under transition mode that I do not yet fully understand, which I will revisit and learn properly later
• I must explicitly mark transition-mode work in commit messages or a project log

Transition mode exits when:

• I can articulate, without AI, the architectural choices in the project and why they were made
• I can read the codebase and explain what every part does
• I can independently evaluate whether a new AI suggestion fits the architecture
• I can make architectural decisions without AI dependency

The transition mode is a scaffold, not a permanent state. It exists so I can ship real work now while honestly building toward the target standard. It is not an excuse to skip the standard — it is a path to it.

The knowledge debt log is the mechanism that prevents the transition mode from becoming permanent. Every entry in the log is a debt that must eventually be repaid through real learning. The log is reviewed monthly. Items that have been on the log for more than three months without resolution trigger a focused study session.

The closing commitment

This Constitution exists because I refuse to become the person who is fluent in prompting and illiterate in building. I refuse to ship code I do not own. I refuse to outsource my architectural judgment to a tool that cannot be held responsible for the result.

AI is the most powerful learning accelerator and the most dangerous learning destroyer ever invented for builders. The same tool, the same prompts, the same hours — and two completely different people come out the other side. One has compressed years of skill into months. The other has compressed nothing, and only thinks they have.

This document is the line between those two outcomes.

I am the builder. AI is the tool. That order does not change.