Skip to main content
In the back of my mind, I’ve been thinking a lot about what’s going to happen to software developers. In a metaphoric way it feels like an existential question, given that, well, I’m a software developer. The real answer is that nobody really knows. But we can guess and speculate, and sometimes that speculation is what helps build reality. There’s of course the doomsday scenario that we just all go away, but then what? Are we all unemployed and our skills intransferrable to anything else? I tend to be optimistic and think that there won’t be a sudden shift but rather that gradually we’re going to adapt and morph into new job titles (both new as in existing job titles that are new to us but also totally new job titles) but there will probably be side effects coming in the form of mass layoffs and the like, justified or not. It’s of course silly to speak of “software developers” as a class because it’s so broad, and I think it’s clear we’re not all going to the same place when it’s all said and done. Probably because despite the shared title we weren’t even in the same place to begin with. It’s the same with “engineer” — there are mechanical engineers, civil engineers, electrical engineers, chemical engineers, and even we’re sometimes called software engineers! For simplicity’s sake, I’ll narrow down my scope. I think there are broadly two classes of software developers: the “software as a means-to-an-end” ones, and the “software as the end” ones. Now, before we’re all up in arms and I haven’t even truly started this post yet, of course reality is a lot murkier and all of us are a combination of the two in some sense, but I do think this is a valid separation for the purposes of this discussion. The “means-to-an-end” devs are those that write code because code lets them build things. Code is the means to building a company, or a home automation system, a blog, a website for your friend’s wedding. That doesn’t mean this class of devs doesn’t enjoy code or appreciate the beauty of well-written code and well-designed systems, but it means that they would have built that website with a no-code tool if that no-code tool truly let them build it just how they wanted it. Boris Cherny, the creator of Claude Code, constantly talks about how he’s in this category. This is also the category I’m myself in. The other category, the “software as an end” devs, are the ones that are generally more math-inclined, took part in coding competitions, enjoy dealing with and optimizing algorithms, and so on. They are really happy to code just to code, even if it doesn’t necessarily produce a product in the end. Writing beautiful performant code is often enough of a kick. Again, this does not mean these people don’t, can’t, or aren’t interested in building products. Just like being in the other category does not mean you don’t actually enjoy the process of writing code. Come to think of it, I think these categories are a lot more about “what got you into this” rather than what you actually end up doing in this space. But what gets you into something is also relevant for determining how you’re getting out of it. So I wanted to talk about the “means-to-an-end” folks, since that’s where I fall. What’s gonna be of us? In some ways, this AI revolution (or whatever we want to call it) should be the best thing since sliced bread. You can prototype faster, try more ideas, build things in spaces where you don’t have all the prior skills (like a new programming language), and overall just build more. The whole goal was to build stuff, right? You can build anything quickly now, let’s go! On the other hand it also means that people who want to build stuff just like you but didn’t take the time to learn code can build things now too, so you’re no longer special. Not only are you not special, but before this, a domain expert needed you to turn their ideas into reality, and you needed them for their domain expertise. Now, they don’t need you but you still need them. I think it’s clear that AI has changed and will continue to change our jobs. This is indisputable. We can debate on how true the 10x, 100x, and 1000x claims are, and how steep or not steep the curve is — but things have changed and we need to change too. With that said, here are a few possibilities I can see. It’s important to note that we’re not talking about a distant future here, more like a 5-10 year timeline, and in world terms, not SF terms.
As a side note, the SF vs world thing is something I think we overlook often. The first fully autonomous Waymos started roaming around SF in 2022, and while they feel normal now, my hometown in Brazil is probably not going to see self-driving cars for at least half-a-decade more still. Hell, most cars driving around in Brazil are still using manual transmission.

​
The business-as-usual case

We all know that today software devs are much better at building software with AI than non-devs are. Vibe coding is all the rave and platforms like Lovable exist but knowing how to structure your data models, architect your system, and what tools to use is still massively relevant. Non-devs can build things now with AI that they couldn’t before, but they’re far from being as good or as fast as a real developer with AI tooling. If you believe we’re going to hit a plateau soon or that at least the rate of improvement will slow down, it means that the tooling will change, but the job won’t change that much, and it will mostly be business-as-usual. Software development has seen many step changes over the years and AI will just be one more. The ecosystem of tooling around models will get better and just like most of us moved from the terminal to the IDE back in the day we’ll move from the IDE to… the terminal? Anyway, job titles and org charts stay roughly the same, maybe some types of people leave the industry, some new types of people come in, but it’s basically BAU. In a few years you look back and probably you are indeed 10x faster, just like people got faster with high-level languages, and Git, and the Web, Cloud, containers, and so on. You need to adapt but not radically change.

​
The product builder case

One little prototype I vibe-coded this year with my dad in mind was a platform that let non-technical people build apps for themselves to help them in their everyday lives. If models are still getting much better, that means it should soon be possible for everybody to really code and build apps. As we’ve seen, there’s a clear interest from at least some number of non-coders to build apps, but there’s one thing I’ve been reflecting on while building this platform and talking to friends about these ideas: does everyone really want to build stuff? I think a lot of the talk is about how non-technical people don’t build apps because they don’t have the tools or the means, but I think we’re ignoring the possibility that a bunch of them just don’t want to actually build products and apps. Even if you’re not writing the code, building a product means spending a lot of time thinking, designing, prototyping, and debugging (whatever shape this takes), and I think a lot of people just don’t want to do that, even if it’s done by using natural language exclusively. Sometimes we pay for software very much because it’s embedded with someone else’s opinions and ideas about how something should work, and we trust that that’s better than what we can come up with ourselves. These are the apps we call opinionated and we like them because they remove the paralysis that comes with choice and force us to work a certain way that is often super helpful to us but that we couldn’t self-enforce. We also pay for software because we trust that it will have fewer bugs and be more secure than something we’d build. We pay for it because there’s customer service to help us when we have problems. We pay for it because we just don’t want to think about any of it. So many things have made it easier for us to cook these days, and day-to-day cooking doesn’t really require some special skillset that you need to get a degree for. We have machines to chop for us, do the dishes for us, we have machines that turn on and off automatically, we have online recipes, and even machines that cook whole entire meals by themselves. Some people just don’t want to cook. What that means is that there is a world where, yes, more people can suddenly build things, but we still need people to actually build things. Because not everyone will build for themselves. The job changes a bit, and it becomes more like “product builder” than “software developer” but we were already kind of moving in that direction anyway with all the talk about “product engineers”. While we transition, some code is still written manually, but soon it probably goes away and product builders just use natural language. But they have taste, they study design, they study psychology, they learn to balance AI and human input, and they keep building products. Maybe there’s a world in which we have fewer of them, maybe we have more. But these people exist and they’re very much relevant.

​
The PM case

Some time ago, the Claude Code team started doing office hours. User interviews are nothing new, and while they’ve traditionally been more of a Product Manager thing, this newer wave of “product engineers” also engages in interviewing. What struck me was that I don’t think I’ve heard of many instances of developers from a highly successful product opening up their calendar like this to talk to users. Particularly because I imagine the demand was insanely high. It got me thinking that, at least for me as a “means-to-an-end guy”, if AI frees me up to spend more time with users and on higher-level product thinking, that’s not that bad of an outcome at all. I’ve always cared about high-level product direction, I’ve always cared to talk to users. But a lot of my time simply had to go towards writing code. Building a feature request from a user could take days, so I can’t afford to go in and talk to users as often as I’d like and get five requests, spec them out and build them. But if coding is truly “solved” as they say, or if it comes to be at some point, maybe that frees up more time for higher-level thinking, strategy decisions, and understanding requests more deeply before building. Maybe we’ll spend a lot more time talking to users. And if that happens, are we then becoming kind of like PMs? Maybe developers become PMs and their team is composed only of agents, or at least in its majority of agents. Direction and coordination are maybe even more important if we’re talking about a combination of humans and agents. The question then becomes: can the world even sustain this massive influx of PMs? I don’t know. Maybe. It could be that there’s more software to be built, as has been the case over the last few decades. We got more efficient at building software, we built more software, we got more devs and PMs to build that software. It could be that indeed we move towards companies with much smaller headcounts but we have more of them. In any case, the devs that really just cared about product in the first place go on to manage teams of agents and build them. There have always been many different types of PMs anyway, so there’s space for different brains and personalities here.
The scenarios I’ve laid out above are all about developers staying within the software realm, and there’s of course the scenario where the disruption is far greater than I’m imagining and most of us need to move towards non-software things, but it’s hard for me to visualize it. Nevertheless, my point here was to show a few of the ideas and directions I’ve been considering, and I’m keen to hear from others what you’re thinking about too. I’m not super online, so I’m not sure what the current chatter is about where devs are going, and these are just ideas I’ve come up with through my reflection. I actively try to see both sides, and I’m a bit worried about where some of the AI stuff is going, but I’m choosing to be optimistic. And if we cease to exist, well, it was a good run at least.