Why are we so afraid of code as a commodity?

The Real Question Behind AI-Generated Code

Most conversations about AI-assisted development start with the wrong question: will it automate our jobs? A more useful framing, argues Figma CTO Kris Rasmussen, is to ask what engineers uniquely do well, which problems AI can actually solve today, and where the space remains for human judgment. That distinction matters because the fear itself—that code will become a commodity—may be misplaced.

Rasmussen points out that modern product design tools like Figma already store designs as a form of code internally. Converting those designs into components written in TypeScript and React or Kotlin and Jetpack is essentially a translation exercise, not unlike moving from Python to C++ or Java to Kotlin. Most engineers don't aspire to spend their days on language-to-language translation, so AI handling that work should sound like a positive outcome. The question is whether translating pixels to code should feel any different.

The Limits of Commoditized Code

Even if AI can reliably turn mockups into production-ready code that leverages modern UI frameworks, engineering is about more than producing lines of code. It's about knowing which problems deserve solving and how to approach them. It involves designing and understanding abstractions that help teams reason about complex systems—and doing so correctly and simply.

The best engineers reason from first principles about the higher-order domains they work in, without over-rotating on the quirks of a particular language, framework, or platform. That expertise was already diminishing in value before generative AI arrived; specializing in React or Jetpack alone only carries you so far. What won't be commoditized is the ability to identify and interpret what users need, then compose elegant, maintainable systems around those needs. That's where AI-assisted development still comes up short. Engineers will keep working through technical challenges from the ground up, making sense of context and constraints, even if AI accelerates parts of that process.

Engineering as a Creative Endeavor

Figma software engineer Ricky Rajani sees AI automating rote work, which he considers a good thing. The more interesting effect is what it unlocks: creativity. There are always multiple paths to building something, and AI can surface approaches engineers wouldn't otherwise consider. Weighing those tradeoffs remains the engineer's responsibility. The true art of engineering, in his view, is using constraints creatively to suggest solutions and guide better product decisions. Technical systems and implementations aren't just engineering challenges—they're creative endeavors.

Roles Shift Toward Higher-Level Work

Vincent van der Meulen, also a software engineer at Figma, notes that his workday no longer starts with writing code. It begins with conversations with teammates, triaging which user problems to solve and how to solve them; code comes only after that direction is set. That model has grown more pronounced over the past few years and will continue shifting toward prioritization and alignment as implementation shrinks as a share of the job.

As AI automates lower levels of the tech stack, the abstraction layer keeps getting bigger while the details engineers must worry about get smaller. For engineers, code becomes an implementation tool; for designers, it becomes a medium for interactive prototyping. As code is commoditized, designers and product engineers can spend more time on user problems, and those roles will move closer together. Van der Meulen identifies more as a design engineer than a traditional software engineer—and suspects many others will too.

New Archetypes: The Architect and the Design Engineer

Michael Bullington is hesitant to claim AI makes people more productive in the usual sense. People keep getting tools that make them more productive, yet their productivity generally stays the same. Instead, AI raises the ceiling on the technical challenges teams can take on, leaving room for more ambitious ideas and deeper actualization. With reclaimed time, engineers can focus less on what the solution is and more on understanding and prioritizing the right problems, shifting from "how" to "why."

Bullington imagines two archetypes emerging from this shift. The first is the architect: someone who thinks through backend services, systems, and infrastructure. The second is the design engineer: an engineer who moves into the design space. Taken to their logical extremes, both lead to good outcomes. Engineers will need to interface better with design teams and adopt their values while also having the agency to think more deeply about technical systems.

Velocity Over Productivity

Tommy MacWilliam, an engineering manager at Figma, acknowledges that infrastructure engineers in particular tend to be skeptical of AI, worried it's all a bubble and that it will take away rather than add. He's optimistic: the point isn't subtraction, it's enabling teams to do more than they can today.

There's a theory that if AI turns every engineer into a 10x engineer, an AI-powered team could be 10% of the size. MacWilliam doesn't buy it. Teams will ship more instead. What it means to be a good engineer and a good company will change: engineers will spend more time on higher-order work like initial design, collaboration, and last-mile review, while AI handles the rote mechanical work in between. The result will be more things built than ever before.

He also warns against underestimating the rate of exponential change. What seemed impossible six months ago is a working demo today, and if that trend continues, the future looks very different from what people expect now.