A common argument in early 2026 was that designers no longer needed code, because AI writes it. I reached the opposite conclusion from the same starting point. If a model writes the code, I need to read it well enough to see where it went wrong, the way a teacher reads homework without redoing the assignment.
Where I started
In August 2025, my AI use was a row of chat tabs. I drafted Framer code components in one, tried prompt structures in another, and pasted results back when they broke. None of those threads could see a whole repository or remember the last one.
I was not starting from zero. My undergraduate degree is in microelectronics, and my graduate program includes data and computing coursework, so I can follow a function and its control flow. What no course had covered was the modern front end: React, TypeScript and the conventions of a production codebase. I have learned those when a problem required them, going far enough to get past it and a little further.
Reading the plan before it runs
The practice that changed my work is a rule: I read every implementation plan before it touches the code. Most mistakes I catch are in the plan, not in the syntax.
One example came from this portfolio. A navigation plan assumed pages that did not exist yet. Implemented as written, it would have shipped a sticky nav with dead links. Because I read it first, the work changed order: the missing pages went up, then the nav, and every link resolved on the day it launched.
If I can catch that kind of error on paper, I decide what gets built. If I cannot, my review is limited to approving whatever sounds fluent.
The February prediction
My reference point was the Solara design system. By my own recollection, its research, token structure and component documentation took about two months by hand. Two months is not a complaint; that work is why I understand design systems well enough to review one. But it was my honest baseline.
In February 2026, I predicted that with AI implementing and me reviewing the plans, I could do comparable work in about a week. I had not tested it. It was the first prediction about my own capability that I could actually test, so I wrote it down to check later.
Updated, July 2026
The prediction got its test: the design system this essay is published on was built in code, with AI implementing under my direction. And the speed claim turned out to be the wrong claim. The two systems differed in scope and purpose, and I kept no week-by-week record, so they can't be timed against each other.
What I gained wasn't a faster version of the Solara build. It was the ability to hold a design system in code: read it, extend it and log every change against the baseline with its reasoning. The style guide documents the result, reading its values from the stylesheet the site runs on, and the log behind it records each departure, what it replaced and why.
That log is the thing February me couldn't have predicted, because it isn't evidence of speed. It is evidence of judgment, which is what the reading habit was building all along.
Where the idea came from
Flora Guo described the constraint in an interview: the quality of AI output is limited by the operator's understanding of the system underneath. You need to know what is mechanically possible to ask well, and to notice when the answer is subtly wrong. That is the reason I kept learning to read code after the tools could write it.
Extended reading. This essay grew out of two documents from February 2026. The toolkit report surveys design-engineering workflows, tools and learning resources as they stood then. The study plan sequences what to learn by dependency, and cut six vibe-coding courses down to two.