The advice designers keep getting right now is that code has finally become optional: the AI writes it, so describe what you want and move on. I've arrived at the opposite conclusion from the same premise. Precisely because the AI writes the code, I need to be able to read it — not write it fluently, read it. The way a teacher reads homework: not to redo the assignment, but to catch where it went wrong.
Six months ago, it was just tabs
That distinction hadn't occurred to me yet. In August my AI use looked like a browser full of chat tabs: draft a code component for Framer in Gemini, prompt, paste, come back when it broke. I was experimenting with prompt structure, taking early stabs at context engineering, using models to digitize corners of my life. Some of it worked.
But nothing was connected. Every thread was its own chat window, with no memory of the last one. Nothing was automated, nothing agentic, no tool could see a whole repository, no assistant lived on my machine. The model was doing tasks. It wasn't carrying work.
I should be clear about where I was starting from, because it wasn't zero. My undergraduate degree is in microelectronics; my current graduate program includes data and CS coursework. I can read a function and follow a control flow. What no syllabus covered was the modern front-end — React, TypeScript, the layered conventions of an actual production codebase. So that part I've been learning the way I've learned everything past a syllabus: on demand, at the moment of being blocked, going exactly deep enough to get unblocked and a little further so the same wall doesn't stop me twice.
The rule: read the plan before it runs
The practice that has actually changed how I work isn't a course at all. It's a rule: I read every plan the AI writes before it touches anything. Not skim — read, the way you'd read a junior's proposal before they spend a week on it.
The errors are almost never in the typing; they're in the plan. A step that assumes a file that doesn't exist. A migration that's correct in isolation and wrong for this codebase.
If I can catch those on paper, I stay in the loop as the person who decides. If I can't, I'm just the person who clicks approve — and the quality of everything downstream is capped by that.
The "before": two months by hand
That habit needs a baseline to measure against, and I have one. The Solara design system — the color and typography architecture, the token structure, the component specs — took me about two months of my own hands: research first, then establishing a workspace operation, then implementing the system across the designs. Two months is not a complaint; that work is why I understand design systems well enough to audit one. But it's the honest denominator.
So here is what I believed in February 2026, and had not proved: with Claude carrying the implementation and me reading the plans, I thought I could do that two months of work in roughly a week. I didn't know that. Nobody was paying me to find out on their system, and I hadn't built one of my own since the tools changed. But it was the first prediction I'd made about my own capability that I could actually test — and I intended to.
Updated, July 2026
The prediction got tested: the design system this essay is published on was built in code, with me directing. And the speed claim was wrong — or rather, it was the wrong claim.
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 deviation with its reasoning. The live style guide documents the system, and its mutation log records each divergence from the baseline — what changed, from what, and why.
That log is the artifact February-me couldn't have predicted, because it isn't evidence of speed. It's evidence of judgment — the one thing the reading habit was building all along.
Where the framing came from
Credit where it's due: Flora Guo articulated the bottleneck in an interview — AI output quality is capped by the operator's understanding of the system underneath, because you have to know what's mechanically possible to prompt well, and to notice when the output is subtly wrong.
I'm not the only one drawing this line. The design-engineering community makes the same cut between speed and understanding — as designengineer.xyz frames it, vibe coding gets you 70% of the way there fast, but the last 30% (the polish, the edge cases, the subtle refinements) needs actual understanding. And the market has started pricing that in: job listings at Raycast and Circle now name Cursor and Claude Code as explicit requirements rather than bonuses — hiring for people who can wield the tools and read what they produce.
Read the homework.
Extended reading. This essay grew out of two documents I put together in February 2026 while planning the pivot. The first is a landscape report on the AI-native Design Engineer toolkit — the professional workflows, the Cursor / Claude Code / Figma MCP triad, the learning resources, and the job-market signals that shaped the plan: the full toolkit report. The second is the plan itself — a phased, dependency-sequenced study curriculum that cut six vibe-coding courses down to two and sequenced the rest by hard dependency. Together they're the "homework" behind the prediction.