# Developer Experience in the AI Era — Helping Engineers Stay Competitive > Source: > Published: 2026-07-06 14:57:24+00:00 # Developer Experience in the AI Era — Helping Engineers Stay Competitive [Tadashi Shigeoka](/en/author/tadashi-shigeoka/)· Mon, July 6, 2026 I was teaching a Claude workshop. Meaning to demo the basics for the attendees, I typed “tell me about myself” into the [Claude](https://www.claude.com/) chat, and back came a summary drawn from across the articles I’d written and the talks I’d given. It was a fun little aside. But what really made me think came right after. One of the engineers attending the workshop asked me: “How do you think about improving Developer Experience in the AI era?” A theme I’d cared about for years, rephrased in the present tense and handed to me by an engineer sitting right in front of me. It was a slightly uncanny experience. I’d started out as the one teaching, and somewhere along the way I’d become the one being asked. I answered on the spot with what I was thinking at that moment. But even as I spoke, I felt the question deserved to be sat with properly. This post is my attempt to take what I said out loud and rework it, from where I sit as a CTO watching both technology and organization in a fully remote company. ## What Developer Experience Used to Mean Before talking about the AI era, it’s worth pinning down what Developer Experience actually referred to. It’s often abbreviated as DX, but since DX collides with the customer-facing digital transformation, in this post I’ll call it DevEx, short for developer experience. The DevEx I mean here is developer experience in the literal sense: how comfortably, how free of hesitation, how deeply focused the people building software can work, day to day. The paper that turned this concept into practical language was [DevEx: What Actually Drives Productivity](https://queue.acm.org/detail.cfm?id=3595878) by Abi Noda, Nicole Forsgren, and colleagues. It frames developer experience along three axes: fast feedback loops, low cognitive load, and the ability to reach a flow state. Do builds come back quickly? Do tests return results fast? Do reviews avoid piling up? Is the required background knowledge not excessive? Is there uninterrupted time to immerse yourself, free of context switches? At bottom, DevEx was the work of reducing these three kinds of friction. The measurement frameworks had matured too: the four [DORA](https://dora.dev/) metrics that look at deployment frequency and lead time for changes, and the [SPACE](https://queue.acm.org/detail.cfm?id=3454124) framework that captures developer productivity across many faces, from satisfaction to efficiency. What they shared was a refusal to reduce productivity to raw output, treating it instead as the whole of the environment and the experience a developer sits inside. When I’ve talked about improving DevEx, that was the context: shaving away friction one piece at a time so engineers can focus on the work that matters. ## What AI Changed So what did AI change? If I had to put my honest impression into one phrase: a torrential era arrived. First, the cost of writing code itself dropped dramatically. With a coding agent like [Claude Code](https://www.claude.com/product/claude-code) or [Codex](https://openai.com/codex/), an implementation that used to take half a day becomes a working draft in minutes; investigating an unfamiliar library, scaffolding tests, sketching a refactor, all move at once through conversation. In DevEx terms, feedback loops shortened, part of the cognitive load got shouldered for you, and many of the small snags that break flow disappeared. Put another way, someone who can develop in an AI-native way can satisfy all three DevEx axes at once, fast feedback loops, low cognitive load, and flow state, through the sheer force of the tooling. Some of what traditional DevEx was reaching for is now being filled rapidly from the tooling side. But the story doesn’t end there. As the friction fell, the bottleneck shifted. Once the speed of writing code stops being the constraint, what gets asked of you next is the judgment to see what should be built, the ability to read and evaluate large volumes of generated code and ship it under your own responsibility, and the capacity to design and integrate the system as a whole. In an era where AI can mass-produce drafts, developer experience can no longer be described only as “how much typing friction did you remove.” How well you can collaborate with this new partner has itself become the substance of DevEx. And the pace of change is extraordinary. The usable models and tools get overwritten on a scale of months, and yesterday’s optimal answer is obsolete today. Left alone in this environment, DevEx degrades easily. The gap between an engineer without the latest tools and one who wields them fluently widens at a speed unlike anything before. That’s what I mean by a torrential era. ## Leadership Provides the Environment, Without Hesitation In this situation, what I as part of leadership should do first is clear: give people an environment where they can use AI, without hesitation. I see this not as a perk but as the very foundation of DevEx in the AI era. The latest coding agents, generous usage limits, and the setup that lets people use them safely at work. Skimping here is the same as taking away the weapons an engineer needs to fight at the front line. The license cost of the tools pays back overwhelmingly, as an investment in productivity and, more than that, in people growing. If traditional DevEx meant speeding up CI, tidying the development environment, and cutting pointless meetings, then providing an environment where AI can be used without hesitation belongs squarely on that same continuum. That’s how I read it. At the same time, it isn’t done just by handing out accounts. How to use it so it actually helps, where the pitfalls are, how to handle confidential information: sharing that knowledge across the team and building a foundation people can step into with confidence is also part of providing the environment. The Claude workshop I opened with was one I ran for people outside the company, but the thinking about how you hand over the tools is exactly the same inside it. Not just distributing the tools, but preparing the scaffolding to use them to the fullest. That much, I believe, is the responsibility of whoever provides the environment. ## Providing It Isn’t Enough: Use It to the Fullest and Run at the Front But providing the environment is a necessary condition, not a sufficient one. From here on is the part entrusted to each engineer. What I genuinely hope for is that they use the environment they’re given to the fullest, without holding back, and keep running at the front line. A tool means nothing while it’s merely owned. Only when you touch it, try it, fail with it, and work it into your own craft does it become power. Delegate boldly the parts AI can take, and redirect the freed-up time and cognitive headroom toward design, verification, and harder problems. Don’t swallow generated code whole: read it, doubt it, fix it, and ship it under your own responsibility. The people who can spin this loop fast are the ones who’ll run at the front line from here on. It isn’t about taking it easy because the AI writes it for you. It’s the opposite: precisely because the AI writes it, you can step more deeply into the judgment and the design only a human can do. Using it to the fullest means that leaning-forward posture. Here’s a paradox. The more AI takes on the drafting, the more the fundamentals actually matter. To see whether generated code is any good, you need a solid axis of evaluation inside yourself. To judge whether a design is sound, you have to understand the principles. The gap between someone who dumped everything on the AI and stopped thinking, and someone who used the AI as a lever to accelerate their thinking, widens almost cruelly over time. So alongside using it to the fullest, keep learning: not just how to operate the tool, but the essence beneath it. Running at the front line isn’t chasing trends. It’s holding onto both the fast-moving surface and the unchanging fundamentals at the same time. ## The Goal: Being Called “Excellent, from That Company” So what am I aiming for, through all of this? Let me write down the thing I most wanted to say. What I’m aiming for is that our engineers, even if they someday leave this company, stay the kind of people who remain competitive in the market, the kind described as “engineers from that company are excellent.” Not an optimization that only works inside this company, but portable, real ability that holds up anywhere they go. Improving DevEx in the AI era, taken to its conclusion, is where I think it lands. As a manager, this might sound like a strange thing to say. The more the engineers who’ve grown through their time at the company become excellent, the more other companies court them, and they might leave. Even so, I don’t want to choose not to grow people’s abilities in order to fence them in. Quite the reverse: I believe that helping people become good enough to succeed even after leaving is, in the end, what builds the strongest organization. If you stay here, your market value rises; you get the front-line tools and experience. Because people believe that, it becomes a reason excellent people gather and stay. Promising ability that carries over even after you leave, and being a place people want to stay, do not contradict each other. This is also an attempt to pull the true subject of the word DevEx back from the organization to the individual. Traditional DevEx has often been framed as developer experience in service of maximizing the organization’s output. But the subject of the experience is, always, each individual engineer. That they themselves run through this torrential era while finding it genuinely interesting, and look back a few years later to find they’ve become someone who can compete in the market: that sense of traction is the best Developer Experience I can imagine. The company’s productivity follows afterward, as a result. You mustn’t reverse the order. ## Conclusion Here is my current answer to the question I was asked at that workshop, “improving Developer Experience in the AI era,” in three points. **From removing friction to the bottleneck moving**: By collapsing the cost of writing code, AI shifted the focus of DevEx from typing friction to judging what to build, evaluating what’s generated, and designing the system. Collaborating with AI has itself become the substance of developer experience**Leadership provides the environment; using it to the fullest is on you**: Preparing an environment where the latest AI can be used without hesitation is leadership’s responsibility. But that’s only a necessary condition; using it to the fullest, learning the fundamentals, and running at the front line is entrusted to each engineer**The goal is portable competitiveness**: Not an optimization confined to the company, but ability that has people say “excellent, from that company” even after you leave. Pulling the subject of DevEx back from the organization to the individual is, in the end, what builds the strongest organization Having written out an answer to the question I was asked that day, I find myself thinking again: no matter how clever the tools get, in the end it’s people who run. Shaping the environment so those people can find this torrential era interesting and keep their competitiveness intact. That was the substance of the Developer Experience improvement I want to deliver in the AI era. That’s a view from the ground, thinking about Developer Experience after being asked about it by an engineer in the room, from where I sit watching technology and organization in a fully remote company.