The IDE is dead. Now what?

**Chris Kelly:** I think everybody is tired because of how quickly everything is changing. Some would say the IDE is dead. What you're doing as an engineer is actually different work, and that's a really important shift that I don't think a lot of people have made yet. In a year or two, what we think of engineering is not writing code — it's building the factory system.

I'm not working on the factory line. **Emma Webb:** You're listening to We Built What? The podcast for engineering leaders building in the agentic era. I'm Emma Webb, your host from Augment Code, and today I'm here with my colleague and pal Chris Kelly, our product lead. Chris, thanks for joining. **Chris Kelly:** Thanks for having me.

**Emma Webb:** So Chris, you've had a front row seat to all of these major developments in software engineering from your time at GitHub, New Relic, Salesforce, and Fire Hydrant. How do we contextualize this AI moment compared to everything else you've seen throughout your career? **Chris Kelly:** Software has always been changing, but this is different.

It's not just making a faster horse. Everything from low level to high level languages was still doing normal programming, just at a higher abstraction level and faster. What's actually changing now is the work itself. We used to generate more code. Now, as agents have really started to take hold, what you're doing as an engineer is different work.

In a year or two, what we think of engineering won't be writing code. It'll be building the factory system, not working on the factory line. **Emma Webb:** Can you give me more specific examples of the before and after? **Chris Kelly:** Assembly to C was a huge shift. Punch cards to assembly was a big shift. But those were all just doing the same work faster.

What's shifting now is we're not trying to write more code. I'm trying to get LLMs to produce code the way I want it produced. I'm not thinking about the end software, I'm thinking about how that software gets assembled. The goal of software engineering now is making sure the LLM produces the kind of code we want, and less about make this button do this thing.

You're making sure the agent has the right context and structure so it can build the software for you. We used to produce more code. Now we're producing code to produce something different. In the factory analogy, we used to work on the line making widgets by hand, then with a lathe. We just did the same thing faster. Now I'm the engineer making the lathe so the agent can make the widget.

**Emma Webb:** The role is very different. Is it less fun, more fun, a different kind of fun? **Chris Kelly:** I come from the software craftsman part of the industry that cared about software craft, object oriented design, really thinking about the code we're building. There's definitely a loss there, and that's hard to let go of.

If you really love the craft of writing the perfect system, you're going to feel some loss. I empathize with that. But for me, it's always been about building a thing, making a system. This doesn't change that. For someone who is truly a craftsman, like a master woodworker, if you're no longer doing the joinery, that's going to feel worse.

I don't have a good answer for how to make that transition easy. It's just going to take people some time. There's always going to be a place for the craft of writing software. The misconception is that this is vibe coding with spaghetti everywhere. If I've ever sat down to write code without a mental model of what I was going to write, the thing that came out was never good.

Whether an LLM was helping or I was writing it by hand, I have to know what the outcome is supposed to look like. That doesn't change. **Emma Webb:** Is the goal of building the software factory to create code output indistinguishable from what a software craftsperson would produce? Is that possible? **Chris Kelly:** I think it's possible.

I don't think we've figured it out yet. It takes a lot of work to get an LLM to produce the kind of code you want. We've always written software differently. If you were writing a PR and I was writing a PR for the same functionality, we'd end up with different results. You have to get comfortable with: it doesn't have to write code exactly like me, but it does have to write code with the principles I want in order to make good software.

What gets overlooked is that good software design is actually better for agents anyway. The more spaghetti code you have, the more the agents get confused and grind to a halt. **Emma Webb:** You're building a software factory right now with our new product, Cosmos. What was the inspiration? **Chris Kelly:** It's been about a year.

I was thinking about closed loops of software development. My prior company was in incident response and we thought a lot about what happens after code gets to production and how to get those learnings back into the system. Abstract that a little and you think: isn't all software just a big loop? If agents can reason about each of the seams between our systems, from writing code to a PR to a build system to production to an incident, and I can put something with reasoning power at each of those seams, I can start to get a closed loop of software development.

Why wouldn't an exception thrown in production automatically open a ticket? If I've opened a ticket, why can't an agent tackle it? If an agent can tackle it, it can review it, deploy it to a canary, and if the monitors are working, roll it out to 100% of production. We're already doing all of that manually. The shift that happened from June to December of last year was that the reasoning capabilities of agents really changed.

Once the model can reason, you feel a lot more comfortable putting it into those seams. This isn't actually new. It's just fulfilling the original promise. **Emma Webb:** Are there core principles guiding how you're building Cosmos? **Chris Kelly:** We know models will get better. So we're always leaning a little over our skis.

We design it to do more than it can today, even if it's only hitting 50% right now. In six months that's going to jump to 80 or 90 or 100%. The other core principle is letting the agents lead. The previous generation of AI was: send a prompt, get code, send another prompt, get more code. That's the faster horse again. Now we want agents making decisions, monitoring the system, keeping track of what needs to happen.

You feed agents inputs, bug reports, feedback, product priorities, and the agent prioritizes the work, creates tickets, completes them, verifies them. When it doesn't make the right decision, your job is to teach it how to make a better one. Lastly, we want everything in the system to be managed by agents. If I want a weekly report of the most reported feedback issues, I just tell an agent to do that.

I end up with a fleet of agents doing work and I'm training them to do the job better. That doesn't feel threatening to me. There's always going to be an opportunity to teach software how to do software better. **Emma Webb:** One of the principles is that models will keep advancing, so you're not tying architecture decisions to what models can do today.

Can you give an example of how you've kept it flexible? **Chris Kelly:** Different models have different strengths. We make sure we can utilize every model from any frontier lab for different tasks. GPT 5.5 is great for code review. Opus is great for code writing. Haiku is perfectly fine for small tasks that don't need high reasoning, which helps control costs.

We don't know what's going to emerge out of the next round, so we have to keep the software flexible. We could have built a webhook that runs a script system. We decided not to. We want the agent to manage its own subscriptions to events rather than building a traditional if-then with AI sprinkled in. That flexibility lets us capture whatever capabilities the next models bring.

That's been tough as someone who spent a career building deterministic software. I want software to run the same way every single time. Getting over that has been a challenge. **Emma Webb:** How do you get past that mental shift? **Chris Kelly:** Guardrails. We've always had guardrails, test suites, linting, alerting. In non-deterministic systems, every chance an agent has to go left or right, it could go either way.

String too many of those together without a verification step and you might end up making a U-turn. So I design my agents to have a verification system after each task. Verify, hand off, verify. You get a much straighter line. It's not perfect, but you're helping the agents correct themselves. **Emma Webb:** Where's the IDE in Cosmos?

**Chris Kelly:** Some would say the IDE is dead. I'd say it's not a surface that serves the purpose we need anymore. It was great when I was handwriting code, even when agents were just generating code faster. But now I need multiple agents running simultaneously. Juggling that in an IDE is challenging. IDEs are trying to flip their UX to be agent-first, but that's a lot of legacy inertia to overcome.

Maybe just let it go and think about what the new interfaces should be. The bigger problem is that a lot of the work doesn't even start with me prompting anything. If an agent is running a weekly report and automatically starting a session, the agent decided what to build, started building it, verified the build, deployed to a preview.

At no point did I need an IDE. The work is handled start to finish by an agent system. We spent years arguing about light modes and dark modes, tabs and spaces. All of that can go away. **Emma Webb:** Teams that have adopted AI have done so very unevenly. You might have one engineer burning 500,000 tokens a month and another burning five.

How do you think about leveling the playing field across an organization? **Chris Kelly:** There are two things. First, the system. A lot of organizations think they're using AI because they've adopted a CLI tool for code generation. That's still the faster horse. That's not what an AI native engineering organization looks like.

AI native means not just the code production side, but code review, deployment systems, alert responses. You have to think through the whole new SDLC. Second, organizational adoption. Not everyone adopts tools at the same rate, and that's always been true. By building Cosmos with teams in mind, if I've developed a great solution, I can share it and put it into production for the whole team.

Someone joining the org gets all of the AI nativeness for free just by joining and using the tools already in place. The agents are there, the secrets are shared, the MCP servers are already connected. One person sets it up and the whole organization levels up. You can't do either of those things in isolation. **Emma Webb:** It's like if you have a faster horse, you still have to learn to ride.

Or you could just get in the car. **Chris Kelly:** Exactly. We can keep finding faster horses, but what we actually want is to be driving a car. We still want to go fast. How we go fast just has to change. **Emma Webb:** I don't think I realized until this conversation how difficult the job of an engineering leader is right now.

It's not just about accomplishing business goals. You have to rethink everything from scratch. **Chris Kelly:** It's organizational change, technical change, and keeping the lights on for your customers, all at the same time. That's excruciatingly hard. I think community is going to be the way through it. Sharing best practices, going to dinners and conferences, learning from one another.

Engineering leaders have navigated major shifts before and we'll do it again. But this is both technical and organizational change simultaneously, while also leading your engineers with empathy through losing something they love. It's a lot.