{"slug": "the-code-is-cheap-artifact-now-the-spec-is-the-asset", "title": "The Code Is Cheap Artifact Now The Spec Is the Asset", "summary": "A developer describes a shift in software engineering where AI drafts specifications, implementation plans, and code, while the engineer focuses on defining intent, identifying constraints, and reviewing decisions. The project involves rewriting an existing product to follow a new architecture without changing business logic, treating the work as a constraint management problem. The developer emphasizes that specifications are now written for the next AI session rather than human readers, and that the most valuable human contribution is determining which constraints are load-bearing.", "body_md": "Over the past few weeks, one of the biggest shifts in my thinking has been this:\n\nI want to spend less time writing specifications and implementation plans by hand, and more time on design.\n\nThe surprising part is that AI has made that possible — not by replacing engineering judgment, but by changing *where* that judgment is applied.\n\nToday, I increasingly let AI draft specifications, implementation plans, and even code. My job has shifted toward defining intent, identifying constraints, and reviewing decisions. The writing itself has become the least valuable part of the process.\n\nThe specifications I'm talking about aren't traditional documentation.\n\nThey're not written for future engineers casually browsing a wiki. They're written for the **next AI session** that needs to continue the work without requiring me to re-explain everything from scratch.\n\nThat changes how they look. Instead of narrative descriptions, they focus on:\n\nIn other words, they're designed to be **executed against** rather than read.\n\nThe audience is no longer a human reader. The audience is the next contributor — whether that's an engineer or an AI agent.\n\nThe project I've been focused on recently is rewriting an existing product to follow a new architecture **without changing the existing business logic**.\n\nThat combination creates a challenge that's almost entirely about constraints:\n\nThis isn't a CRUD application problem.\n\nIt's a **constraint management problem**.\n\nAnd constraints are exactly the kind of information AI can work with effectively — if they're captured clearly.\n\nOver time, our workflow has evolved into a series of deliberate review gates:\n\n```\nIntent → AI Specification → Human Review → AI Implementation Plan → Human Review → AI Code Generation → Testing & Validation\n```\n\nI provide:\n\nAI generates the first draft of the specification. I review it. AI generates an implementation plan. I review it. Only then does code generation begin.\n\nThe result is that I'm writing far less than before. But I'm **reviewing far more carefully**. And that's where most of the engineering value now lives.\n\nOur specifications are intentionally structured like test plans.\n\nA specification doesn't explain *how* code works. It defines **observable requirements**.\n\nFor example, a refactoring specification might include:\n\nNo class in the application layer may directly reference DAO implementations.\n\nThe acceptance criteria become executable checks:\n\nThe specification defines **what must be true**.\n\nThe implementation plan defines **how to make it true**.\n\nThose are different documents serving different purposes — keeping them separate has proven incredibly valuable.\n\nThe most important thing I do today isn't writing.\n\nIt's determining which constraints are truly **load-bearing**.\n\n**Architectural foundations** (critical — violating these can break everything):\n\n**Conventions** (useful, but not critical):\n\nThen there are **intentional deviations** — things that appear wrong but exist for legitimate operational reasons. Those can be the most dangerous. A well-intentioned cleanup can accidentally break a production system because it removes something that looked like technical debt but was actually preserving compatibility.\n\nWhen AI produces a specification, my primary review question is simple:\n\nDid it correctly identify which constraints are load-bearing?\n\nThat's still a human judgment call. And it's a far more valuable use of my time than writing the initial draft myself.\n\nThis is the realization that changed how I think about AI-assisted development.\n\nIndividual AI sessions are **temporary contributors**. They appear, contribute, and disappear.\n\nThe value doesn't come from any single session being exceptionally intelligent. The value comes from every session sharing the same source of truth:\n\nTogether, these artifacts become the project's **long-term memory**.\n\nThe AI session is temporary. The memory persists.\n\nI learned this lesson the hard way.\n\nAt one point, our documentation drifted. An ADR stated that database schemas were initialized through startup scripts rather than Liquibase. However:\n\nThree artifacts. Three different stories.\n\nA new contributor — or AI session — reading the repository would inherit the wrong mental model immediately.\n\nThe fix wasn't complicated. We simply asked:\n\nWhat actually happens on a clean environment build?\n\nThe operational behavior became the arbiter of truth. Once we verified reality, we:\n\nThe result wasn't cleaner documentation. It was **restored trust in the source of truth**. And that's what allows future contributors to move faster.\n\nHere's how this translates into the actual repository layout without the microservice modules:\n\n```\nstate-retail/\n├── CLAUDE.md                  # THE WORKFLOW — human-review gates. Read first.\n├── README.md                  # Entry point: layout, doc map, schema strategy, how to run.\n├── status.md                  # Living index of every spec/plan and its state.\n│\n├── specs/                     # The WHAT (and why)\n│   ├── CONVENTIONS.md         #   Authority — wins on overlap\n│   ├── architecture.md        #   Layering & naming reference\n│   ├── global-rules.md        #   Cross-cutting rules\n│   ├── infra.md               #   DB / Docker / schema-management contract\n│   └── <module>/<NCEVR-NNN>-<slug>.md\n│\n├── plan/                      # The HOW, mirroring specs/\n│   └── <module>/<RETAIL-NNN>-<slug>.md\n│\n├── rules/                     # Class-level coding conventions per layer\n│   └── domain / dao / service / application / api\n│\n└── docs/adr/                  # WHY significant decisions were made\n    └── NNNN-<slug>.md         #   Immutable once Accepted; supersede with a new ADR\n```\n\nAI is increasingly capable of generating specifications, plans, and code.\n\nWhat it **cannot** do reliably is determine which constraints matter most to your business.\n\nThat remains a software engineer's responsibility.\n\nFor organizations building complex, highly regulated systems, this is more than a productivity improvement. It's a way to accumulate executable knowledge over time — every new project starts with shared memory rather than a blank page.\n\nBecause increasingly, the code is cheap artifact.\n\n**The specification is the asset.**", "url": "https://wpnews.pro/news/the-code-is-cheap-artifact-now-the-spec-is-the-asset", "canonical_source": "https://dev.to/daniel_wu_cac679a2760ba0a/the-code-is-cheap-artifact-now-the-spec-is-the-asset-3b02", "published_at": "2026-06-17 13:32:46+00:00", "updated_at": "2026-06-17 13:51:39.229339+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents", "large-language-models", "ai-products"], "entities": ["AI", "developer"], "alternates": {"html": "https://wpnews.pro/news/the-code-is-cheap-artifact-now-the-spec-is-the-asset", "markdown": "https://wpnews.pro/news/the-code-is-cheap-artifact-now-the-spec-is-the-asset.md", "text": "https://wpnews.pro/news/the-code-is-cheap-artifact-now-the-spec-is-the-asset.txt", "jsonld": "https://wpnews.pro/news/the-code-is-cheap-artifact-now-the-spec-is-the-asset.jsonld"}}