This concept of like promotions and titles and that game of growing your career—it sounds like you're just rejecting it wholesale.
I am.
Today we're speaking with Tuomas Artman, CTO of Linear.
There's no machine that is capable of telling you how a user feels when they interact with your application. Atlassian had been around for ages and everybody in the industry was using project management software. You need to build a better product.
No, I think it makes sense theoretically, but if that was a winning strategy, why isn't every company quality focused?
It's hard to do after the fact. You have to hire for that.
So, on a scale of 1 to 10, as the CTO of Linear, how worried are you that what you've built is going to become obsolete as AI gets better?
Today, we're speaking with Tuomas Artman, CTO of Linear. Thanks for coming in to have the conversation.
Thanks for having me.
You dropped out of the University of Helsinki when you were 18 years old, eventually became an engineering manager at Uber, and then a senior staff engineer before becoming the CTO of Linear. If a degree isn't necessary for success like yours, what is?
It's raw talent that I think is necessary. I would think that today maybe a degree is necessary. I'm an old-schooler; I went to study in the year '96, so I've been engineering for 30 years. Back then I thought to myself that this is not worth my time. I dropped out after one week in uni because the first course that they trained me on was Programming 101 with Pascal. I went in and I was like, "What are we doing here?" Pascal, really? Java was around, the internet had just started getting started, and I just felt like they're way too late to the party. I want to learn something of value.
I immediately got a job doing some programming. Back then it was multimedia CD-ROMs that I was working on. But I realized, even just a few weeks in, that I'm learning much more doing my job than I would have in the university.
Was it the incongruity between what you were learning in school and what was happening with computers and the internet back then?
Definitely. I wouldn't know how to use Pascal even back in '96. There literally was no job that I was interested in that used it. It was all about HTML and Java; Java maybe was one of the core languages that was raising its head. Sure, the university had some degrees just getting started with Java maybe a year after I dropped out, but it was still too late to the party.
Well, when you quit university after the first week, did you have a plan at that point or did you just kind of throw yourself into the wind?
So, yeah, I did have a plan. It was very different from what you would do here in Silicon Valley. I come from Finland where everybody actively does consulting. That's the thing there; you don't dream big. There wasn't really a startup scene at all back in the day. So, I went into consulting. I was working on creating multimedia CD-ROMs for big corporate customers. If you ever had a Nokia phone that came with a CD-ROM with instructions on how to use that phone, chances are that was made by me or the company I was working for.
I had done programming before. I had an Amiga—that's where it all started—and I did some C++ on that. My first application that I ever wrote was called AceStart. Windows 95 had just been announced and I really liked the start menu that they had, so I recreated that for the Amiga. I put it out as shareware, and it got featured on one of those German Amiga magazines with a disc that came with it, and my software got released.
Would you advise Tuomas in 2026, at 18 years old, to drop out of school the way that you did?
No. I would go through school really quickly because I do think that you get a very sort of fast-track experience in what you need in your daily job. I do think that the four years that you would now spend in the university would be really worthwhile.
Well, I guess what's the difference? You will still probably take a course on some programming language that doesn't have applicability in the real world.
I think the applicability is much closer to reality these days. You would be taught Java, you would be taught maybe Swift, maybe Kotlin—any of these languages that you can use today. I think schooling just has caught up. I lived in this time where maybe there was 10 years where you could learn much more doing it yourself than you could get out of school. I don't know if that was the case in the US; I'm just referring to Finland and how it was in Europe at the time.
So you've been really intentional with your career since the CD-ROM days. What did you prioritize in terms of what you were looking for?
I made all the mistakes up front. Looking back, I think the time that I spent in consulting was just years wasted. It's the biggest regret of my life. My past is split into two: all the consulting things that I did in Finland—I started my own company back in the day as well, ran that for nine years doing general consulting for all these customers in Finland and maybe a few international ones as well—and I just really didn't understand that I would have to be in the US in order to really start up and gain experience from the ecosystem here.
It was almost luck how I got into San Francisco. I moved to China in 2011 to work at a startup over there. At that point, I had realized consulting is not for me. I had spent 9 years on it and it was somewhat lucrative—I had a nice life—but it didn't really go anywhere. At some point, I realized that I want to build something of my own, something that I can sink my teeth into and not just spend 3 months on a project, throw it over the fence, and move on to the next one. While I was there for a year, a friend of mine sold his company to Groupon in San Francisco and he called me up because he needed more engineers to bump up his sale price, and that's how I got in.
So, hypothetical Tuomas from 2026 who's 18 and lives in Helsinki—you would be like, "Go to the US, or maybe go to college and then after college move to the US."
Yes. Do whatever you need. If you're European, your sole focus should be to first of all—I think the best way to get into the US is to start with a company that is US-based and work in Europe, and then maybe take a manager position and be transferred over within a year of working there. But your sole focus should be on getting into Silicon Valley. Work here for 3-4 years, learn the ropes, get exposed to the magic of Silicon Valley, and then do whatever you want after that.
It's almost an extension of your university. Uni gives you the skills to be an effective programmer, but you don't learn the mindset that people have in Silicon Valley. The one thing that I really dislike about Finland is that they do have really good education and excellent programmers—really good engineers—but what they lack is this belief that anything is possible. They're very pessimistic to start with, and if you are a pessimistic person, you won't be jumping into a startup. Everybody's mode is sort of like, "Oh, it's going to fail anyways. There's only a 10% chance of succeeding, why should I even try?" And that's how people get into consulting and spend their lives wasted, in my mind.
If you're a regular listener, Linear sponsors this show. This conversation with Tuomas is a perfect example of why Tuomas built Linear exactly the way he wanted to. There are no levels, no promotion culture, no internal emails. He doesn't tolerate any bugs. The guy still commits code every day as CTO. I asked him about strategy and he said that the only strategy is quality. That's it. And honestly, you can tell when you use the product. Engineering is changing super fast right now. Agents are writing code, AI tools are everywhere, and Tuomas built Linear with the same stubbornness he brings to everything else. They've figured out how agents and AI fit into how you build software day-to-day. The best tools in this new world manage context. Linear is the best context for any project. Simple as that. Check them out at linear.app.
Yeah, I grew up in the US, so I'm just coming to realize that America has this sort of bubbling enthusiasm and can-do attitude. I thought just everybody had that by default. Then you go to Europe and everybody's just like, "Ah, why are you trying so hard?"
Nope. That is the differentiator. To some sense, it makes sense to be a bit pessimistic as well, but you need the optimism in order to build a big company that is highly successful.
So when you worked at Uber, you were a manager, and then I saw in your LinkedIn you became a staff or senior staff engineer and worked on the framework for mobile development within the company?
That was one of them. I think I was just a manager, not a senior manager. I started as an engineer, and as Uber grew, my manager came to me and said, "We need a manager for the platform team, do you want to be it?" and I stupidly said yes. For the next 3 years I was a manager and hated it in some sense. I like the experience that I got out of it—I think it made me a better engineer and a better person to begin with—but I really disliked managing and solving the problems of people. I didn't like that I wasn't able to spend 100% of my time just programming.
So I'm interested in the manager versus IC ping-ponging. Was the managerial part just out of necessity so that you could get entree into bigger IC problems?
Yes. I think the managerial aspects—you could break them apart into two. The fact that I didn't like managing at Uber was because I was just asked to do it, and I want to be a good player and say yes to everything that I'm asked of. I jumped into it without really asking myself the question of whether that's something that I want to do. I did that for three years, and my manager had to see that I really hated it and he then got me out of it, which I'm super stoked about. I was happy to get back onto the IC track.
During that time, I realized why I don't like it: because I was a frontline manager. I was just a pawn in the middle of it, and it was all about politics and shielding your team from asks from above. That's not what I wanted to do; I wanted to build product. I'm happy with having some managerial responsibility at Linear now because it's the thing that I'm building. I'm not building somebody else's application; I'm building mine. If I'm a manager, I can help myself do whatever I want in the product. I'm still working most of my time in code; I'm still programming like 80% of my time.
Really? Even as CTO.
Yeah.
I think I understand the apprehension or the unhappiness or frustration around being a frontline manager. The reality is that most people are going to be reporting into some sort of manager. So what can somebody do in their career if they'd like to stand out?
I think the most important thing you need to do is find a company where you want to work on the product. Get yourself into a mission that you want to work on. That's the most important thing. Obviously, there's the politics part which I still dislike. I'm happy that I got the experience out of Uber and maybe Groupon to some effect as well on how that all works, but I thoroughly dislike it.
We want to build Linear in a very different manner. Particularly what I didn't like—and I think it applies to many companies in Silicon Valley—is that you have this duality in your IC engineering where you're supposed to be building this product and you're supposed to help the company become better, but on the other side, there's some requirements that you have to fulfill in order to get promoted. Well, what is more important as an engineer in your life? Is it the promotion or is it the product?
I think it changes when your company is small. You think about the product; you have a lot of options which might be super worthwhile if the company makes it, so you're focusing on the product itself. But once you get to a thousand engineers at your company, you realize that you're just a small piece in the big pond and your contribution really doesn't matter that much anymore. So it becomes more important to you to sort of make sure that you get promoted, get the salary increase, and get a bump in salaries. That's when you start playing that game.
You don't really look at the product anymore, which is what you should be doing, but you think about yourself. You go through the rubric. You come up with projects that might make no sense to the company, but will be looked at as impressive examples of engineering which might then get you promoted. I don't know how to change this or whether it's possible to change at these large companies, but I wish there was a large engineering company that would not go down this route of having this rubric and having managers where one of the big responsibilities of a manager is to help engineers go up that ladder and get promoted.
I had a former manager at Uber who went to Confluent. Confluent used to have no titles at all. Everybody was just an engineer and things were happy; everybody was just working towards the product and creating the best work that they could in order to make the product successful. My previous manager at Uber was the head of engineering at Confluent, and managers would come up to him regularly saying, "We need titles." He was like, "Why are you asking me? Everything's working fine, everybody's working towards the product and everything's great." He realized that it was usually mid-level or frontline managers who were asking for titles.
A frontline manager's purpose in life is to promote engineers that are working for them. That's one of the big aspects of being a good manager: to help your team grow and get from senior to staff and whatnot. Eventually he buckled in; after many years of getting this feedback of needing titles, he gave up and said, "Okay, let's put in titles." They had 500 engineers at that point. Overnight they implemented titles and they figured out who's a senior, who's a staff, and whatnot.
That day things changed. People weren't building the product anymore, but they were like, "Hey, hold on, why am I a senior engineer and this guy is a staff engineer? I don't think my title is right; I need to get promoted immediately." They started effectively working towards their titles. According to the story, that was the time things really changed for the worse when titles got introduced. So, yeah, I wish they had gone without titles longer, and I think that's what we tried to do at Linear.
What I'm hearing is that to stand out in your career optimally, you would just do the best thing for the product or for the company, and that would be the perfect world. So this concept of like promotions and titles and that game of growing your career—it sounds like you're just rejecting it wholesale.
I am. I absolutely love that.
And in your company, everybody is a senior engineer, right? Is that correct?
Yeah, everybody's a staff engineer. More like 90% of the engineers are staff. Sure, we do have people who are out of the uni immediately or don't have a career behind them, but we treat everybody as an engineer and that's it. If I had one reason to quit Uber, this would have been it: being a Finn, I'm super open and I tell how I feel about things. My feedback from my manager throughout those five years at Uber was, every single time, "Dude, you're too open. You should tone it down a bit. You shouldn't be questioning things that other people do, even though you're right. You should sort of play the game and be a bit more politically correct." I understood where they were coming from.
That's how everybody in the US works. I maybe tried to change it, but still my mind was on building the best possible product out there. During the last year, I had—not a falling out, but I berated one of the managers on the team that I was working on in front of the team, which is not what you do. I felt that he was really not pulling his weight and he was really bad for the entire project. I opened that discussion in front of everybody else. Obviously my manager came to me and said, "This is not great. You should tone down what you say out loud; it will be a problem if you want to get promoted. You cannot go down this way."
My question after that was, "Hold on, so you're asking me to care less?" and he was like, "Yes." That's when I was like, "Okay, I'm out." It doesn't make sense, especially if I'm right, which I think I was in that case and many other cases. If I really believe that what I was doing was for the better of the company and the product and the projects that I was working on, why should I not say anything? Why should I play this game of "let's be nice to each other" and not voice out or have confrontations?
Netflix was famous for only hiring top performers, I think very similar to the Linear model. Everybody was a senior at Netflix, and they just reintroduced levels, right? Now there are principal engineers and entry-level folks. Do you think that the concept of no levels breaks after a certain size of organization?
I'm sure it has to, and that's probably the reason why all the big companies have levels. It is super hard to manage 4,000 engineers and diligently give everybody what they're supposed to get—sort of level them across. Obviously we do leveling as well; we have top performers and we have people who've really done something in the industry and who contribute to the product maybe a bit more than others, and it shows in their compensation. So sure, you need that in order to build; not everybody can be equal. But at some point when you get a lot of engineers, I think it's easier to just bucket people up and it becomes an easier problem to manage that way, putting in boundaries for how you can cross from senior to staff and then just having a checklist of whether people are doing that.
"I don't like this promotion game. I'm going to go start my own company and we're not going to have any levels and it's going to be a product that I like." So that's the advice that you give then to people?
Yeah. If you don't like something that you're working on, choose a company that you enjoy working at or enjoy the mission even more, and thus you might be fine with the politics that comes with it. Or build your own. But building your own company is probably the last thing that you should do because you really need conviction and you really need to want to go through the pain of maybe never succeeding and working a ton of hours in order to make that happen. You should really think about starting up. If you're not 100% committed, if you think that there is even a slight other chance to get you to your objective, you probably shouldn't start up. You should only start up when you feel that there's really no other way. "This is the only thing I can do." And then get started, because it is painful and it usually doesn't succeed, and there might be much easier ways to make you happy.
There's a new trend with CTOs. All of this AI agent stuff is going on now, so now they're coming back into the game. They're firing up their terminals and getting their dev spaces working and starting coding. But it sounds like you've kind of been there this whole time.
I have, because that's what I want to do. I started the company so I can program, I can build it. To some effect, I've been very intentional about it. I've hired a team to take on the responsibilities that I have; we do have managers, we do have infrastructure leads and a whole infrastructure team, so that I don't have to be present 100% of my time leading that or working there. I can spend my time on stuff that I enjoy doing and stuff that I want to work on at the company.
I'm assuming that a CTO typically doesn't code if you just look at the industry, you look at all these startups. It's the exception that a CTO is a coder. Is there some CTO stuff that you should be doing that you're not?
The way we go about it as a company is to really make it all about the product itself. I think it's not just me, but everybody else on the team. The way we've structured the company is a way where the IC's work is the most important thing that happens. We have a product team of 65 people. We effectively have three managers in there who still contribute as well to some extent if they can. The rest is just ICs, and we try to make that happen as long as we can. I'm sure there will be some breaking points down the line where we need to hire more managers, but everybody we hire, we just want to get into the product and working on it. Karri, our CEO, is still designing; he's currently doing a redesign of the entire application, a refresh of the visual aspects of it.
Everybody who works here has not only the hunger to build the product, but also the means and the time to do so. I think what we did correctly back in the day, and why I don't really need to be active as a CTO, is we laid the groundwork very well. We did things that other startups probably would never have done. We spent, for example, half a year building a synchronization engine before we built any single product. Who does that? Uber didn't. It was very different for them, and maybe that was the inspiration for all of this.
What I saw at Uber was you have this idea of a product, you try out things, you try to find product-market fit. You build some crappy infrastructure to support that, and then suddenly you hit product-market fit and you're in a race. Things take off and you're scaling 2x every single week, and you still have this shitty infrastructure. Now your job as an infrastructure engineer or backend engineer becomes fighting the fires and turning it off. For the next two years while you're scaling crazy, you're just fighting fires. After those two years, your whole team—you've hired thousands of engineers to keep the flames off—you end up being a burned-out pile of ashes. Then you need to start everything again; you need to start building the actual infrastructure while your application is still running, and that will be a four-year effort. I didn't want to go through that.
I wanted to see if we could be a bit optimistic about this. We started in an industry where we knew that it had existed already for 25 years. Atlassian had been around for ages, and everybody in the industry was using project management software, so it wasn't a question of whether this will stick. The question was whether we will just build a good enough product for everybody to come over, at least get the ICs, and maybe from there we can go into the product managers and CEOs and CIOs. We took the time to lay the groundwork perfectly. From day one, we went into GCP and put up a Kubernetes cluster, which you wouldn't do if you were a startup trying to find product-market fit. We built half a year of synchronization engine work. The whole infrastructure team has always been working like that; we know what the bottlenecks are, and we know them maybe a year or two years in advance. We have plenty of time to figure these things out and implement changes without ever having to fight fires.
If you started Linear in 2026 instead of 2019, what would you do differently?
Maybe I would do things technically a bit different and obviously use AI to build most of this stuff, and maybe lean more into the agentic experiences immediately. I think what we set out to do still holds today because we had this simple idea—and it's so stupidly simple that it sounds like a cop-out—but we as a company just have one strategy, and that strategy is one word: quality. Nothing else really matters. Quality obviously can be many things: what you put into the product, how you make it work, the design aspect of it, the user experience, and interactions.
To us it was always clear that being in a space that has hundreds of companies and millions and millions of users that use these incumbent solutions, the only way for us to win is quality. Build a product that is just simply better—not only a bit better, but it needs to be 10 times better. Because if you have a company that is using a project management system, them moving over to Linear has a lot of pain in it. They need to redo their integrations; they probably have hundreds of them going into other systems, and it would be painful to switch over. In order for us to have a case to entice them to switch over to Linear, we just need to build such a product that is so good that they have this FOMO effect—they feel that they just have to switch over in order to get something better out of it. And that is quality.
Other than leaning into AI agents, you would essentially do the same thing—same focus on quality. Kind of blows my mind.
I did this talk a while ago around the MVP and Eric Ries's Minimum Viable Product. My thesis back then, before AI came around, was that people today aren't really building too much new stuff. Most of the companies that came around before AI came into a market space that was already there. You didn't need to prove that when you were building Airbnb you needed to prove that somebody would pay you money to come into your home and sleep on your couch or bed, or with Uber or Lyft that somebody would want to drive strangers around in their own car. It was a bet; nobody had done that before. But nowadays, most of the startups that exist just try to do something better and go into a market space that already exists and try to create a better version of it. You're competing against people already. Your MVP is not "see if this sticks" but "make it so good that people will switch over." That is why people have been starting to talk more and more about quality. You need to build a better product in order to make that happen.
No, I think it makes sense theoretically, but if that was a winning strategy, why isn't every company quality focused like you guys are?
It's hard to do after the fact. You have to hire for that. If you have hundreds of engineers that are not quality focused, you can't change it anymore. Or maybe you can, but it would be painful to do.
Well, you guys are famous for a zero bug policy. I can imagine you can't just be like, "Okay, we're zero bugs after this particular date." It would take years to pay down that bug total, right?
I don't know if it's years; it was sort of painful for us as well when we implemented it. It took us maybe 1 month or 3-4 weeks of just working on bugs and not working on product anymore. But it made perfect sense, and every company should have a zero policy. The reasoning that we had is a simple formula: you have bugs, and bugs will always be introduced into your product when people work on new functionality. You will be introducing bugs at a constant rate. So then the question is: when do you fix them? You have to at some point fix them because otherwise you have a defective product and you will just accumulate the bugs. What people tend to do nowadays is at some point they start to ease the curve so that the bugs remain super high but at a constant level. They keep on fixing bugs as quickly as new bugs are introduced. What you end up with is a product that has a lot of bugs but you still have to use the same amount of work in order to fix bugs.
Our thinking was: isn't it better to pay a bit up front—and the cost isn't really that high—to just decrease that bug count to zero? After that work, there's no extra work in the zero bug policy. You're still working as much as any company in fixing your bugs. What your users get out of it is, first, they get a bug-free product, which in itself is great. Secondly, I think it changes engineers in some way where they know that they have to fix a bug immediately when it comes in. That's the highest priority. So it might be that you won't be creating that bug in the first place or you test your functionality a bit better before shipping it. And thirdly, and this is maybe the biggest thing, your customers will be in awe. When they report a bug and 12 hours later that bug is fixed and they get an email saying, "Oh yeah, refresh and you're good to go," they will just be delighted by your product. And that again is quality.
What's the fundamental technical challenge at Linear? Why is issue tracking so hard? Why can't I just vibe code an issue tracker and be done with it?
You certainly can vibe code an issue tracker. But Linear is not an issue tracker anymore. Issue tracking is pretty simple to begin with, but project management is not. What is so hard is the sheer complexity of it—not only the UI but the set of functionality that make your team be better at building software as a whole. The thought that we have put into how data flows in the product, how your customer input comes into the product as an input stream, how you can then use that in order to figure out what kind of projects you want to undertake and then go and build those projects and create those issues and work on them—it's a very complicated thing. It requires a lot of integration points. We try to pull in data not only from PMs and engineers but from everybody—from Salesforce, from Intercom, from your bug trackers—and then just pipe that all into Linear in some cohesive and actionable way. You can now make decisions on the inputs that you get and then maybe have a fleet of AI agents to ship those features. But that is the complex part, and that's why I don't think you can just vibe code it.
So on a scale of 1 to 10, as the CTO of Linear, how worried are you that what you've built is going to become obsolete as AI gets better?
I think everybody should be afraid that they might become obsolete if they don't change things. If we don't do anything, I'm sure that we'll be obsolete at some point, but I think that holds true for every single company out there regardless of what they do. You have to change with the times, even without AI. If you don't do anything, if you don't innovate, if you don't build more functionality, you end up getting displaced by something—it might be AI, it might be a competitor of yours. I think we know what we want to build that will make Linear better with AI and that will help us become even a greater application as AI becomes more performant and better at coding things up or making decisions. We're having the entire team execute on that mission, and time will tell how that will work out. I think we're living in a super interesting time where anything can change at any given point in time and people will come up with new use cases and AI will make some use cases that were otherwise really hard to implement trivial in the future. But I'm excited about that future; regardless of whether we win or not, I think the future is great.
You guys introduced agents for Linear, so if I understand that correctly, you're treating an agent as another team member. There's no reason that they couldn't pick up a bug and then sort of fix it on its own and make sure that the state of the issue is tracked correctly and get it all the way out to production. Is that maybe an approach to going to zero bugs after?
Yeah, certainly. We use that internally already. So our flow that we have enabled for us—and anybody can do that in the Linear application—is to hook up, for example, customer requests or your support channels, be it Intercom or bug reports from your own people.
Just like literal bugs that happen through Sentry or other bug tracking software, and have that be piped into what we call triage. Triage is sort of an inbox for all the inbound issues where somebody should have a look, figure out whether anything needs to be done about them, and then assign them to people. You can automate triage in a way where an agent will have a first look. They will first try to figure out who should be responsible for this thing. Has anybody been working on these kinds of features? Is it a bug? Is it a performance regression? What is it? And it will auto-label the issue and assign it to somebody else.
You can also add a coding agent to that triage. Every single issue that comes into your triage inbox can be looked at, and then you can have an agent trying to solve that problem. Currently, I think the success rate is maybe at 30%; it's not that easy to fix some of these larger problems, but at least you will have a PR waiting for you when you get that issue assigned. Somebody has looked at it and tried to figure out what needs to be done here, pointing to the right files, giving a detailed description of where the problem might be. So even if it's not fully successful, it will still help you figure out the problem. And I do think that success rate will just increase as agents get better. I'm sure with Opus 4.5 or Codegen 5.3, it will be in the realm of 50%, 60% maybe.
Where is Linear in 3 years?
Linear in three years—it's hard to say where we will be. I think we will be in a world where—again, this would be my guess because I don't know where the AI industry is heading—it might be that all of coding happens with agents, or it might be that we're in a world similar to ours today where you just can't make much more progress on the quality of coding agents, or it might be somewhere in between.
But what I think will happen with Linear is that the focus will go more from the actual issue tracking that we started with to the project management aspect of things. If you have agents capable of doing large swaths of coding work and even creating or building out features—long-running features, having sessions of a few days of working out and shipping an actual feature—then I think the project management system goes more in the direction of helping you figure out what needs to be built instead of focusing on the actual building of it.
Today we have this duality: if you're a PM, you really don't care about issues anymore; you work on the project level and the initiative level in Linear, and you look at inbound customer requests trying to get a sense of what the product you're building should be. And if you're an IC, you work on the downstream of this: you look at your issues, look at your projects that you're assigned to, and try to figure those out. That definitely will change; you will be using more agents and you'll do more delegation.
Linear will probably help you in some way manage or orchestrate your agent layer and your coding agents and then review their work. That is something that we're building out today, hopefully shipping that soon and then improving on that. So for ICs, we should make your life easier by orchestrating agents, and for PMs, we hopefully will make your life easier by getting all that inbound stream from all your peers and your customers and providing context for you to work on, and obviously provide agents as well to go through that context and help you make good decisions.
So bullish or bearish on software as a career?
I'm bullish. I think I'm both. I think we need to redefine what a software engineering career is. If you're a product engineer, I'm super bullish. I think you now have the capability of doing much more and trying out things with the help of AI and agents in a way that was unimaginable back in the day. You can try out the things that you've imagined much more rapidly. Therefore, if you have good taste in what you want to build, you probably will have a good time from here on out. Even if AI stays at the level that we're currently at, it'll be so much better than what we used to have. If you're an engineer that just moves data from one pipe to another or creates pipes here and there and doesn't know about products, it might be more rough. I think AI becomes over time so good at doing these things that you might have to find a niche elsewhere.
There's this thought right now which is: if you're a software developer, why do I need a product person and a designer? I can just pull some of that stuff in. Same thing with product, right? Product can just be like, "Well, do I really need a whole bunch of engineers if I know a little bit about the technology and engineering?" So maybe you're bullish on these hybrid roles.
I think both are still needed. To give you an example: if you're an engineer and you don't know how to design, there's no AI that can do that for you. There literally isn't. You can do okay-ish designs with AI, but I think it's a long run before AI becomes capable of creating something that humans will feel is new or beautiful. It can copy things that exist already out there—you see that with all the templated designs and the AI tools that you have—you can spot a design from miles away that has been created by AI.
Is that a temporary or a fundamental limitation? We have token space and that maps really well to software engineering; is design space not? Is there anything specifically different about it?
I think it's different, but I don't know if it can be achieved by AI. There might be a place where it becomes sufficiently advanced, but we definitely need to come up with new... a simple LLM probably won't do it because I don't think you can become a great artist by just copying others and not having some human aspects to it. But it's definitely possible that over the years it will become possible.
Relating to the other thing about product managers: if you're a product manager, you have the idea of what you want to build, so AI might help you build it. But I still think that you need designers and engineers in there because AI might be able to implement what you ask of it, but you also need to ask it to implement the right things in the right kind of fashion. It goes off the rails very quickly if you don't know how you want it to be implemented. It won't be suggesting a synchronization engine to you; it will build a simple HTML application that has a REST backend and that's what you're stuck with. So if you don't know that you can do things in a different way, it won't do it for you. You have to ask it, "Let's explore WebSockets and synchronization."
The same aspect goes for performance and UX. There's no machine that is capable of telling you how a user feels when they interact with your application. A fade-out animation of your hover state needs to be 150 milliseconds or 200 milliseconds—it can read through everything that people have written about the subject and maybe come up with an average of 175, but it cannot test the application and get an emotion out of it as humans do. If that's solvable, then I think the design aspect is solvable as well. If we can instill some sort of emotion into AI, then I guess everything's over.
I think about temporary versus fundamental limitations. Code I think is a temporary limitation; I think everybody came to that realization recently. Fundamental limitations like accountability—you can't punish an AI. You can't have an AI vouch for another; there's no consequences. That's a fundamental limitation. I think the jury is still out on whether it can write a joke that makes you laugh, or make a really nice well-designed product that just sort of feels right.
Have you seen a joke by AI that you've really laughed at? Maybe there's a few. It's getting there. It might be that it is capable of surprising you, which turns into laughter.
Three years ago there were those videos of Will Smith eating spaghetti and it was just like, "Haha, look at this limitation of AI, it's always going to look like that." And now we can make a very nice Will Smith eating spaghetti video. I don't know why you would create one, but what if Anthropic decided they were going to focus on joke writing in the same way that they focused on code?
I don't think there's an inherent limitation. Human minds are incapable of understanding exponential growth. You only have to go three years back and look at the AI space as it was then—it was literally nothing. ChatGPT had just come out, I think. Was there any agent that could write even one line of code? Probably not. And now we're in a place three years later where they implement features and see compilers and all that. So, go forward 3 years—if it scales exponentially, it'll be crazy. We can't comprehend what they can do now.
I realized 6 or 8 weeks ago that I was just moving the goalpost. It's like, "Oh, it could never do a LeetCode question, haha." Then it did and I'm like, "Well, I don't even do that at work so that's not even important." And, "It could never take an issue from Linear and do the code." Then it did. I just kept on moving the goalposts and then I realized these are all temporary limitations that I've been bringing up.
But I still think that bringing in human emotion is the hard part. I don't know how you would do that even if you grow it exponentially. Just the simple fact of using an application and feeling that it's slow—you click this button and it should pop up a bit faster. There was a sort of lag in there. It's super hard to instill that feeling of frustration that you have as a user into AI when they use the application. I don't know how you would do that today. Let's see. Bullish or bearish on Claude Bot?
Oh, bullish for sure. But you have to always be bearish too; at some point things will go horribly wrong. The first time somebody gives access to their bank accounts, people will lose all their life savings. That will happen. But as a whole, I'm super bullish.
I've installed mine. I've been Telegramming with it trying to prepare for this interview. It did a pretty decent job, I think. Do you think that the cost of AI will eclipse that of a software engineer when you start thinking about the cost of labor and all the electricity involved—the economics of this?
Yes, I think you will have agents that will cost more than a software engineer, and then those costs will come down. You will still have the incremental benefit of things just getting more performant and using less energy and becoming better over time. But I think once you crack the notion of "a 100 agents is not good enough, let's go to a thousand or 10,000 agents working on the same problem," you don't have a limit. If you can solve how these interact together to become smarter, you can throw a million agents at a problem and that will cost you immensely at first, and then 10 years later it probably won't.
I just don't know if costs are going to increase substantially or decrease substantially. I hear about these chip shortages, power shortages, data center shortages—is the price going to infinity or is it going to zero? I don't know what's going on.
I think it's going to zero over the long term. We might have shortages in the meantime and it might become super expensive to run any of this—there might be competition for GPUs and electricity and all of that. So in the next 10 years, I don't know what the answer would be, but over the course of time it's bound to go to zero or near zero.
But you have these companies, like Amazon's $180 billion investments into a resource that you think is going to go to zero over time. Seems like—why would you invest?
Well, if they can recoup the money before it goes to zero. And that is literally the way to get it to zero. You currently have a cost of running agent compute, and it's currently very beneficial to run it—you can make money with it. I think the big question is—and I'm totally the wrong person to answer—is whether all these investments will be able to recoup their money and make much more before the technology goes by. I would be scared if I had to buy the latest GPUs at $20,000 knowing that the moment I purchased them, a year later the price will have gone down by 25-30% and what I just bought is literally melting and depreciating in my hands. It would be a crazy feeling.
Well, Tuomas, thanks so much for spending the time to have the conversation today. Really appreciate it.
Thank you so much.