BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations A Few Predicted Talks From QConAI 2030

A Few Predicted Talks From QConAI 2030

35:17

Summary

Meryem Arik discusses her predictions for software engineering in 2030. She explains how token spend management, parallel agent infrastructure, and non-technical builders will reshape IT. She shares insights on agent-driven vendor decisions, upcoming regulatory hurdles, and why software engineers must pivot from pure coding skills toward product leadership and multi-agent coordination.

Bio

Meryem Arik is the Co-founder and CEO of Doubleword, a self-hosted AI inference platform empowering enterprise teams to deploy domain-specific or custom models in their private environment. She frequently speaks at leading conferences, including TEDx and QCon, sharing insights on inference technology and enterprise AI.

About the conference

QCon AI is a practitioner-led event focused entirely on the engineering discipline required to scale these workloads safely. It provides direct access to the architectural playbooks and failure metrics that peer organizations use in production.

Transcript

Meryem Arik: I'm going to be doing something very risky today, and I'm going to be predicting the future. You should famously never, ever make predictions, especially about the future, because it always goes wrong. A very wise man said this. He actually was a baseball player in Boston. Luckily, I'm not a wise man. I'm Meryem. I'm the cofounder of Doubleword. I work on high throughput inference. The reason why I felt somewhat confident to make vague predictions is I actually have a fairly good track record of it. A couple months after ChatGPT came out, I did a TEDx talk called, AI's Looming Hardware Crisis, where I argued that inference would be very important and that we would not have enough GPUs to be able to serve all the inference that we needed. This was three years ago, and in that time, NVIDIA's stock price has gone up 10x. It turns out I was right. I was right once, I might not be right again.

I'm going to give you a brief overview of the structure of this talk. I'm going to present my worldview, which I think is a fairly coherent worldview. I'm going to make a bunch of predictions, and they hopefully shouldn't contradict each other too drastically. You can think of the sections of my talk as standalone mini-talks. The reason I structured it like this is so I can clip it up in five years' time if one of them is right and none of the others are right, and I can claim that I predicted the future really well. It's aimed at you, so specifically, I'm going to be talking about the types of things that I think enterprise early adopters and early majority will be caring about in 2030. Finally, you might not agree with all of my predictions, and that's totally fine. I tend to think of myself as a semi-logical person, and so hopefully the reasoning should follow.

If you disagree with my conclusions, I'd recommend that you think about what assumptions that I've made that you disagree with, and then you can follow the logic of where you go from there. As I mentioned, this is aimed at the InfoQ audience. I'm only going to be talking about things that I think are going to matter to the early adopters and early majority. For the laggards, the stuff that we talked about at this conference probably still won't be relevant even then. Also, I'll make a note on the likely direction of error. I'm self-aware enough of myself to know where I tend to overestimate and underestimate things. I tend to overestimate how quickly enterprises will change, which I think a lot of people do. I tend to underestimate how quickly the frontier has improved. This didn't used to be a problem, but actually the frontier has been improving so quickly that it's possible that we're actually way further than I'm predicting. I'm pretty good at spotting bottlenecks. We decided that inference would be a bottleneck in 2021, and that turned out to be pretty good. I would also caveat that if we achieve AGI, all of the bets are off, and then I'll be doing my power washing business or something like that.

Prediction Framework

What am I going to be making predictions about? I've tried to pick a range of topics. I'm going to talk about money and how much money we are spending on AI. I'm going to be talking about what happens when we have more code and more builders within our organizations. I'm going to be talking about infrastructure, what's the kind of infrastructure we're going to be building on top of. I'm going to be talking about agents, obviously. I'll talk also about regulation and how, if at all, it's going to impact people here. Then, finally, I'm going to talk a bit about what I think careers look like for AI engineers and software engineers.

How We Manage and Attribute Token Spend

Let's start with money. How much do I think we're going to be spending in 2030? Do I think it's going to be a topic of conversation? I've been in the inference space since 2022, so a relatively long time. I've always thought that inference cost was going to become a problem. We would talk about it with customers, that inference cost is a really big issue. Actually, it wasn't really a big issue until about three months ago, when it seems to be a huge issue. I'll talk about why it's become an issue in that very short period of time. It was released via Twitter that some unnamed company blew through half a billion dollars' worth of Claude credits in one month. Uber has burned through their entire token budget by the end of April. J.P. Morgan is spending $2 billion more on IT this year than it did last year.

Token spending is becoming a very big issue now. We've seen talks in the conference about this particular issue. It's an issue, and we are still so early. This is a source from Deloitte, 23% of companies say they use agentic AI at least moderately. When we think about what moderately means, it typically means that some of the organizations are using it on some of their use cases. We are still so early, and token spend is already an issue. There's a myth that I want to dispel. Actually, we heard this as well in Jordan's talk. There's this myth that I've actually heard from a lot of the lunchtime conversations that AI labs are subsidizing tokens. That they're eventually going to jack up the price of these tokens, because they're subsidizing it. That's not true. Their inference part of their businesses are highly profitable. Yes, these organizations do lose money, although I think actually Anthropic now makes money.

The reason they are not as highly profitable on their bottom line is because they are spending so much money on infrastructure and so much money on training. I'm going to firstly dispel this myth that I don't think we're going to see AI labs jacking up token prices for their existing models because they're subsidizing it. In fact, I think tokens are getting cheaper. Empirically, we've seen that tokens have gotten much cheaper. They are going to continue to. If you take a fixed intelligence point, so let's say a fixed IQ point, that fixed IQ point over the last three years has gone down and cost roughly 10x every single year. If you were using GPT-4 in 2023, that price has gone down 10x year over year in that time. That is largely driven thanks to open-source model pressures. The open-source model providers have gotten very good at taking an intelligence level provided by the frontier labs and distilling them and building more efficient architectures to deliver them.

Tokens for a fixed intelligence level are going to continue to get cheaper. We'll also see a rise of open-source models. This is taken from OpenRouter, which is a place where you can get access to a lot of different models. The share of people using open models versus closed is growing significantly, in part because of cost pressures. Despite that, spend is still skyrocketing, even with cheaper tokens. This is the very classic Jevons paradox. I think we've had a couple talks mention this exactly. Token prices are plummeting, but we're finding more and more use cases to apply them to. Spend is continuing to rise. This is taken from Goldman Sachs. I actually think it's a fairly conservative estimate, but they expect that token usage by agents will multiply 24 times by 2030. I actually think it'll be much more than this. The percentage of headcount budget, which I think is like a way to think about it, that is spent on tokens will go up significantly and will be a very big pain point in 2030.

We're going to have more use cases that are unlocked. As tokens get cheaper, we find more things to apply them to. We also are seeing more and more token-hungry use cases. Unfortunately, or fortunately, every single generation of AI use cases that have come out, so starting with simple chatbots, then moving to RAG, then moving to reasoning models, then moving to agents, and then increasingly complex agents, every single generation is getting more and more token-hungry, and we should expect that to continue. The use cases we develop will be more token-hungry. Then, thirdly, even though I said that AI labs are not going to jack up the prices of their existing models, the frontier models that they release tend to be more expensive. They tend to be bigger models, and also these labs are pretty compute-constrained. The prediction, this is my imaginary person giving a talk at QCon in 2030, that we're going to be seeing a lot of talks like how to manage and attribute token spend to make sure that we are not spending more than we need to and that we're attributing it in the right way.

How Do We Deal with Abundant Code?

The second prediction that I want to make is about what we do with abundant code, with more code in our organizations. The current state of play is that we have a very small number or a small amount of code that services a huge number of use cases. Every organization has a couple pieces of software that they either build internally or that they buy externally and they deliver that to maybe thousands of users within their organization. I've got screenshots here of, for example, Salesforce. It's a piece of software that is used by many people in the organization who might have very different use cases. This makes sense if you take the limitations that we have had on software. On my left, I have hundreds of thousands of different users all with very different use cases. I, as IT, because code is not free, code is actually very expensive, it's expensive to both develop software and kill software, and it's expensive to manage that as well.

I'm going to funnel all of these different people into as few apps at the end of the process. What we end up is we have a couple apps servicing a huge number of users. That's the current state of play. There's no reason why the assumptions that made this happen should continue to hold. The first claim that I want to make is that the cost of software is going to trend towards zero. I know this is true because I've seen it in my own world. Right here, we made a complete frontend rewrite of our application, of our product. I think it cost us $20 to do it, and otherwise it would have cost us two weeks of engineering time. Another example is because the cost of software is essentially free, I'm building custom software to plan my wedding, in a way that I otherwise would have used an Excel sheet.

The cost of software is basically free and is going to trend towards zero. The other thing that we're going to see is that anyone in the business is going to be able to build software. It's not just trending towards zero for developers, but it's trending towards zero for everyone, and it's going to get very easy to build. Companies like Lovable, but now also Claude do this, and Codex do this. They're making it exceptionally easy for non-technical people to build. When you have code that is free, essentially, and the skill barrier is removed, then what are you going to see? What we've seen within our organization is that we have seen non-technical people feel empowered to build software in a way that otherwise they would have not used software and would maybe have just used a Google sheet. This is an example of something that a BDR in my organization built.

He's fresh out of college. This is all dummy data because I asked him to remove real people. We were at a conference and he built in about 25 minutes a lead tracking app that connected to the lead device that we were using and connected to our HubSpot and connected to our email systems as well, and this is a completely non-technical guy who did this in about 25 minutes. We're going to see way more of that. If we have thousands of people in our organization with hundreds of different use cases, and code is no longer expensive to build and it's also the case that anyone can build, then the natural conclusion is that we're going to see a Cambrian explosion in the different applications that exist within our business. We're going to see hundreds of incredibly bespoke applications. This problem already exists. I used to be a quant working in an investment bank, and we had this exact same problem but this was just different versions of Excel spreadsheets.

Everyone had their own Excel spreadsheet with their own different way of building their financial models. This problem has already existed but now it's going to be even more complex because it's going to be custom code. It's really obvious why this is so appealing. All of these people get their problem directly solved exactly in the way they want it to be solved. It's also obvious that it's going to raise a huge number of challenges for IT that we're going to have to deal with. This can very easily turn into a bit of a mess where we have various forms of cyber risk, maybe people are using non-consistent data. Maybe we have various data silos or whatever it is, it can turn into a mess really quickly if we're not going to be careful.

I think we're going to see a number of challenges when everyone is a builder, because it is a when and not an if, I believe. Who is accountable for this software? Who is accountable that it actually works? If I build an application and it's connected to a data source, if that breaks, whose problem is that? How do we as IT enable these builders to actually be able to build? Ben did a great session on this on talking about how his organization is enabling builders, non-technical users, to build these applications. How do we think about cyber, which is going to become an increasing problem in the world of malicious AI attacks? How do we have single data standards? What happens if the person who built the tool leaves? There's a huge number of challenges that we're going to have. I think we see the role of IT changing.

Until now, IT has often just been a home of the people that have technical skills that other people don't have. For example, you can largely predict whether someone is in the tech org or not by whether or not they know how to code. That's no longer going to be the distinction I don't think. I actually think the role of IT goes from being the people that write code to the people that are enabling the rest of the organization to solve their problems. I think IT actually turns into way more of a platform team than it does anything else. The kinds of things that we'll be thinking about is, how do we as IT give people the building blocks they need such that they can build their completely custom bespoke app but in a way that doesn't turn into a big headache? My prediction is that by 2030 we're going to have organizations where IT teams are managing thousands and thousands of internal apps, and we're defining the standards of what it means to build accountability frameworks for this and build enablement frameworks to make this happen.

What Infrastructure Are We Using?

What infrastructure are we going to be using? Humans have very strong preferences for things that we're familiar with. It's actually really quite funny to see. You'll see someone who's been brought up in the AWS ecosystem and the only jobs they'll apply to are AWS jobs because they've got those certifications and that's what they're familiar with, and they like being in their own little bubble. It's actually very interesting how we've started to create that. Humans really have very strong preferences for things that we're very familiar with. What's fun is that agents also have really strong preferences on the infrastructure they like to use too. There's a bit of a recipe of like what agents like to use. They like to use Supabase and Vercel and Stripe and Resend. If you ever really try to build an app with any of the major coding tools like Cursor, Claude, Codex, whatever it is, it'll almost always use a combination of these tools.

They've got strong preferences from whatever it is. There are a couple things, of what that means. The reason I included our logo in this is because this is something we're observing as a vendor. As a vendor, we are noticing that the majority of our clients are not engineers. The majority of our clients are agents who find us and agents who use us for the first time as well. Almost every single dev tool is having to build agent first because agents are our customers now. This is causing exponential growth if you are one of the lucky ones that the agents prefer. This is the user count growth for Supabase. It's been around since about 2020, and it's got 7 million users now. You can see pretty much all of those users came in the last year. Basically, all of those users are users that have come thanks to AI.

The next prediction, I want to give a shout out here to Erik Peterson who made this prediction as well independently earlier on, that agents are now making our buying decisions for us. They're deciding which infrastructure we're using. That's fine given they're picking open-source tools, but it never really stops there. Agents are building implicit buying preferences for us that the business actually has no control over. I think this is going to lead to really interesting conversations about, how do we avoid vendor lock-in? How do we think about migrating from one tool to the other when we're not actually making conscious vendor decisions anymore? It's not like you have an engineer evaluating the different frameworks and picking the framework they're going to use. AI is coming with preferences, and it's like you've hired a whole bunch of engineers that are super opinionated that Vercel is the best. This is something that we're going to have to deal with and I think we're going to be thinking about.

What Pattern of Applications Are We Building?

Application patterns. What kinds of AI applications are we going to be building? I've been to QCon for the last couple years, and I've seen the journey of us talking a bunch about RAG and then about simple agents and now we're talking a lot about longer running agents. What kind of applications are we going to talk about building in 2030? I'm going to introduce the concept of test time scaling. Essentially the idea around test time scaling is that the more inference you do, the more tokens you throw at a problem, the more intelligent that the model gets. Here are some examples. On the x-axis you can see the amount of compute that is given to solve a problem. On the y-axis you can see the results of that model on a particular benchmark. You can see the more compute you give a model, the better it performs on benchmarks.

There's two ways that you can implement test time scaling. We know we want models to be smarter. We can either have deep or we can have wide scaling, or we can have a combination of both. Deep might be, I have a singular agent which maybe has access to a bunch of different tools and it acts in a fairly linear way. This is a way that you could build a deep agent. Actually, the majority of agents that are being built in enterprise right now take this paradigm of being fairly linear. Or you could use your compute resource and you could use your inference resource instead to build wide agents. I send a request to a singular agent, but then I have a bunch of different sub-agents maybe doing different tasks, maybe all doing the same tasks and seeing where they differ. I'm essentially doing a lot of things in parallel.

Most enterprises right now are building linear agents. This is not something that has hit enterprise mainstream yet. I think there's a pretty good prediction to be made that parallel agents are going to be the winning paradigm. I think this for a lot of reasons, but to boil it down, the first one is latency. One of the nice things about running parallel inference is my end-to-end latency for a user ends up being much lower because I just need to care about throughput as opposed to caring about a bunch of sequential calls. The second thing is you can actually construct these parallel agents to be much cheaper by doing smart context management and also by doing smart use case specialization as well. Then also, finally, it really improves accuracy. You can do genuine trial and error. You can also do genuine, I want to try 10 different agents to do the same thing, and if I get 10 out of 10 with the same answer, I'm really confident in that.

You can do things like that that really improve accuracy. I think parallel agents are going to be the winning paradigm. I'm also more confident by this because pretty much all the frontier agents, so like your Claude, Perplexity, they all use this paradigm of parallel agents. I think these parallel agents come with a lot of infrastructure challenges that I think we're going to be talking about at QCon in a couple years. For example, one problem is aggregation. If I have all of these parallel agents going off, how do I actually aggregate what the end result is? That's I think going to be an interesting problem as these things get bigger and bigger. How do I do capacity planning if I end up having these very bursty workloads where I can go from a single LLM call to immediately then going to a hundred? How do I observe this?

How do I deal with the memory bottlenecks if I'm actually hosting these things myself? How do I schedule these different workloads as well? All of this will end up making the infrastructure challenges much more complicated. Unfortunately, AI applications seem to have the habit of going from more infrastructurally simple, like a simple chatbot, to more and more chaotic and difficult to manage. I think parallel agents are incredibly complex, chaotic systems. I think we're going to be talking about parallel agents and architecting for these paradigms where you can imagine a world in which I have a single prompt and that's spawning potentially 10,000 sub-agents all doing their own thing, all calling tools and all calling services.

What Kind of Regulation Are We Dealing With?

Regulation. I'm not sure if I'm talking about this just because I'm European and Europeans love talking about regulation, but I do actually think it's going to be a very real problem that we'll be thinking about. We've been in this very weird place where there's been very little regulation given how consequential the technology is. There was the EU AI Act that was mainly drafted before GenAI. Then when GenAI hit, they were like, we don't want to stifle innovation too much, and so there's not really enforcement yet. They don't really know if they can enforce it. That's not pretty toothless for now. The U.S. had guidance that would have regulated or provided guidance on how to use GenAI, but then Trump explicitly excluded GenAI last year. The current regulation is pretty weak, and on the whole it's up to businesses and enterprises and people building use cases to figure out how to be responsible.

This is actually changing. I took this screenshot. I don't actually think this is any meaningful regulation, but it does seem like people are starting to not take this complete free-jump approach. As countries, and I would actually say the U.S. probably has more resistance than most countries or at least in Europe, we're already seeing very big resistance from the general population to AI. I found this very cute little girl who apparently really doesn't like data centers, and we're seeing this more and more. The average person is really not excited by AI. I'm sure a lot of people here are, because we're practitioners and we're very close to it, but the average person is not and they're getting less and less excited as time goes on. This is a Pew Research study. Currently 50% of Americans are more worried about AI than they are excited. Actually only 10% of Americans are more excited than they're worried.

The vast majority of Americans do not really want this thing or do not necessarily understand why it's a good idea. It makes sense why. It is really scary, and as an industry we don't help ourselves. We talk a lot about the end of times. I do really understand why it's very scary. I'm going to make a prediction. My prediction is that the 2028 U.S. election campaign is going to be largely dominated by anti-AI and anti-billionaire sentiment. I do think that the anti-AI sentiment is going to be very real. We've seen this already. Elizabeth Warren is talking about taxes on AI. Bernie Sanders announced that he wants to seize 50% of all of the major AI labs. This is not just a democratic issue as well. Orly, a Republican, and Ron DeSantis have both been very anti-AI as well. It seems to be one of the things that there's cross-all agreement on.

I think as we start seeing the impact of AI in our economy, and I don't think we've actually really seen any impact yet, this is going to get more and more intense. The timeline I'm predicting is that over the next couple years we're going to see more and more intense anti-AI, anti-data center campaigning. 2028 I think we can get an anti-AI candidate that wins. That means 2029 we'll be seeing new AI regulation. By the time we get here in 2030 we'll be talking about implementing that regulation as well. I think it will probably be regulation that is probably quite toothy and will impact the way that we're actually building. That's my prediction that I think we will increasingly be entering into a more AI hostile political environment. We've been pretty lucky with how un-hostile it's been over the last couple years.

What is a 'Good Software Engineer' in 2030?

The final thing I'm going to talk about is, what makes a good software engineer in 2030? How do the skill sets that we need change over the next couple years, and how we implement AI? I took this from I think it's softwareengineerscareerleveling.com or something like that. It talks about the different axes of what makes a good software engineer. There's a bunch of different axes. You can have technology. This is probably the main one that people think about before they get to management level. How good is your knowledge of the tech stack and tools. Like how talented a technologist are you? We talk about relationship with the team. Are you easy to work with? Are you not easy to work with? People like you. Talk about process. What is your engagement with the development process? How good are you at that? We talk about system. This one I think is particularly interesting.

What is your level of ownership over the system? The reason I think this one is particularly interesting is because software career leveling frameworks exist mainly as a retention tool. They exist mainly so that you're not going to go and leave. We really reward people who understand the system. Because it's very difficult to get new people to come in and understand the entire tech stack and build from there. We talk about how good your understanding is of overall systems. Then we talk about influence. This is when we talk about management as well. These are axes that we currently care about in software engineering. With different leveling and different skill sets, you'll be at different levels in this Pentagon. For example, if you are an engineering manager 6, you probably won't be that high in technology anymore, but you'll be pretty high in people and process. If you were a developer before, you might be a generalist everywhere.

Everyone has their own Pentagon. That largely decides where they are in the career leveling framework. I think that's really a good reason to say that most of these really change in importance in the AI era in pretty radical ways. I don't think knowledge of technology stacks really matter that much anymore or will continue to matter that much anymore for the majority of software engineers. I think there's some exceptions of when people are working in particular types of technology where that will change. I think on the whole, technology will be less important in 2030 than it is now. I think there's also a good reason to think that your relationship with your team might be less important as well or at least will change. What we've been seeing more and more is that people aren't necessarily working in a large team anymore to deliver complex software.

They're actually working with a lot of agents to deliver complex software. That we're seeing more and more people able to own entire projects by themselves. I think that relationship changes. The way we measure that changes. The process also changes somewhat as well. There's an argument to which you say that like the software development cycle exists largely because you have a lot of people going on. If you have AIs in that system, it's not clear how that changes as well. Level of ownership of the system I think is a really interesting one. I think that will become way less important in the new career leveling frameworks of the future. I think actually the difficulty of onboarding a new person onto a complex tech stack given they have AI tools becomes much easier. It's not as important to reward people for deep level of knowledge of your system.

I think influence could also change. Importantly, I think we're missing a very big thing here which is product. For a lot of organizations, you see product and engineering having slightly separate roles. I think product thinking, requirements gathering and understanding will become an increasingly large proportion of the software engineer role. Evidence to support that is the number of companies looking for product engineers has skyrocketed over the last year. I think we're going to see more and more expectation that everyone will be a product engineer. How we use AI I think also becomes a key part of leveling. I know that in a number of talks we've talked about tokenmaxxing, and should you tokenmax and what does that mean? I tend to agree with Erik the founder of Modal here when he talks about actually the thing that we want to max is this ratio of whatever the output you deliver is divided by the salary plus your token usage.

If you are able to maximize that ratio by using $20,000 worth of tokens a month, great. If you're able to max that by using $500, that's also great. I think we're going to be measured by this metric going forward as opposed to anything else. I think the things that will change when we think about what a good software engineer looks like going forward is I think deep technical skills matter less and less, and actually product, project management because your engineers will be required to deliver more and more complex projects, and requirement settings will become increasingly important skills. Kind of like being a conductor. We have engineers within our organization who simultaneously manage between 5 and 10 separate agents, and they're basically becoming team leads as individuals and they're becoming conductors. I think we'll see a lot more of this becoming the thing that we're measuring against. I predict that we'll have a talk titled something like, building software engineering career leveling frameworks when technical skills don't matter. It's a bit controversial as a title but gets people attending.

Recap

My predictions. Token spend will go up. It'll become a very big issue of how we manage it. We will have a lot more code and a lot more builders, and it's the job of IT to figure out how to provide them the framework so that doesn't turn into chaos. We're going to have agents making buying decisions with infrastructure, and I think that'll be an interesting question of how we manage that. We're going to be having very parallel agents and I think that will lead to a lot of infrastructure challenges that we will need to deal with. I think we will have a bunch new AI regulation and AI skeptic administrations. Finally, I think the definition of what a good software engineer looks like will change. I'll make one final prediction. The talk title was what we'll be talking about at QCon AI in 2030. Maybe I disagree with this talk title on the whole. I don't think there will be a QCon AI in 2030. I think we will just be at QCon, and I think this will just be part of all software engineering that we do.

 

See more presentations with transcripts

 

Recorded at:

QCon AI is a practitioner-led event focused entirely on the engineering discipline required to scale these workloads safely. It provides direct
access to the architectural playbooks and failure metrics that peer organizations use in production.

Sep 05, 2026

BT