Taste and Tradeoffs

October 10th, 2024


All meaningful code used to be written by humans, but it's not anymore. Today, somewhere between 20-50% of code is generated by AI copilots, and in just a few years virtually all new software will be created by autonomous agents. So what will happen to software engineers? Is it still worth learning how to code?

I've been writing code as a Google engineer and startup CTO for over a decade, and after using (and already relying on) tools like Github Copilot and Cursor, it's clear to me that creating software is already fundamentally different than just a few years back. Language models make the work faster and more enjoyable, and they'll only get better from here. However, two skills will resist automation and become crucial for future software engineers to master: the ability to decide system tradeoffs and an excellent sense of taste.

Software Engineering Today

Modern software engineering relies on engineers to hold a ton of information in their head and bring abstract ideas to life with code. They must be fluent in the syntax of relevant programming languages and have broad knowledge of available tools and frameworks. They must be aware of their existing codebase and understand previous implementation choices. They need to be able to coordinate with product managers, designers, and other engineers to determine what to build. Then with all of this context, they must be able to fit structure around ambiguous features and physically type it all into a computer. Assuming they nailed this translation on the first go (it rarely works that way), they then test their work and iterate until the project is complete.

This all encompassing software engineering role will seem archaic and amazing a decade from now, probably similar to how I view the legendary programmer Chris Sawyer that made RollerCoaster Tycoon in assembly language (so insane). Honestly, we have it pretty good today, but the next generation of software makers won't believe the way we did things.

Where We're Headed

Soon, engineers will orchestrate swarms of coding agents that take ideas, map them onto a project, build it, test it, and iterate until the result works perfectly. With human directions and automated code generation, the speed of “typing” and "filling in the implementation gaps" will increase 1000x allowing for massive refactors, perfectly optimized changes, and debugging loops to happen without human intervention.

The time to make software will drop to essentially zero. If you can articulate your thoughts, agents will be ready to turn your intent into code. Having the right thoughts becomes the challenge, and this skillset will become core competency of software engineers. Boiled down a step further, the differentiating directions to communicate will be around system tradeoffs and making a tasteful product. Everything else will be automated away.

Let's explore each skill and how to develop them today.

Tradeoffs

As long as we live in a world constrained by physics, computer science, and money, software engineering will be a game of tradeoffs. For every implementation decision there’s a negative tradeoff to consider, and that's as true today as it will be in the distant future. An engineer must make decisions on platform dependence, system architecture, and key algorithms all with implications on latency, accuracy, cost, reliability, and ethics. Great software engineers know when they are making system tradeoffs, how to evaluate their decisions, and generally make the right choice. Those choices will still be relevant when agents are writing our code.

Top engineers will know a wide variety of the platforms and tools at their disposal and understand their pros and cons. They'll know when to specify implementation details and when to give the agents free reign. When they sense a critical tradeoff, they'll ask the right questions and adjust the product accordingly. They'll have total system awareness, but not deep system fluency (just like I can't read assembly code but understand bottlenecks in a product today).

It's worth noting that any tradeoffs related to developer productivity will no longer be relevant. All engineering teams today grapple with prioritization: should we build feature A, build feature B, or fix tech debt C. Those decisions will be a thing of the past, and you'll have free reign to build with unlimited engineering effort. With all that freedom, building the most performant, low cost, and useful system becomes all the more important.

Developing intuition to make good tradeoffs today is fairly straightforward: make more product decisions. Building your own technical projects from scratch is a great way to do this, and one of the key reasons I think learning to code will still be relevant in the future. Once you start thinking of your project as a series of tradeoffs expressed through code, you’re thinking like an engineer.

A software engineer who understands the innards of their system will communicate with an AI agent far more effectively than someone who only knows the system at a high level. To stay relevant, my advice is to get building today, practice weighing the tradeoffs you encounter, and learn how to communicate your choices.

Taste

Having great taste is difficult to develop and arguably a more valuable and differentiating skill in the future. Great taste leads to great design in everything from the aesthetic of a product to its user experience. It’s a skill that's as much artistry as science, and is deeply human in nature. Concerningly, I'd argue that few software engineers today truly have great taste.

A top software engineer will need to know a wide variety of successful of successful software products and be able to articulate what gives them an edge. They will have deep intuition of what looks and feels right, and they will be opinionated in a unique style that makes their products stand out. Their combination of deep technical understanding and human-computer interaction design intuition will lead them to build seamless products that separate them from their peers.

Developing taste comes from using great products, launching great products, and internalizing feedback on your work. Some have a knack for taste, and others will have to work at it. But good taste for building software products can certainly be earned. (As an example, my earliest projects were garbage in every way. Now they’re not too bad.)

As agents get better and require less human intervention, a less experienced maker will be able to create fancier products. But, these novice creators won’t stray far from the defaults inherent in AI models and end up building indistinguishable products. To break out from the crowd, you need to develop good taste.

How Long Will These Skills Matter?

It’s hard to say how long taste and tradeoffs will be relevant, but in my opinion they’ll certainly be the last human software skills automated away. Today in the copilot phase of AI, writing code and debugging are becoming relics of the past. Soon in the age of agents, makers will be able to think bigger because the smaller details will be handled. In the farther future, agents may even self organize and make higher level decisions themselves, but let's not get too far ahead of ourselves. As a software engineer for at least the next five years, it's going to be an incredible period if you can take advantage of the opportunity.

To get ahead today, build something. Make a new project. Use new tools like Cursor and Bolt. Launch what you make to real users and get offensive feedback from someone anonymous online. Develop a sense of what’s good software and learn how to make it run quickly, cheaply, and reliably.

I'm excited for a future where we can translate our ideas into live products faster than ever before. Embrace the change, learn taste and tradeoffs, and stay relevant with me!

I'm currently researching how to make agents cheaper and more useful, so please reach out if you'd like me to share what I've found. Thanks to Alexander Lee, Adam Hardej, and Nic Mahaney for feedback on drafts of this post. I'd also highly recommend reading Paul Graham's essay on taste for makers.