Why are we so afraid of code as a commodity?
Instead of asking how AI will automate our jobs, we should be focusing on what we, as engineers, uniquely do well. What problems can AI currently solve, and where is the whitespace to go beyond that?
Illustrations by Jiyung Lee
With the rise of AI-assisted development, many people are wondering what engineering roles and workflows will look like if design to code is automated. By now, most of us assume that AI can—or will in the near future—translate one programming language to another as effectively as software engineers. To me, this sounds like a positive outcome; more efficiently going from Python to C++ or Java to Kotlin isn’t something any engineer I know aspires to do exclusively. Should we feel any differently about translating pixels to code? As it turns out, modern product design tools like Figma already store designs as a form of code internally. Converting them into code components with TypeScript and React or Kotlin and Jetpack is akin to translating between programming languages.
So AI might automate going from one language to another. It might help us write lines of code more efficiently. And it might help expedite the process of going from design to code. But even if AI can translate mocks into code that leverages modern UI frameworks, does that mean you don’t need to know how to do your job?
There’s so much more to being an engineer than just outputting code. It’s also about knowing which problems to solve and how to solve them. It involves designing and understanding abstractions that help us reason about complex systems. It also requires solving those problems correctly and simply. The best engineers are ones who can reason from first principles about the higher-order domains they are working on without over-rotating on the nuance of a specific manifestation of that domain—a language, framework, or platform du jour. Even before this new wave of generative AI, specializing in React or Jetpack could only get you so far; nuanced platform-specific expertise diminishes in value over time in comparison to our ability to reason from first principles about what these frameworks have in common.
There’s so much more to being an engineer than just outputting code. It’s also about knowing which problems to solve and how to solve them.
What won’t be commoditized is being able to identify and interpret what users need and how to compose elegant, maintainable, intuitive systems around those needs. That’s where AI-assisted development continues to come up short. There will always be room for engineers to work through a technical challenge from the ground up, to make sense of context and constraints, and to build elegant solutions to user problems, even if AI is helping us do this faster and more efficiently. Whether AI automates design to code misses the point—and that’s a good thing. I’m excited about where we’re headed, and I know engineers on my team are, too. Here’s what makes them optimistic about the future.
On the art of engineering
My sense is that AI will automate rote work, and this is ultimately a good thing. Will it compress some parts of my job? I’m not sure. But it’s so much more interesting to focus on what it will unlock: creativity. Everyone can be creative on their own, and AI supports us in being even more creative, more often, by exploring approaches we otherwise wouldn’t have considered.
In my experience, there are always 10 different paths to building something, and AI will only open our eyes to new ones; it’s up to us to weigh the tradeoffs. The true art of the engineer is using constraints creatively to suggest solutions and help teams make better product decisions. Technical systems and implementations aren’t just engineering challenges—they are creative endeavors.
On embracing role shifts
When I go to the office, I don’t immediately start writing code. I chat with my teammates and triage which user problems to solve and how to solve them. Only then—once we’ve determined what to work on—do we turn our attention to code. This working model has become more pronounced over the last few years, and it will continue to shift more towards prioritizing and aligning; implementation will make up an even smaller part of the pie.
With AI, the abstraction keeps getting bigger and bigger as the things you have to be concerned with get smaller and smaller. In practice, this means that AI automates lower level parts of the tech stack and allows us to go higher up in the tech stack. For engineers, code will just be an implementation tool; for designers, it will be a medium for interactive prototyping. Put simply, as code becomes commoditized, designers and product engineers will be able to spend more time on user problems. And in doing so, these roles will move closer together. My title at Figma is “software engineer,” but I identify much more as a design engineer—and I suspect that many others might, too.
With AI, the abstraction keeps getting bigger and bigger as the things you have to be concerned with get smaller and smaller.
On finding new ways to engineer
I’m hesitant to say that AI makes people more productive; people continue getting tools that make them more productive, but their productivity generally stays the same. Rather, AI raises the ceiling on the technical challenges we can take on. It leaves space for more actualization and more ambitious ideas. With the time we get back, we can focus on the core of the problem we’re trying to solve—less on what the solution is, and more on understanding and prioritizing the right problems. Instead of asking “how,” we’ll learn to ask “why.” We need to stay curious about why things work the way they work.
I imagine two archetypes emerging: the architect, someone who can think through backend services, systems, and infrastructure, and the design engineer, an engineer who flexes into the design space. If you take these to their logical extremes, they both lead to good outcomes. Engineers will need to better understand how to interface with design teams and adopt their values, while also having the agency to consider our technical systems more deeply. I'm excited for a world where AI gives us space to make our computers technically simpler, benefitting both ourselves and creating abstractions better suited to AI-driven development.
This article is part of The Prompt, an online and print magazine by Figma and designed by Chloe Scheffe.
On prioritizing velocity, not productivity
I know some engineers, especially infrastructure engineers, tend to be a bit skeptical of AI and worry that this is all a bubble. The cynical view is that AI is going to take away rather than add. But I’m optimistic: It’s not about taking, it’s about giving us a way to do more than we can today.
There’s this idea that if AI enables every engineer to become the fabled 10x engineer, then an AI-powered engineering team would only need to be 10% as large. I don’t think that’s true. Teams will ship more. And, what it means to be a good engineer and good company will change. Engineers will spend more of their time on higher-order work, like initial design, collaboration, and last-mile review, leaving AI to tackle the more rote, mechanical work in between. The result is that we’ll see more things being built than ever before.
If you think about what the future looks like, it’s something we can barely imagine. People often underestimate the rate of exponential change. And that’s what we’re seeing in AI—what seemed impossible six months ago is a real demo today. I’m pretty excited to see what the world looks like if that trend continues.
Explore the rest of The Prompt, a magazine available online and in the Figma Store as a limited print edition.
Kris Rasmussen is the Chief Technology Officer at Figma, where he leads the engineering, security and data science teams. Prior to joining Figma in 2017, Kris served as engineering lead and a technical advisor at Asana, where he co-authored many aspects of the framework and infrastructure that powers the company's realtime collaborative features. Before Asana, Kris co-founded RivalSoft Inc., a web-based application that gives companies an internal hub for market information, and served as Chief Architect at Aptana.
