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. The you know about every 2 to 3 weeks software engineers been making this face on the screen. 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. 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 what this leads to overall is the future is super hard to predict right now. So, a lot of people, a lot of CTO's, a lot of people who work in developer experience to people who care about helping developers are asking themselves this question, are all of my investments going to go to waste? Like, what could 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. 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 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.

One of the biggest ones is the development environment. What are the tools that you use to build your code? What package manager do you use? What llinters do you run? Those sorts of things. You want to 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. 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. 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.

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.

In order to take action today, agents need either a CLI or an API to take that action. Yes, there's computer use. You can make them write playright and orchestrate a browser. But why? 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?

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. 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 llinters, right? But it's even more important for the agents because the agents cannot divine what you mean by 500 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.

Agents work better on better structured code bases. For those who have worked in large enterprise, you know that there are code bases that no human being could reason about in any kind of successful way because the information necessary to reason about that codebase isn't in the codebase and the structure of the codebase makes the codebase impossible to reason about looking at it. Yes, 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 it.

The agent cannot read your mind. It did not attend your verbal meeting that had no transcript. 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? 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.

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. And what that means is every software engineer becomes a code reviewer as basically their primary job. In addition, 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.

So one of the things that we need to do is we need to figure out how to improve code review velocity. What you care about the most is making each individual response fast. You don't actually want to shorten the whole timeline of code review generally because code review is a quality process. If you don't have a process that is capable of rejecting things that shouldn't go in, you will 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.

If you have low quality code reviews or code reviewers who are overwhelmed, 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 is your agent productivity will decrease consistently through the year. 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.

So to summarize, standardize your development environments. Make CLIs or APIs for anything. Improve validation. Refactor for testability and reasoning. Make sure the 'why' is written down. Speed up code review responses and raise the bar on quality. What's good for humans is good for AI.