The history & evolution of devtools from researchers in applied AI

Brandon Waselnuk

January 30, 2026

I sat down with Doug and Peter, two of our engineers at Unblocked, to talk about the arc of developer tools, from the Apple II to Claude Code, and the research that's shaping what comes next. We covered everything from why Doug has his terminal set to monochrome, to what happens when you accidentally teach an AI to agree with itself, to the experiment where we could see every window open on your machine.

Here's an overview of our conversation.

Dropped into BASIC

Doug started the conversation by dating himself. He was twelve years old when he got an Apple II C. You'd turn that thing on and it would drop you into BASIC.

"Welcome. And you were just there."

He couldn't remember if it was Apple's BASIC or Microsoft's. Turns out Microsoft had one of the best implementations, which is partly why Doug ended up working on developer tools at Microsoft years later.

Peter's entry point was different. He started at Blackberry when mobile was just taking off. They had their own internal IDE built specifically for that embedded platform. And the way knowledge got transferred?

"Hey, Doug. I'm having this problem. Have you experienced this before? Could you help me out here?"

That was it. That was the system.

The magic of hitting dot

Doug lit up when he talked about the first time he saw IntelliSense. You'd type an object name, hit dot, and there was a list of everything you could do with it.

"When I first saw that, my mind just exploded. This was clearly the future."

What made it work was surprisingly simple: just some metadata baked into the COM specification. But it changed everything about how developers interacted with code.

The other moment that blew people's minds was Visual Basic letting you modify runtime state. You could right-click on something in a running program, open a context window, change a value, and save it.

"Everybody's head just kind of blew up."

And when VB got embedded into Excel? Doug's pretty convinced most of the world still runs on Excel and VBA, even if Microsoft has moved on to the Power Platform.

Why we're back in the terminal

Here's the weird thing about 2025: the most advanced coding tools dropped us back into the command line.

Doug spends most of his time in Claude Code now. He's even got the monochrome look enabled.

"I feel like I'm on an Apple II. And if anybody walks by my machine, they actually see the monochrome, which they all laugh at me for. But those were my favorite days."

Peter explained how this happened. The Anthropic team had a CLI tool that was still rough, but people inside the company were using it to prep their work before implementing anything. Then it evolved into fully implementing things. They shipped it because people were getting maximum utility from it, not because CLI was the "right" paradigm.

"Sometimes people assume that the existing paradigms are the thing that works best for the new thing. And maybe not."

Doug's response: "Claude Code's not enough. Claude PC is what we need."

He wants the runtime together with the language, the documentation, the browser. What that actually looks like, nobody knows yet.

The dichotomies

Doug got philosophical—"not to get too philosophical," he said, before getting very philosophical.

Developer tools keep playing out these tensions: command line versus GUI. Design time versus runtime. Local versus remote. And now, inference time versus training time.

"Watching that sort of evolution happen over time and how they synthesize has been the most amazing thing to see."

Peter added that these paradigm shifts happen maybe once a decade. Mobile was one. It changed how people wrote software, not just the products themselves. Everyone had to think differently about network communication, interaction modes, everything.

This feels like another one of those shifts.

Swivel chair engineering

Doug brought up a term I hadn't heard: swivel chair engineering.

At Microsoft and in telecom, partners would have multiple monitors running different systems. They'd literally swivel between them to get their work done. Different tools, different contexts, no connection between them.

"You're seeing the same kinds of pains that happen there."

The dream is something that stitches it all together. Peter described it as going from "zero tooling at all, to gradually more tooling, to places to store institutional knowledge, to now: stitching together automation with generation of new content and surfacing all the things all at once."

Research: what we tried and threw away

I asked what research directions they're most excited about. Peter went first: memories and conflict resolution. What happens when one source says X is true and another says X is false? That's still an unsolved problem.

But the more interesting part was what they tried and abandoned.

Fine tuning: Early on, they looked at fine tuning models on organizational data. The conclusion?

"The juice was not worth the squeeze."

The compute cost didn't justify the uplift. It was far more important to nail the context narrowing at inference time.

Graph RAG: This was big about a year ago. You'd spend enormous time during ingestion building an ontology, then try to leverage it at inference. What they found was it was easier to build the ontology at runtime instead.

Plus there's a security problem nobody talks about enough:

"What happens if we drop that HR document containing everyone's pay data into the training? Whoops."

Self-referential answers: This one was my favorite. Early in the product, they captured Unblocked's answers and fed them back into the corpus. The thinking was: if Unblocked gave a good answer, future queries should benefit from it.

The problem?

"It converges all of Unblocked's answers to its past historical answers, even if they're wrong."

They threw it out.

The echo chamber problem

This led to a broader concern. There's a new CLI tool (Aider) that dynamically rewrites its own prompts based on how you interact with it. It learns your preferences.

I asked whether that could create echo chambers.

"If we dynamically rewrite prompts because you like VBA, Doug, it's gonna lean on that and then just start to basically ignore other data."

Engineers are curious people. They reach for new tools, try new things. Do you really want something that confines you to what you already know?

Peter's take: if you're going to do something like that, you need reinforcement learning features that let users correct the behavior. But that puts the burden on the customer. You're probably better off not taking that approach to start with.

Doug raised the meta-question: we've got AI doing code review because AI is writing code that needs to be reviewed more carefully. Now we might need AI to judge those reviews.

"So when does it stop?"

Peter compared it to the immune system. You spin up a sandbox, let the agent operate, see what it does. If it's trustworthy, you let it do more. If not, you don't.

"Will we let it out of the box? That's the question. And will it convince you to let it out of the box?"

Context is personal

One thing Peter emphasized: context isn't global. It's personal.

"You can't think of context as some sort of global thing that's the same for everyone."

What you work on, who you work with, what you've touched recently. That's how you filter signal from noise.

He expanded Unblocked's promise: "All the things you need, none of the things you don't—but also none of the things you shouldn't."

You might want to know something, but you don't get to know it. Security is baked into how context gets surfaced.

Local versus remote

Doug mentioned he has to rebuild his local machine at least once a week.

"Which is just a nightmare."

The research direction that excites him most is figuring out the local-global boundary. Your local commit tree that you haven't pushed yet—should you be able to reason about that alongside your org's global context? Absolutely.

Your M4 with 96 gigs of GPU memory—can it handle some workloads locally instead of hitting the cloud? Yes.

Peter noted they had an early experiment where Unblocked could see all the windows open on your machine and pull in that context.

"That was before we released it to customers," he clarified quickly. "It was an experiment. Safe in the box."

But imagine pulling main, something's broken, and there's a conversation happening somewhere that explains it. What if that was just at your fingertips?

Listen to the full conversation

This post covers some of the highlights, but the full conversation goes deeper into the paradigm shifts Doug has lived through, the research Peter is most excited about, and why they think everything's about to change again.

Give it a listen.

Unblocked is available now. Read our docs or reach out to see it in action on your codebase.