The cycle treats AI as an amplifier that carries whatever signal the builder feeds into it. Artisanal coding is the practice of ensuring that the signal includes the builder’s genuine understanding of the system she is building—not just her description of the desired output. A developer who prompts for a feature and deploys the result without understanding the architectural decisions it embeds is feeding a shallow signal: the output may be correct today and brittle tomorrow, and the brittleness will not announce itself until the leak occurs. A developer who reviews the generated code with the critical attention of someone who will be responsible for it in production is feeding a signal that includes her judgment, her taste, and her accumulated knowledge of the specific system in which the generated code will operate.
The cycle’s account of the Trivandrum training describes the ideal division of labor between human and AI: humans decide what should exist and how the pieces should fit together; the machine produces the pieces. Artisanal coding is the practice that makes this division of labor coherent. Without it, the human is not deciding what should exist—she is accepting what the machine decided should exist, at the level of architectural detail that determines how the system will fail. The ascending friction that the cycle identifies as the non-negotiable cost of genuine depth is, in Spolsky’s terms, the friction of artisanal practice: the time it takes to read, understand, and own the generated code rather than accepting it at face value.
The decline of Stack Overflow—the collective diagnostic memory that Spolsky built—is the institutional correlate of the decline of artisanal practice. When developers stopped asking Stack Overflow and started asking AI, they gained speed and lost the community-validated understanding that Stack Overflow’s answer architecture produced. Artisanal coding is, in part, the practice of maintaining the diagnostic relationship with the underlying system that Stack Overflow answers encoded: not just the fix, but the reason for the fix, and the reason the reason matters.
The concept appears explicitly in Spolsky’s essay of the same name, written as generative AI tools were transforming the profession he had spent his career analyzing. The essay argued that AI-generated code, for all its technical competence within well-documented patterns, lacks the qualities that distinguish code written by a human engineer who has thought carefully: the elegance that comes from understanding the problem deeply enough to see its simplest solution, the efficiency that comes from choosing the right abstraction level for the specific context, and the intentionality that comes from making design decisions on the basis of reasoning that can be reconstructed and explained.
The essay’s argument extends Spolsky’s earlier “Things You Should Never Do, Part I”—his 2000 case against rewriting codebases from scratch—into the AI era. The case against the rewrite was that existing code contains enormous amounts of implicit knowledge: bug fixes, edge case handling, hard-won workarounds that look like mess but are actually a record of every failure the system has encountered and survived. AI-generated code creates a version of the rewrite problem from the beginning: code that may contain important patterns from the training data and may not, with no way to tell the difference without understanding what the code is doing and why.
Design reasoning, not just output. Artisanal code differs from generated code not in what it does but in what accompanies it: the engineer’s understanding of why it is structured the way it is. This understanding is not necessarily documented; it may be tacit, carried in the engineer’s head rather than written in comments. But it is present, and its presence means that when the system needs to change—when requirements shift, when the system must scale, when a new vulnerability is discovered—the engineer can distinguish the decisions that are essential to the system’s correctness from the decisions that are arbitrary artifacts of when the code was written.
The difference from output review. Reading and approving AI-generated code is not the same as artisanal coding. The developer who reviews a pull request and confirms that it produces the correct output has not made the design decisions artisanally. She has confirmed a result. Artisanal coding requires understanding the process that produced the result: which alternatives were considered, which were rejected, and why. For AI-generated code, that process is opaque—the “why” in the human sense does not exist—and the developer who practices artisanal coding must reconstruct it: reading the generated code with the critical attention of someone who is making design decisions, not consuming them.
The slow-fast tradeoff. Artisanal coding is slower than uncritical deployment of AI-generated code. Spolsky’s framework is explicit that this is a genuine tradeoff, not a misunderstanding. The developer who practices artisanal coding ships fewer features per sprint. She is also the one whose features do not produce integration leaks, assumption failures, and security vulnerabilities at the moment when the production system is under load and the dashboard is red. The tradeoff is between short-run productivity and long-run system integrity, and the cost of choosing the former is paid at the worst possible moment.
The professional standard implication. Artisanal coding implies a professional obligation that the field has not yet formally established: the obligation to understand the code one deploys, regardless of how it was generated. Aviation established mandatory hand-flying hours when it recognized that automation dependence was eroding pilots’ ability to hand-fly at the moments automation failed. Automation dependence in software is Spolsky’s law at the institutional level: not a question of individual competence but of whether the profession as a whole will insist on the standard that artisanal practice represents.