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. That work is why I understand design systems well enough to review one.
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, and I wrote it down so I could check it later.
What the next project showed
The next design system I built was this site's, in code, with AI implementing under my direction. It could not confirm or refute the prediction. It was a different system, with different scope and a different goal, and I had no week-by-week record to compare.
It did show something the prediction had not asked about. I can now work on a design system in its code: read it, extend it and log every change against the baseline with a reason. The style guide documents the result, reading its values from the stylesheet the site runs on.
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.