# Writing Code Was Never the Point > Source: > Published: 2026-09-01 15:30:38+00:00 AI can write production code faster than any engineer alive — and the industry is figuring out, slowly, what else got bundled into that process all along. ## 1. The Hidden Contract in Every Line You Wrote For most of software engineering's history, a useful thing happened when you sat down to write code: you were forced to understand it. Not as a rule, not as a principle — just as a practical consequence. "Aside from the most basic comp sci homework problems," [one engineer put it recently](https://martiansoftware.com/articles/ai-written-code-is-still-yours), "it's pretty hard to write something you don't understand and still get a passing grade from your professor, your boss, or your customers." Writing and understanding were bundled. You couldn't meaningfully separate them. That contract is now broken. Coding agents will write things you don't understand all day long. They will pass tests. They will ship. The bill comes later — when something breaks in production and you're reading code you've never really read before, reasoning about a system whose internals you never internalized. The mental model that used to come with writing the code is no longer included. You have to acquire it separately, as a deliberate second act. This isn't an argument against agents. It's an observation about a structural change in what software engineering requires. The cost of writing just dropped dramatically. The cost of understanding didn't. For most careers, we never had to track those two separately because they moved together. **Why it matters:** **For ICs:** Your output velocity is going up. Your comprehension of what you're shipping may not be. That gap is a future liability that shows up at the worst possible moment — usually 2 a.m. on a Saturday. **For leaders:** Faster shipping metrics will look great. Watch for the lagging indicator: production incidents caused by code nobody on the team truly understood before it merged. **For founders:** Letting agents build core systems without requiring engineers to deeply understand the output is accruing a new kind of technical debt — not bad code, but unowned code. When a system breaks and nobody truly understands it, the diagnosis cost skyrockets regardless of how cheaply it was built. ## 2. Blindfold Chess and the Discipline Writing Demanded An engineer [writing about his father in the late 1990s](https://askmike.org/articles/ai-coding-lessons-in-the-90s-from-my-dad/) tells a story that's the right analogy for right now. His dad made him play blindfold chess — calling moves out loud, never looking at the board — to force a real internal model of the game. Strong players don't need a photograph of the position. They track relationships: which pieces are active, which squares are controlled, how one move shifts the tension across the board. Programming, before agents, worked the same way. You couldn't easily avoid building an internal model. Reading your own code, reasoning about interfaces, tracking what changed — all of it forced cognitive engagement that is now easy to skip. "Programming with AI is the opposite of blindfold chess," the author notes. "You don't have to pay attention every turn, you don't have to remember what the important pieces are." You can close your eyes. The AI will move the pieces. The question isn't whether that's bad in principle. It's whether engineers can stay sharp when the incentive to do so has weakened. Every abstraction layer in programming history — assembly to C, C to Python — shortened the list of things you had to understand, but the list never hit zero. Now it can. You can ship working software while understanding almost nothing about it, and the consequences arrive slowly enough that they won't disrupt your current sprint. **Why it matters:** **For ICs:** Carefully reading AI-generated code before merging — actually understanding it, not skimming for syntax errors — is now a deliberate practice you have to choose, not a side effect of writing it yourself. **For leaders:** Code review built on the assumption that the author understands their own PR may need rethinking in an agent-first workflow. The author may have only steered. **For founders:** The engineers who maintain the habit of understanding are going to be materially more valuable than those who optimized purely for output rate. This is not obvious yet. It will be. ## 3. Two Thousand Pull Requests and a Working Database Engine If you want to see the extreme end of what's possible, look at [DoltLite](https://www.dolthub.com/blog/2026-08-31-doltlite-beta/). It is a fork of SQLite — everything above the B-tree layer intact, the SQL parser and query engine untouched — but the storage layer replaced with a Prolly Tree that adds Git-style version control over data. Five months ago it didn't exist. Today it's Beta, built across roughly 2,000 agent pull requests. This is not a toy. It is a real embedded database engine, written in C, with a replaced core storage layer in one of the most widely deployed pieces of software in existence. Agents wrote it, reviewed each other's work, and shipped something that functions. The DoltHub team guided the process and made architectural calls — but the line-by-line comprehension that normally comes from writing 2,000 PRs yourself is distributed across an agent fleet rather than held in anyone's head. The question DoltLite raises isn't whether agents can build real things — they clearly can. It's what ownership looks like five years from now when something breaks deep in a system built this way. Architectural understanding and line-level comprehension are not the same thing. Agents made it possible to have one without the other at scale. **Why it matters:** **For ICs:** DoltLite is a useful calibration point. If agents can build a database storage engine, what they can build in your codebase is probably further than you assume. The follow-on question is whether your team will understand what gets built. **For leaders:** "The agents built it" is going to be an increasingly common answer to "who wrote this." Your onboarding, incident response, and bus-factor calculations need to account for that. **For founders:** Invest in documentation and architectural clarity as first-class outputs now, not retrofitted later. The system an agent built in a week may take a human three months to fully reason about. ## The Verdict: Real or Hype? **Code velocity from agents → Real.** The productivity gains are measurable and not going away. **The understanding gap → Real but underestimated.** The industry hasn't fully priced in what's lost when writing and comprehension decouple — because the bill hasn't arrived yet at scale. **Agent-built production systems → Real but early.** DoltLite works. Whether teams can debug and evolve agent-built systems over a three-year horizon remains an open question.