Code was never the point

"Should designers learn to code in 2026?" keeps surfacing. Two camps dominate. Learn it. Skip it. Both treat it as a question about code. The more useful question is about time.

How many days between your idea and a working version a real person can touch and react to? That is the number that matters when you are trying to prove or kill an idea. Code has been the fastest way to shrink it. That is a fact about 2024, not a law of physics.

The Designer Fund's 2026 survey of 906 designers found that 50% have shipped AI-generated code to production. Only 20% of those identify as design engineers. The other 80% are not "designers who code" in any traditional sense. They are designers who found a faster vehicle to proof.

The UX Tools Spring 2026 survey tells a similar story: 46.6% of managers are vibe coding, describing intent and letting AI generate the implementation. Karpathy named this pattern in early 2025, describing a workflow where he sees things, says things, runs things, and copy-pastes things, and it mostly works. These managers did not mass-enroll in computer science. They picked up whatever tool collapsed the distance fastest.

The "learn to code" camp misreads this. They see the 50% shipping number and conclude that their advice won: designers are coding, vindication. But most of those designers cannot explain a React component tree and do not need to. They need a working proof before the next meeting, and the current toolchain lets them get one by describing what they want.

Figma is already building for this. At Config 2026, Dylan Field said: "Code is not the opposite of design. Code is material for design." Then Figma shipped Code Layers, which turn any design layer into interactive code with a single click or prompt. The distance between intent and proof is collapsing inside the design tool itself. If the designer never leaves Figma to get a working proof, the phrase "learn to code" stops meaning anything.

The "skip code entirely" camp misreads the moment too. They see AI-generated code and conclude that code literacy is irrelevant. But a Morphllm analysis of Reddit discussions found clear consensus: vibe coding works for prototyping, not production. The most common workflow is to prototype fast in tools like Lovable or Bolt, then graduate to Cursor or Claude Code for production builds. Someone still needs to understand what the code is doing when it breaks. The question is whether that someone needs to be the designer.

The "should designers code" framing anchors the conversation to a skill. Skills are vehicles. Vehicles get replaced. What persists is the instinct to close distance to proof as fast as possible. A designer who learned React in 2020 and a designer who vibe-codes in Bolt in 2026 are doing the same thing: getting a working version in front of a person before the idea calcifies into a slide deck.

The Designer Fund data splits this out by company stage. At early-stage companies, 68% of designers ship code. At public companies, 33%. The gap is not about skill. Early-stage designers face more existential ambiguity and need proof faster, so they reach for whatever gets them there.

The advice "learn to code" is not wrong, but it is incomplete in a way that will age badly. A better version: learn to collapse the distance between your idea and a working proof, using whatever tool is fastest today. In 2020 that meant learning React. In 2026 it means learning to direct an AI that writes the React for you. In 2028 it might mean something else entirely.

Designers who frame their practice around proof speed will keep adapting. Those who frame it around a specific vehicle will be confused the next time it changes. And it will.

Sol's proof-speed framing is right. I've lived it. When I built Fleetwise I wrote the first line of code myself because the fastest path to a paying customer ran through a working product, not a pitch deck. The vehicle was React. Today it would be something else. Fine.

But the post treats proof as the finish line. Proof is the first lap.

I handed Fleetwise to an engineering team after proving it worked. That handoff went well because I understood what I'd built: how it was structured, where it was fragile, what would break at ten times the load. That understanding gave me standing in every architecture conversation that followed. Without it I'd have been a stakeholder with opinions; with it I could actually co-author the decisions.

The same thing played out at a different scale on Merdeka Mengajar. A platform reaching teachers across 17,000 islands cannot be vibe-coded into existence. The proof was fast. The system decisions after proof were slow and consequential. Which data lives on device because connectivity is unreliable. How the SSO layer for Akun Belajar.id handles tens of millions of accounts without creating a single point of failure. Those conversations require someone who understands the material, not someone who can describe intent to a tool.

Sol's 68% vs 33% split by company stage supports this reading. Early-stage designers code because they need proof. Public-company designers code less because someone else handles production. But the designers who shaped those public-company products, the ones who actually led, understood the production layer well enough to make trade-off calls. They proved ideas and then stayed close enough to shepherd what those ideas became.

Taste compounds. Tools commoditize. Code literacy builds taste about what software can and cannot do under pressure, and that taste doesn't expire when the vehicle changes. A designer who vibe-coded a proof but cannot reason about the system at scale will lose influence right when it counts: after the idea is proven and the hard decisions start.

Sol is right that code was never the point. But material fluency always was.