Coding Agents in 2026: You’re Not Faster. You’re Just Expected To Do More

Summary

Coding agent adoption has shifted from a question of whether to use AI to one of operational maturity, with developers now acting as managers supervising agent-submitted PRs and being expected to produce dramatically more output without commensurate increases in compensation.
Key operational recommendations include capping active coding environments at three or four tools to avoid decision fatigue, building internal skills for consistent agent behavior, and running organization-wide agent boot camps to accelerate team-wide maturity.
Supply chain risk is a critical and often overlooked concern—agents can accidentally leak API keys and credentials in submitted code—making human review of all agent-submitted PRs a non-negotiable governance requirement.

Coding Agents in 2026: You’re Not Faster. You’re Just Expected To Do More

As AI tools and coding agents rapidly scale across enterprise environments, organizations face a critical transition from initial tool adoption to long-term operational maturity. Managing multiple autonomous agents simultaneously introduces a unique layer of friction, often causing user decision fatigue and operational complexity as developers are forced to act more like managers overseeing junior contributors. To address this friction without stifling velocity, teams must establish a structured approach to agent orchestration, utilizing centralization and deliberate caching strategies to prevent burnout, secure the software supply chain, and manage token consumption costs effectively.
𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• 𝗙𝗼𝗰𝘂𝘀 𝗼𝗻 𝗺𝗮𝘁𝘂𝗿𝗶𝘁𝘆 𝗼𝘃𝗲𝗿 𝗮𝗱𝗼𝗽𝘁𝗶𝗼𝗻: Enterprise challenges have shifted from adopting AI tools to executing and scaling their usage effectively.
• 𝗟𝗶𝗺𝗶𝘁 𝗮𝗰𝘁𝗶𝘃𝗲 𝘁𝗼𝗼𝗹𝘀: Cognitive overload and productivity drops occur when using too many tools; teams should cap active environments to three or four.
• 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲 𝘁𝗵𝗲 𝗲𝗻𝘁𝗶𝗿𝗲 𝗹𝗶𝗳𝗲𝗰𝘆𝗰𝗹𝗲: AI compresses only a small fraction of software engineering, making optimization of research, planning, and debugging crucial for ROI.
• 𝗘𝗻𝗳𝗼𝗿𝗰𝗲 𝗵𝘂𝗺𝗮𝗻 𝗿𝗲𝘃𝗶𝗲𝘄: Automated code presents severe security and supply chain risks, requiring human developers to review and sign off on all work.
00:00 — Developer Freedom vs. Administrative Governance
01:28 — Product-Market Fit of Coding Agents
02:19 — Shift to the IT Admin Perspective
03:28 — The Pitfalls of Tool Standardization
04:46 — The Reality of Vendor Sprawl and Cost Management
06:40 — Introducing the AI Gateway Solution
07:20 — Observability, Cost Control, and Data Privacy
10:12 — Developer Workflow and Open UI/Isaac Multi-AI Harness Integration
11:42 — Advanced Features (Computer Use and Model Context Protocol)
12:37 — Case Study: Implementing Governance and Scaling at Databricks
Check out future Agentic + AI Observability events: https://luma.com/AgenticAIObservability

Chapters

FAQs

How has the role of software engineers changed with coding agents in 2026?

Engineers have shifted from individual contributors writing code to managers supervising and reviewing agent-submitted pull requests. Every developer now owns the code their agents produce, but the organizational expectation is to deliver far more output than before—at the same or similar compensation—which is the core tension this video addresses.

Why should teams limit the number of active coding tools to three or four?

Using too many coding agent environments simultaneously creates cognitive overload and productivity drops because context switching between tools with different capabilities and behaviors becomes a significant friction point. This video recommends capping active environments at three or four to maintain developer focus and reduce decision fatigue.

What is the supply chain risk of coding agents and how should teams manage it?

Coding agents can accidentally expose secrets, API keys, and credentials in submitted code because they have broad file system access and may incorporate context from configuration files. This video emphasizes that human developers must review and sign off on all agent-submitted work, and that organizations need governance processes specifically designed for agent-generated code.

What does optimizing the full software engineering lifecycle mean in the agent era?

AI tools compress only a fraction of the software engineering workflow—primarily the code generation step—while research, planning, debugging, and review remain largely human activities. This video argues that teams must optimize the entire lifecycle, not just the code generation portion, to realize the full ROI of coding agent investments.

Full transcript

[00:02] So if you build these things properly, you can actually lower your burnout. The problem is not going ahead and building those skills or running the agents, but actually supervising them because guess what? All developers now are turning into managers. Whenever you go ahead and
[00:14] submit a PR, you may have be helped by an agent or by an LM, but you, the human, are the ones that actually own that code.
[00:28] So I called the session, you're not faster. you just expect to do more because that's probably how all of you feel with in the age of AI. Is that correct? Raise your hands if you agree with that statement. No, all of you need to raise your hands because that's actually what's really going on. Okay.
[00:40] Are you paid more to do all this? >> The answer is no. Right. So that's the state of coding agents. Now we're going to breeze through some real kick concepts uh just so that we you have a
[00:53] feel of the uh how fast we had to adapt everything. Basically the context here, a year ago, AI coding agents were a demo. It's obviously the default follows now, right? In other words, you're all using it whether you meant to or like to
[01:05] or not. It's embedded inside our slides. It's embedded in everything. And so there's intense competition. Uh some of them are here today, which is great. But the whole point is that you got to ship ship ship just exactly what Maria called out, right? And sometimes you get to fix
[01:18] it, too. All right. Now, there's a little cool little call out here. uh inside a particular database or we went from basically 20% to about 100%
[01:31] uh to all using coding agents. Pretty cool, right? So again, engineers writing PRs. Is that great? Yes. >> No, it was actually the PMs. Okay. Now, you can all you can all debate with me
[01:44] whether PMs should be writing PRs or not. Okay. That's a whole other discussion and outside the scope of the keynote here. Okay. But the context I'm trying to get is that we actually got all the PMs within the uh within data bricks to go from 20% like 100%. In a
[01:59] matter of months, okay, why? Because for them to create demos, for them to make sure they had proper communication to their customers and to the engineers, we had to make sure that they actually could go ahead and write PRs, they could
[02:12] go ahead and write code, they could vibe code their way out of stuff. So that way they weren't because does everybody like reading a 100page uh PRD? Good. I'm glad nobody raised their hand. Okay. For that. All right. So this is cool.
[02:24] Adoption solved, right? Am I done? No. Maturity is not. Okay. So the call out actually is by Casey here. Uh she's the director of PM at data bricks is that
[02:36] the interesting question is no longer if we're going to go do this. The interesting question is how well are you doing this? Right? That's our problem. Now, okay, so if I was to look at the
[02:48] four stages of coding agents, this is basically the story arc that you want to think here. You're going to start with tire kicking in terms of tokens per month. I put the rough numbers because if I actually put the real numbers down,
[03:00] I'm pretty sure I'm going to get in trouble. So, I'm not going to do that, but we're talking hundreds of dollars a month in tokens. Okay. Then you do your daily drivers. Every day I'm running an agent to answer my emails, to clear out things, to fix PRs, to report things.
[03:14] Now we're talking hundreds to thousands of dollars a month. Okay. Then you realize, man, I can actually do this multimodel. I can go ahead and run this across multiple models, multiple agents at any one point in time. That's
[03:26] awesome. Now we're talking about thousands of dollars a month. Okay. And then I do fleet management. Does anybody know what fleet management is? Raise your hand. Yes. No. Okay. We're going to go through that concept in a second. But the point is the problem is that now
[03:39] you're all going to run multiple agents, right? It's not one agent you're running. You're going to multitask. You're going to have to manage all of these agents at the same time. Now you're talking thousands to tens of thousands a month.
[03:52] Okay? So you're able to do a lot more, but you're not paid more, are you? All right? So we'll remember that one. In order to be able to pull this off, 70% of devs are using around two to four
[04:04] coding tools simultaneously. That's the rough estimate, okay? Based on some of the stuff we've done at data bricks, but also talking to a lot of our customers. Okay. Um there's this concept of basically 15% use a single tool and 15%
[04:18] use five plus more tools. Okay. Uh there's different uh options. For example, if I was just to pick on uh uh anthrop and claude, right? For example, this is the common practice where you have haiku versus having sonnet and
[04:30] versus opus. Why? Because you're basically trying to go go with the super fast ones versus the think regular thinking versus deep thinking and analysis, right? So that way you have instant processing versus the one that actually takes uh perhaps will less
[04:44] hallucinate the answer for you. Okay. And there's a common approach where you're consolidating all these things into a single AI gateway. So that way you can manage all that stuff. That's great. But oh sorry before I go into now
[04:58] uh pron the concept I wanted to say you all should hopefully know this concepts right. Basically the agent primes are MCP like their uh uh the model context protocol. You got your skills, your sub agents, and the orchestrations that go
[05:10] above that. Okay, so everything we're doing is based off of that concept. Okay, so because we're a little running low on time, I'm going to hopefully you all know this, and I'm going to skip this part for now, but fleet management, when I put all this together, okay, is
[05:24] this idea that you have a cognitive ceiling, your productivity peaks at around three AI tools, possibly four, but you go above four tools at once, it starts dropping. Why? Because you're
[05:37] having a hard time managing that. Okay, so Real Fleet today, like, okay, I've got a morning briefing. Okay, so I'm going to have one agent go through my Slack through all my emails, summarize things so I can understand what's going
[05:49] on. Uh the Wednesday prep agent because I'm prepping information so that way my Friday uh QBRS or my Friday syncs are ready. Um like I'm running multiple monor repo dev pools because I'm pulling the entire repo down. I'm trying to run
[06:02] PRs, look at what's going on, right? So that's real fleets running actually today. Okay. But like I said before, oh and right for example, I want to call Casey again. 50page PRDS into one page
[06:14] apps, right? So a lot simpler. So this is great, but you suffer from this concept of AI brain fry. All right? In other words, the oversight of this is what breaks
[06:27] productivity. In other words, you start getting really fast, able to do lots of things, really cool, but then all a sudden trying to manage all of these things at once starts breaking your brain down. So, for example, when I created these slides alone, I had four
[06:40] agents running simultaneously looking at different parts of the slides. I I screwed up because I forgot what context me the human forgot what context I was on for each of the agents. Okay, so and
[06:53] that was one slide deck, right? What happens when you have completely different context running at the same time where I'm fixing a PR code in Rust. I'm fixing a Spark issue in Spark uh in Scola and I'm going ahead and also answering a bunch of Slacks, right?
[07:05] You're going to lose context fast. All right. And so 14% of AI users report basically brain fry. There's this idea of like basically decision fatigue, major errors, higher intent to quit.
[07:17] Okay? People are frying out, burning out because of this, right? The nuance is this though. You can use AI to replace repetitive tasks. And so for those repetitive tasks, that actually leads to
[07:31] lower burnout, right? The ones that you have to constantly do that are boring. So if you build these things properly, you can actually lower your burnout. But because you're asked to do more, that's what the fleet implication is. Then what ends up happening is that you have to go
[07:44] ahead and figure out how to build skills properly so that way you can actually manage them. The problem is not going ahead and building those skills or running the agents, but actually supervising them because guess what? All
[07:58] developers now are turning into managers. And so you are instead of a developer, you're managing four junior devs when you're running four agents. That's the best way of thinking that. Okay. All right.
[08:10] So if you're running a team, some my first bit of advice for y'all. Okay. So hopefully you're doing this, but if you're running a team, first run a hands-on boot camp. Get your team to
[08:22] actually be on the same page. The reason why you want to run a boot camp is not just because you're trying to get people up to speed on the skills, though that's important, too. The reason is because there's underlying native knowledge of
[08:34] your organization, of your team, of your group, of your company that isn't necessarily written down, but you apply together when you go ahead and build run these boot camps so that you all implicitly understand well how the team
[08:47] operates so you can actually pro properly scale. Right? The second thing is that track maturity not adoption. So, for example, if I'm just measuring how many tokens I use, cool. You spent a
[09:00] 100,000 tokens to clean up your email. Cool. If I did that the first day, that's okay. If I do it every day, you're not actually adopting. You're
[09:13] excuse me, you're not actually maturing, right? You're not actually improving your usage. You're just faking the numbers to make sure you look like you're using lots of tokens. That's all you're doing. Okay. And then pub in ter t t t t t t t t t t t t t t t t t t t t typically within any organization, any
[09:26] team, any company, you have a skills marketplace. Don't just go publish everything publicly because you know there's plenty of ways for you to go ahead and get sort of messed up or screwed over by referring to a public skill. But the idea is you have an
[09:38] internal skill within your own org and publish to that. So that way you're actually able to contribute so other people can leverage the skills that you've created both figuratively and literally. Make sense so far? Cool. All
[09:51] right. four habits if you're shipping code though. Okay, so let's say yeah super fast. Okay, cap the fleet, orchestrate the rest. What I mean is that if you're draw if you're going to go create a fleet, don't try to run 20
[10:03] at a time. Okay, use orchestration tools to actually help you so you don't actually have to micromanage everything. When you're running things yourself, try to run things only three to four at a time because that's actually what prevents your brain fry. Verify before
[10:17] you commit. Uh, how many of you go ahead and have your coding agents submit the PRs on your behalf without reviewing them? Okay, good. So, I I'm glad some people
[10:29] were honest. Okay, so I expected more of you to actually raise your hands. Okay, and I'm one of them, too. So, I'm not pretending I'm not guilty of this exact same problem. Okay, but that's not a good idea,
[10:41] even though I do it, too. All right, in all seriousness, we can get lazy at times, right? or because we're burning out so we're trying to crush things faster. The reality is we need to verify before we commit. All right, the this is what ends
[10:53] up creating things like the supply chain attacks because I accidentally left the uh the keys directly inside one of my repos. Uh fortunately, I only did that five years ago and you can't guys can't find it anymore. So, I'm fine. But the
[11:06] point is with AI you can do that a lot faster, okay? And miss it. Um I'll talk about the compress the other 92% in a second. And then uh also we're going to talk about fellow humans sign your work.
[11:19] Okay. So yes I'm a human too but the point is that whenever you go ahead and submit a PR you may have be helped by an agent or by an LM but you the human are
[11:32] the ones that actually own that code. All right so understand that concept. So we're going to go into the way four ways this can still go wrong. Like I said, there's concepts like prompt injection, uh the soft squatting that led to things
[11:44] like the supply chain attack, uh secrets and prompts, uh Vive coding without tests. Okay, I'm breezing through that relatively quickly, but these are just four of many things that can go wrong when you don't actually monitor manage
[11:57] your agents properly. Okay, so that that's why we call this out consistently. One of the things that we often have, we talk about what I just talked about the antiatterns, like the things that you don't want to do. Okay,
[12:09] but that's when the engineer disappears from the picture because you allow the agent to run by itself. All right, but then there's this other thing where a lot of people talk about, hey, the 100x engineer orchestrates dozen type, right?
[12:23] In other words, the engineer, the coding developer, what they're doing is basically running these gigantic fleets. That's all they're doing. Okay. Now, this is uh my friend and a very smart guy, Cameron Cameron Edady. He's the CTO
[12:36] of Launch Darkly. No, he's not a datab customer, at least not yet. So, I'm not doing that for that purpose. I'm doing just because he's a good friend of mine. But he actually had a really good quote that I really I want to paste inside here, which is the 100 next is not
[12:48] someone who codes 100 times faster. It's someone who can orchestrate agents continuously and rewrite the worst parts of the product. That's actually what really is happening. Everybody thinks that because
[13:01] you're using coding agents, you can be that much more efficient. And this is what we wanted. I wanted part of the reason I'm we're talking today is because I wanted to spell that. Okay. So, what does the community have to say?
[13:13] So, I'm going to resort to going to asking Reddit. Okay. You all use Reddit in this? No. Okay. You should, by the way. Okay. There's some really good stuff there, by the way. Okay. But, um, the key call out is coding is not equal
[13:26] to software engineering. Those are two distinctly different things. Okay? Writing code is only a small fraction of the job. All right. How many of you have been able to write code without doing a design review, without doing uh
[13:40] analysis, without user cases, without understanding what the customer needs? How many of you been able to do that? Cool. If I was to go ahead and go to Reddit, again, this is fun. If you're bored and you really want to go look at
[13:52] is the community's metaphors is like the calculator is the mathematician or the power tool for the construction worker or claude is just a hammer but you still need an architect. Right? The whole point is that just because you have a
[14:04] coding agent, it's a tool. It's not the whole person. It doesn't represent what they do. Okay? So you still need the blueprint, the guiding tools, yada yada yada. So if you were to apply AMDall's
[14:16] law to AI productivity, what's interesting is that, okay, there's the quote here. AI makes me five times faster, cutting the 10% down to 2%. The remaining 90 or 80% is going to take just as long as it did before. Because
[14:28] before AI, 90% was research, planning, debugging, content, review, all that stuff. Only 10% was coding. So sure, I'm five times faster on the coding part. I still had to do research, planning, debugging, context, review. So all I did
[14:42] was save 8 uh 8%. Okay. So the real ROIs is basically it isn't actually going to be uh the the coding part. It's like can I compress the rest of this the research planning
[14:54] and things of that nature. So when I go back to this this concept of like reasoning agents then like reasoning agent disguise. They aren't really coding agents because a lot of that context is within the developer,
[15:07] right? You know the reasoning. You know the reason why we're doing you know how to debug. You know why we're building this in the first place. So this doesn't replace you because you're the one that created the context. I'm sorry. You're
[15:19] the one who created the idea of why you're building this in the first place. All right. So coding agents won't replace you unless all you do is write code based off of stack overflow then it
[15:31] will so just calling space bait okay so it's sort of a misnomer okay which is basically these reasoning agents happen to live in the harness or the terminal the the IDE right and many many of the
[15:45] sessions ultimately that you are in order to be efficient when it comes to a coding agent is actually done in the design doc reviews the performance reviews things of that nature That's actually
[16:00] cool, but there's an interesting counterpoint. All right, the interesting counterpoint right here on the bottom. Don't worry, I'll expand into this. Gusto's law. You won't bank the 8%. You're just expected to ship more, right? Which is the whole
[16:12] title of this session in the first place, which is to say we actually the efficiencies we get mean we just have to produce more. We have to be more productive. All right. So gush's law for
[16:25] air product the core insight is that assumes the problem size is fixed says that's wrong in practice works expands to fill available capacity yes I have
[16:38] math formulas in there don't worry I'm not going to go through them explicitly in this context right now but the whole point is that the laws that we use for CPU GPU network the design of distributed systems like Apache Spark
[16:52] We constantly have this war between AMD's law and Gustin's law and they apply to AI as well. So the same computer laws that we've been fighting with since the 1960s are still
[17:04] applicable today. I'll skip through this real quickly, but the real context I want to give you is like in order for you to save money when you're trying to do all this stuff, you want to cache aggressively and decompose it deliberately. In other words, use the orchestration layers to basically speed
[17:17] things up and use the content caching so that way you can reduce the cost. In other words, cache the context of of your repo or or the slides that you're trying to produce so that way it doesn't
[17:29] actually have to read the whole thing or extract the whole thing all over again. It already has it in memory to work with. Okay. Um, so that was the real call out. I'm going to skip those. Okay. And so here there's definitely a quality
[17:41] versus quantity problem where basically everybody's putting tons of PRs. This is especially painful for the open source community where basically they're just being inundated with a ton of code that frankly doesn't make any sense. My
[17:53] favorite one was in the Delta Rust repo where the person admitted, I'm not sure what I built. Can you help me with that? Okay, so that's not great. Okay, and then operational complexity, right? Because it's a fleet of agents all interacting with each other. So now it
[18:06] gets harder and harder to figure out what's going on. All right. So, I'm going to skip to just like Apache. Oh, I'll do this real quick. But basically, the idea is that all the learnings that we had for building Apache Spark way back when are still
[18:20] very much applicable because that's what I'm saying. We're fighting even with the days of AI, we're still doing a war between Ambul's law and Gusto's law. Okay? They're still fighting with each other even today. All right? So, and open source for example, we're even
[18:32] fighting this entire concept which is like for example, Kimu has a strict rejection. If it's AI generated content, they refuse to let any of it in. If you look at ASF or Linux Foundation, it's permissive. So you have to things say things like generated by this person but
[18:46] uh but assisted by these agents as an example, right? Um and then basically fundamentally it means AI writes human sign. So in other words, even if you're
[18:58] getting an agent to go write this code for you or this PRD for you, somebody has to sign off on that. Some person has to sign off on that. If I look at the Linux kernel for example, only humans can sign off the DCO. So that's becoming
[19:10] much more the way everybody's doing things which is great. And so that's why I meant by generated by insisted by. So for example, if you look at even these slides, I have a generated by and assisted by just to call out exactly what's going on. All right. So saying
[19:23] all that, I'm almost done. So you guys can get to see the main show. Three line recap for y'all, right? Adoption is solved, but maturity is the question.
[19:35] Now, that's the problem that we're trying to face. At the speed of we're going, we're already facing that problem. What you're all feeling, what you're all suffering from is a version of number two. You're faster. You're not faster, excuse me. You're just expected to do
[19:48] more, right? So, doing things like fleet management, orchestration allow you to do more. Do it in an effective way so you don't burn out. And number three, AI's rights, but humans. So right now we
[20:01] are still the ones that have to ensure that the codebase we're writing actually makes sense. All right. So saying that thanks

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.