AI Engineer Code 2025
Developer Experience in the Age of AI Coding Agents
Read the talk
Developer Experience in the Age of AI Coding Agents
Coding agents make development environments, testability, written context and code review more consequential—and give teams a reason to invest in foundations that also help humans.
From a talk by Max Kanat-Alexander
Before you start: Familiarity with automated tests, continuous integration and pull-request review will help you follow the examples.
What will still be worth the investment?
Every few weeks, a developer arrives with another tool they want to use. The developer-experience team has barely evaluated the last release before someone asks about the next one. Refusing a tool that appeared yesterday used to feel straightforward; with coding agents, the answer increasingly becomes: perhaps we should try it.
That creates a practical investment question: what can an engineering organization improve now that it will still be glad it improved at the end of 2026? Buying access to coding agents is one answer, but it cannot repair every surrounding problem in a company.
Max Kanat-Alexander approaches the uncertainty through two questions. Which developer-experience principles remain valuable regardless of how agents change? And what must improve outside the agents to make both agents and developers as effective as possible? The durable investments are in the inputs and working conditions around the agent, where improvements can benefit humans as well.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use tools the way the industry uses them
Start with the development environment: build tools, package managers and linters. Kanat-Alexander recommends industry-standard tools used in conventional ways. His rationale is that those conventions are represented in model training data, giving agents familiar patterns to work from.
An instruction file can explain a heavily modified toolchain, but it also asks the agent to override familiar behavior. A bespoke package manager makes that problem concrete: instead of continually teaching the agent your replacement, consider returning to the standard tool. The recommendation is about reducing the amount of unusual behavior an agent must learn before it can do useful work.
Kanat-Alexander applies the same reasoning to programming languages. Although he enjoys exploring languages, he says he no longer uses obscure ones in his everyday agentic development work. That does not mean new tools must stop emerging; enthusiasts can still explore them.
The tension between experimentation and operational responsibility predates agents. His hypothetical request is to put an unvetted technology released last week underneath a service handling 100,000 queries per second and serving a billion users. Familiarity to a model adds another reason for caution, but the underlying enterprise judgment was already necessary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give agents direct actions and useful failures
Once the environment is familiar, the agent needs a way to act. A CLI or API exposes operations directly. Computer use and browser orchestration with Playwright are alternatives, but when a direct interface is available, Kanat-Alexander favors the text interaction agents already use naturally. Each action must work accurately for the larger workflow to succeed; unnecessary interaction complexity makes that harder.
The next requirement is objective, deterministic validation. Tests and linters tell an agent whether a change satisfies a rule, and clear failure messages help it decide what to repair. Whether a human or an agent wrote the validator matters less than the quality of that feedback. A bare 500 Internal Server Error tells the agent something failed without explaining the cause or the next useful action.
Asking the agent to write tests does not automatically solve this. On an untestable system, it may produce a test that establishes only that a button was pressed successfully. The test passes while saying little about the behavior the button was supposed to trigger. Legacy systems with only broad end-to-end tests often lack the focused unit tests that an agent can run repeatedly and use to diagnose a specific failure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make behavior possible to inspect
Useful validation depends on system structure. Some legacy codebases are difficult to reason about because the necessary information is missing, or because their organization hides how behavior fits together. An agent can investigate by running the system and seeing what breaks, just as a human can. But that trial-and-error process is a substantial handicap compared with being able to understand the code directly.
The button example exposes the connection between structure and testability. If a test can observe the button press but cannot observe the explosion behind it, generating more tests against the same narrow interface will not reveal the hidden outcome. A human or agent may first need to refactor the code so the relevant behavior becomes observable.
For a concrete illustration, suppose a button reserves stock. Separating the reservation logic from the click handler makes it possible to test the state change and the failure condition directly:
javascript
import assert from 'node:assert/strict';
import test from 'node:test';
function reserveStock(stock, quantity) {
if (!Number.isInteger(quantity) || quantity <= 0) {
throw new Error('Quantity must be a positive integer');
}
if (quantity > stock.available) {
throw new Error(
`Insufficient stock: requested ${quantity}, available ${stock.available}`
);
}
return { ...stock, available: stock.available - quantity };
}
test('reservation reduces available stock and preserves the SKU', () => {
const stock = { sku: 'book', available: 3 };
assert.deepEqual(reserveStock(stock, 2), {
sku: 'book',
available: 1,
});
});
test('reservation rejects insufficient stock', () => {
assert.throws(
() => reserveStock({ sku: 'book', available: 3 }, 4),
{ message: 'Insufficient stock: requested 4, available 3' }
);
});
The important change is what the test can know: it checks the reservation result rather than merely confirming that a handler ran. That is the structural prerequisite behind the recommendation to improve tests.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Document what the code cannot tell you
Documentation debates often focus on whether engineers should write more of it. The agent makes a narrower question unavoidable: where can it find the information it needs? It did not attend an untranscribed meeting. Requirements, specifications and reasons for building a system cannot remain solely in the memories of the people who discussed them.
That does not imply duplicating everything already expressed in code. If the code is comprehensible, an agent can explain its structure. The distinction is between information recoverable from the implementation and information that must come from elsewhere:
| Information | Where the agent can find it |
|---|---|
| Existing code structure | Comprehensible implementation |
| Why the system was built | Written intentions and decisions |
| Accepted URL-parameter shape | An existing validator, if present |
| Expected external input before implementation | An accessible specification |
An existing validator can describe accepted input. Before that validator exists, the agent cannot infer the outside world's contract simply by reading code that has not yet been written. Write down what is absent from the code, somewhere the agent can access.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make each review response faster
Engineers have long spent more time reading code than writing it. With agents, even producing code increasingly means reading proposed changes. As Kanat-Alexander puts it, “writing code has become reading code.” Engineers become reviewers throughout development, while increased pull-request volume creates another review bottleneck downstream.
Both loops need attention: the formal review of a pull request and the developer's immediate response to an agent. Optimize the time to each useful response, while retaining the iterations needed for a correct result. A review is a quality process. An arbitrary five-minute cutoff is no reason to accept broken code. Faster agent execution helps only part of the loop; humans also need to recognize problems and decide the next step quickly.
At the team level, asking a Slack channel whether any of ten people can review a PR leaves responsibility ambiguous. The most responsive person tends to pick up the work. Kanat-Alexander illustrates the imbalance with one reviewer doing 50 reviews while others do three, two, five or seven. That informal arrangement becomes harder to sustain as agents generate more PRs.
A more deliberate review process needs three things:
- Assign each review to a specific person through a system that distributes work.
- Set response service-level objectives, or SLOs, with a mechanism for enforcing them.
- Make it clear whose turn it is to act.
The third requirement concerns handoffs, not just assignment. After a reviewer leaves comments, an author might reply to one, push a change, then answer the rest. Which event means the PR is ready for another review? Kanat-Alexander's criticism of GitHub concerns that ambiguity, not the absence of a re-review request feature. Relying on an extra Slack message to announce readiness leaves people manually coordinating the workflow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep experienced reviewers in the work
Speed is useful only alongside review quality, both when a developer evaluates agent output and when a teammate reviews the resulting PR. Software design does not require perfection: the goal is good enough and better than before. But the expected lifetime of a system determines how demanding “good enough” must be. A long-lived system may need a substantially higher bar than a short-lived one.
A review process must be capable of rejecting changes that should not enter the system. Otherwise, each accepted change can make later work harder for both humans and agents, eroding the productivity benefit of generating code quickly.
Maintaining that judgment requires apprenticeship. Yet the strongest reviewers are often occupied with meetings, strategy and high-level reviews, leaving little time to teach through ordinary code review. Kanat-Alexander says that in more than 20 years he has found no substitute for doing good reviews with people who are learning. Developing reviewers therefore requires giving experienced engineers time to review actual code alongside less experienced colleagues.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The next change inherits the last one
These conditions interact. Start with a confusing environment and a difficult codebase. The agent produces poor changes, the developer becomes frustrated, and eventually a PR goes out because the developer thinks it probably works. An overwhelmed reviewer cannot establish whether it is sound and approves it anyway. The next task now begins in a worse codebase.
Kanat-Alexander predicts that organizations caught in this cycle will see agent productivity decrease through the year. The mechanism is cumulative: weak review admits changes that make the next round of generation, understanding and validation harder.
The positive cycle begins with improving those working conditions. More effective agents can help developers make further improvements, which in turn support more effective work. Foundational changes can be expensive, but Kanat-Alexander sees this period as an opportunity for organizations able to make them to distinguish themselves through software engineering velocity.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put feedback inside the development loop
There is a final operational requirement behind the tooling recommendations: CLIs and APIs must work during development, not only in CI. A capability that becomes available only after submitting a change is poorly positioned for repeated local correction.
Kanat-Alexander characterizes agents as more persistent and patient than humans, but also more error-prone, making repeated validation especially consequential. His illustrative scenario has CI taking 15–20 minutes and an agent repeating the run-and-test cycle five times; he contrasts 20-minute feedback with 30-second feedback. Patience does not remove the delay from the developer's workflow. Making each check fast changes how usable that repeated correction process is.
That development-time condition completes the investments already described: familiar environments and executable interfaces need useful validation; validation needs code that can be tested and understood; the agent needs accessible intentions and external context; and the resulting changes need prompt, discerning review. These are connected improvements, not an exhaustive list of everything an organization could do.
Their lasting value comes from the people who also use them. Clearer code, faster feedback and better review help developers even if a particular investment delivers less benefit to an agent than expected. The closing principle is that what is good for humans is good for AI—and the human benefit remains even when the agent benefit falls short.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Install Playwright and run browser tests locally or in CI, with terminal output and HTML reports.
Further reading
Max Kanat-Alexander explains iteration time, focus, cognitive load and the organizational work behind effective developer tools.
- Speed of Code ReviewsDocumentation
Google's guidance on prompt review responses, protecting focused work and maintaining code quality.
Updates since the talk
Current instructions for distributing review requests among team members using round-robin or load-balancing rules.
Read the complete timestamped transcript
- 0:00
[on-hold music] How's everybody doing?
- 0:22
Still awake? Okay, great. So, like the robot voice said, I have been doing developer experience for a very long time, and I have never in my life seen anything like the last 12 months.
- 0:36
But, you know, about every two to three weeks, software engineers been making this face on the screen. [laughs]
- 0:43
Okay? And if you work in developer experience, the problem is even worse. You're like this guy on the screen. Every few weeks, you're like, "Oh, yeah, yeah, yeah, yeah, yeah.
- 0:53
Here's the new hotness." And then somebody else comes up, and they're like, "Well, can I use the, the new new hotness?" And you know, people have been doing that for years.
- 1:00
I've been working in developer experience for a long time. Everybody always shows up, and they're like, "Oh, can I use this tool that came out yesterday?" And you're like, "No, of course not."
- 1:07
And now we're like, "Uh, maybe yes." [laughs] Right? And what this leads to overall is the future is super hard to predict right now. So
- 1:19
I think a lot of people, a lot of CTOs, a lot of people who work in developer experience, to people who care about helping developers are asking themselves this question:
- 1:27
Are all of my investments gonna go to waste? Like, what can I invest in now that if I look back at the end of 2026, I'll be like, "I sure am glad that I invested in that for my developers."
- 1:39
And I think a lot of people have just decided, "Well, I don't know. I guess it's just coding agents, and I guess they'll fix every single thing about my entire company by themselves."
- 1:47
Which look, they're amazing, they're transformative, but it's not the only thing that you need to invest in as a software engineering organization. So we can clarify this by asking ourselves two questions.
- 1:58
The first one is, how can we use our understanding of the principles of developer experience to know what's gonna be valuable no matter what happens, okay? And what do we need to do to get the maximum possible value from AI agents?
- 2:14
Like, what would we need to fix at all levels outside of the agents in order to make sure that the agents and our developers can be as effective as possible?
- 2:24
And this isn't like a minor question. These are the sorts of things that could make or break you as a software business going into the future.
- 2:32
So let's talk about what some of those things are that I think are no-regrets investments that will help both our human beings and our agents. So the-- In general, one of the framings that I think about here is things that are inputs to the agents, things around the agents that help them be more effective.
- 2:49
And one of the biggest one is the development environment. What are the tools that you use to build your code? What package manager do you use? What linters do you run?
- 2:58
Those sorts of things. You wanna use the industry-standard tools in the same way the industry uses them, and ideally in the same way the outside world uses them, because that's what's in the training set.
- 3:12
And look, yes, you can write instruction files, and you can try your best to try to fight the training set and make it do something unnatural and unholy with some crazy amalgamation that or modification that you've made of those developer tools.
- 3:24
Like, you might, you invented your own package manager. You probably should not do that. You probably should undo that and try to go back to the way the outside world does software development because then you are not fighting the training set.
- 3:37
Um, and also it means, it means things like you can't use obscure programming languages anymore. Look, I'm a programming language nerd. I love those things. I do not use them anymore in my day-to-day agentic software development work.
- 3:50
As an enthusiast, I do come-- sometimes go when I code on, you know, frontline, uh, software engineering languages, but not in my, like, real work anymore.
- 4:00
So what people ask me sometimes, "Does that mean, like, we're never gonna ever have any new tools again because we're always gonna be dependent on the tools that the model already knows?"
- 4:06
Probably not, because like I said, there's still gonna be enthusiasts. And also-- But, like, I would like to make a point. The thing that I'm talking about has always been a real problem.
- 4:15
Like, there's always some developer at the company has always come up to you and be like, "Can I use this technology that came out last week and has never been vetted in an enterprise to run my, like, one hundred thousand queries per second service that serves a billion users?"
- 4:28
And I'm like, "No, you can't do that now, and you can't do that yesterday. It's still the same."
- 4:34
Uh, another one is, in order to take action today, agents need either a CLI or an API to take that action. Yes, there's computer use. Yes, you can make them write Playwright and orchestrate a browser, but why?
- 4:47
Like, if you could have a CLI that the agent can just execute natively in its normal format that it understands the most natively, which is text interaction, why, why would you choose to do something else, especially in an area where accuracy matters dramatically and where that accuracy dramatically influences the effectiveness of the agent?
- 5:07
One of the most important things that you can invest in is validation. So any kind of objective, deterministic validation that you give an agent will increase its capabilities. So yes, sometimes you can create this with the agent, I'm gonna talk about that in a second, but it doesn't really matter how you get it or where you get
- 5:22
it from. You just need to think about, how do I have high-quality validation that produces very clear error messages? This is the same thing you always wanted, by the way, in your tests and your linters, right?
- 5:35
But it's even more important for the agents because the agents cannot divine what you mean by five hundred internal error with no other message, right? Like, they need a way to actually understand what the problem was and what they should do about it.
- 5:50
However, there is a problem here. So, you know, you think, "Okay, I'll just get the agent to do it. They'll write my tests, and then I'll be fine." But have you ever asked an agent to write a test on a completely untestable code base?
- 6:03
They do kind of what it's like is happening on the screen here. They will write a test that says, "Hey, boss, I pushed the button, and the button pushed successfully.
- 6:12
Test passed." Um, like, so there is a sort of a, a larger problem that a lot of enterprises have in particular, which is there's a lot of legacy code bases that either were not designed with testing in mind or were not designed with like high quality testing in mind.
- 6:30
Like maybe they just have like some very high level end-to-end tests, and they don't have like great unit tests that the agent can actually run iteratively in a loop and that will produce actionable and useful errors.
- 6:40
So another thing that you can invest in that will-- can be perennially valuable both to humans and to agents is structure of your systems and structure of your code bases.
- 6:50
Agents work better on better structured code bases. And for those of you who have never worked in a large enterprise and seen very old legacy code bases, you might not be familiar with what I'm talking about, but for those who have, you know that there are code bases that no human being could reason about in any kind
- 7:05
of successful way because the information necessary to reason about that code base isn't in the code base, and the structure of the code base makes the code base impossible to reason about by looking at it.
- 7:16
Yes, you-- the agents can do the same thing human beings do in that case, which is sort of go through an iterative process of trying to run the thing and see what breaks, but that decreases the capability of the agent so much compared to just it having the ability to just look at the code and reason about
- 7:32
it the exact same way that human capability is decreased. And of course, like I said, that all has to lead up to being testable. If the only thing I can do with your code base is push a button and know if the button pushed successfully and not see the explosion behind it, like if, if, if there's no
- 7:49
way to get that information out of the code base from the test, then the agent's not gonna be able to do that either unless it, it goes and refactors it or you go and refactor it first.
- 8:00
And, you know, there's a lot of talk about documentation. There's always been a lot of talk about documentation in the field of developer experience, in the field of improving things, and there's-- people go back and forth about it.
- 8:10
Engineers hate writing documentation, uh, and the value of it is often debated, like what kind of documentation you want or don't want, do or don't want. But here's the thing: the agent-- Let's just take this in the context of the agent.
- 8:24
The agent cannot read your mind. It did not attend your verbal meeting that had no transcript [laughs]
- 8:31
. Okay? Now, there are many companies in the world that depend on that sort of tribal knowledge to understand what the requirements are for the system, why the code is being written, what is the specification that we're, we're writing towards.
- 8:47
If things are not written down, and that sounds like blatantly obvious, but like there are a lot of things that are fundamentally written. Like if the code is comprehensible, like all the other steps are in that we've gotten to so far, you don't need to re-explain what's in the code.
- 9:04
So there's actually probably a whole class of documentation that we may not need anymore, where you can just ask the agent like, "Hey, tell me about the structure of this code base overall," and it'll just do it.
- 9:12
But it won't be able to ever know why you wrote it unless that's written down somewhere. Or things that happen outside of the program, like what is the shape of the data that comes in from this URL parameter, as an example.
- 9:26
Like if you have already written the code, there's a validator, and that does explain it. But if you haven't written the code yet, it doesn't know what comes in from the outside world.
- 9:34
So basically anything that can't be in the code or isn't in the code needs to somehow be written somewhere that the agent can access.
- 9:44
Now, we've covered sort of a few technical aspects of things that we need to improve, but there's a point about software development in general, and it-- that's always been true.
- 9:55
And one of-- and that's-- You've heard this. We spend more time reading code than writing it. The difference today is that writing code has become reading code. So even now when we are writing code, we spend more time reading it than actually typing things into the terminal.
- 10:14
And what that means is every software engineer becomes a code reviewer as basically their primary job. In addition, as anybody who has worked in a, in a shop that has deeply adopted agentic coding, we generate far more PRs than ever before, which has led to code review itself, the like the big scale code review, being a bottleneck.
- 10:41
So one of the things that we need to do is we need to figure out how to improve code review velocity, both for the big code reviews that we like where we-- you send a PR and somebody like, you know, writes comments on it and you go back and forth, and also just the iterative process of working
- 10:56
with the agent. How do you speed up the-- a person's ability to look at code and know what to do with it? So
- 11:05
the principles are pretty similar for both of those, but the exact way you implement them is a little bit different. What you care about the most is making each individual response fast.
- 11:16
You don't actually want to shorten the whole timeline of code review generally because code review is a quality process. It's the same thing with agent iteration. Like what you want with agent iteration is you want to get to the place where you've got the right result.
- 11:32
You don't wanna like just be like, "Well, I guess I've hit my five-minute time limit, so I'm gonna check in this garbage that doesn't work." Right? You, you c-- But what you do want is you want the iterations to be fast.
- 11:41
Not just the agent's iterations, but the human response time to the agent to be fast. And in order to do that, they have to get very good at doing code reviews or knowing what the next step is to do with a lot of code.
- 11:54
At the big code review level, one thing that I see that I think is sort of a social disease that has infected a lot of companies is when people want PR reviews, they just send a Slack message to a team channel and say, "Hey, could one of the ten of you review my PR?"
- 12:09
And what-- And you know what that means is one person does all those reviews. That's what really happens. There, there's like, a- and when you look at the code review stats of teams like that, there's one person who has, like, 50, and the other person have, like, three, two, five, seven, because there's just one person who's, like,
- 12:23
super responsive. So but what that means is if you start generating dramatically more PRs, that one person cannot handle the load. You have to distribute it, and really the only way to distribute it is to assign it to specific individuals, have a system that distributes it among those s- individuals, and then set SLOs that have some mechanism
- 12:40
of enforcement. And another thing is, like, that GitHub, for example, is not very good at today, is making it clear whose turn it is to take action. Like, I left a bunch of comments on your PR.
- 12:52
Uh, you now responded to one of my comments. Should I come back again now? Oh, wait, no, no, now you pushed a no change. Should I come back now?
- 13:02
Okay, no. Oh, no, now you've responded to more comments. What I rely on mostly is people telling me in Slack, "I'm ready for you to review my PR again," which is a terrible and inefficient system.
- 13:14
And another thing you gotta think about a lot is the quality of code reviews, and I mean this, once again, both for the individual developers doing it with the agent and the people doing it in the code review pipeline.
- 13:29
You have to keep holding a high bar. I know that people have other opinions about this, and yes, depending on the timeline that you expect your software to live, you might not need as much software design.
- 13:40
Like, look, it's ... Software design is not the goal of perfection. It's a goal of good enough and better than you had before, right? But sometimes good enough for a very long-lived system is a much higher bar than people expect it to be,
- 13:54
and if you don't have a process that is capable of rejecting things that shouldn't go in, you'll p- very likely actually see decreasing productivity gains from your agentic coders over time as the system becomes harder and harder for both the agent and the human to work with.
- 14:10
The problem is this: in many companies, we have the people who are the best code reviewers not doing any of their time doing code review. They are spending all their times in meetings, doing high-level reviews, doing strategy, and so we aren't teaching junior engineers to be better software engineers and to be better code reviewers.
- 14:32
So we have to have some mechanism that allows the people who are the best at this to do this through apprenticeship. If somebody else has a better way of doing this than doing code reviews with people, I would love to know, because in the 20-plus years that I've been doing this, I have never found a way to
- 14:46
teach people to be good code reviewers other than doing good code reviews with them.
- 14:54
Now, if you do ... If you don't do all the things that I talked about, what is the danger? The danger is you take a bad code base with a confusing environment, you give it to an agent or a developer working with that agent.
- 15:10
The agent produces relative levels of nonsense, and the developer experiences more or less frustration, and depending on how persistent they are, at some point they give up, and they just send their PR off for review.
- 15:25
They're like, "I think it works," right? And then if you have low-quality code reviews or code reviewers who are overwhelmed, they go, "I don't know. I don't know what to do with this.
- 15:35
I guess it's okay," and you just have lots and lots and lots of bad rubber-stamp PRs that keep going in, and you get into a vicious cycle where what I expect to occur and what my prediction is is if you are in this cycle, uh, your agent productivity will decrease consistently through the year.
- 15:52
On the other hand, we live in an amazing time where if we increase the ability of the agents to help us be productive, then they can actually help us be more productive, and we actually get into a virtuous cycle instead, where we actually accelerate more and more and more and more.
- 16:10
And yes, some of these things sound like very expensive fundamental investments, but I think now is the time to make them, because now is one of the times you're gonna have the biggest differentiation in your business in terms of software engineering velocity if you can do these things versus other in- industries or companies that can't structurally do
- 16:28
these things. So to summarize, here's a few things. Not literally everything in the world you could do that's no regrets, but you can standardize your development environments. You can make CLIs or APIs for anything that needs a CLI or API.
- 16:42
Those CLIs or APIs have to run at development time, by the way, too. Another big thing that people miss is sometimes they have things that only run in CI.
- 16:50
If your CI takes 15, 20 minutes, and you know, agents are, like, way more persistent and patient than a human being is, so, like, but they're also more error-prone than human beings are.
- 17:01
So, like, they will run the thing and then run your test, and then run the thing and then run your test, and then run the thing and then run your test, and they'll do it, like, five times in a row.
- 17:07
If that takes 20 minutes, your developers' productivity is gonna be shot to heck, whereas if it t- takes 30 seconds, you're gonna have a ... They're gonna have a much better experience.
- 17:17
You can improve validation. You can refactor for both testability and the ability to reason about the code base. You can make sure that all the external context and your intentions, the why, is written down.
- 17:27
You can make every response during code review faster, and you can raise the bar on code review quality. But if you look at all of these things, there's one lesson and one principle that we take away from all these things that covers even more things than this,
- 17:40
and it's basically that what's good for humans is good for AI. And the great thing about this- [applause] One second. The great thing about this is that it means that when we invest in this thing, we will help our developers no matter what.
- 17:55
Even if sometimes we miss on helping the agent, we are guaranteed to help the humans. Thank you very much. [applause] [upbeat music]