AI in practice

The unease that made me rebuild how we work in tech

The unease that made me rebuild how we work in tech

This is the start of a series. I’m going to tell the shift we started in Prolog’s tech about two months ago: why it started, what’s working, and what cost us. It’s not stage theory. It’s what we lived.

I decided to write for a simple reason: when I went looking for how to do this, I found a lot of opinion and very little honest account from someone in the middle of it. If this text becomes a place for another builder to lean on, it was worth it.

It started with a quiet unease.

What I saw

In March, Jean, my co-founder, and I went to SXSW, in Texas, one of the biggest innovation festivals in the world. I came back different, and the unease didn’t go away. It wasn’t what I’d seen on stage. It was what I saw companies already doing in practice.

Back home, I dove into the technical content of people actually building with AI out there. Not the lukewarm Instagram and LinkedIn kind. The deep one, from people with their hands on it who publish what they learned. And I kept running into case after case of companies that had truly changed the way they work. The difference is subtle and huge at the same time: they didn’t “start using AI”, they put AI at the center.

And you can’t wave it off as stage hype. It’s industrial-scale adoption: big companies and small ones, everyone walking toward the same place. One thing that stuck with me was a simple number: 9 out of 10 Fortune 100 companies had already adopted Copilot. But the figure that matters isn’t adoption. It’s the size of the gain. The ones who just slotted AI into the old flow are reporting 10, 20% more productivity. The ones who rebuilt around it are reporting multiples: 5x, 10x. I’ll open up these cases one by one in the next articles. For now, what matters is the turn they all have in common.

AI on the side vs. AI at the center

This distinction sounds small and it decides everything.

Using AI is opening a tool on the side and following the same process as before. The flow stays the same, the roles stay the same, the review stays the same. AI is one more tab, and everyone figures it out alone with it. The gain shows up at the margin.

Putting it at the center is redesigning the process around it. You assume AI will build a good part of the work and you rebuild the flow, the roles and the review from that. Context stops dying inside a single conversation and becomes shared. The gain is a different order, because it isn’t the same work faster. It’s the work changing shape.

Diagram comparing AI on the side (10 to 20% gain) with AI at the center (a different order of gain)
AI on the side vs. AI at the center: the same work, two places for AI.

When that clicked, the question stopped being “which tool do we adopt” and became “what, in our way of working, was designed for a world without AI”. So I went to look inward.

The diagnosis: everyone figuring it out alone

Around the end of March, before we’d even moved to Claude, I sat down with people from product, design and engineering at Prolog and asked a simple question: how are you using AI day to day? What’s good, where does it jam, what bottleneck do you see in the operation.

What I heard got me.

Everyone used a different tool. One on Copilot, another on Claude, another threw everything into Prolog’s internal AI. And worse than the loose tool was the loose context: what one person built up talking to the AI died right there, with them. The maintenance team, for instance, had put together good material inside Prolog’s AI, with the rules of that product, except it never reached the tires team, who needed the same kind of context and started from zero.

One thing stuck in my head. The devs were avoiding AI to review a big PR, afraid of burning through their credits before the end of the week. Think about the absurdity: a person had to choose between finishing their own task with AI, which they’d committed to shipping, or spending that same credit reviewing a colleague’s giant PR. It became a fight over a scarce resource. And then nobody wants to take someone else’s review.

Someone on the team summed it up in a line I couldn’t get out of my head:

We produce with AI and review without AI.

Everyone figuring it out alone, their own way, with whatever tool they had. What worked for one didn’t become a recipe for the next. No standard, no common ground.

I'll email you whenever there's new writing. No spam.

And it wasn’t just the way, it was the structure

The more I looked, the clearer it got that I couldn’t fix this just by teaching everyone to “use it better”. The way of using was the symptom. The structure underneath was the thing that wasn’t ready. Three holes showed up.

First, context lived scattered. A piece in Notion, another in Drive, another in Jira, in Figma, in Fathom. There was no single source of truth. So every new conversation with the AI started by explaining everything from zero, because the information it needed was in five places and curated in none. We paid in tokens, in requests and in time just to reassemble context that already existed somewhere.

Second, the human was the glue. Someone in product generates a spec with AI, drops it in a doc, sends the link to the next person, who takes it and throws it into their own AI project. AI showed up at the ends, never in the middle: it produced a piece, a human carried the result by hand to the next tool, and another AI started over. The flow stayed human.

Third, the architecture. The base we built over ten years was made for a world where the bottleneck was the person, not the AI. It’s entangled in places and has parts with no tests, and that’s exactly what blocks the fast change AI would let us make. It’s nobody’s moral failing. It’s the buildup of ten years of decisions that worked until now. AI just laid it bare.

And it’s important to say: this isn’t a flaw in the team, or in Prolog. It’s what happens at any company that pasted AI on top of the old way of working. Every ten-year-old company carries a way of doing things that worked until now. AI shines a spotlight on it. And the responsibility to change it is mine.

Why rebuild everything, not just engineering

The first temptation is to fix it in engineering. It makes sense, it’s where AI landed fastest and where we already had a head start. But that’s exactly where the trap is.

If one area moves at AI speed and the one next to it stays at human speed, I haven’t sped up anything. I’ve just moved the bottleneck.

Think about the whole flow. If engineering starts shipping in hours but product still takes weeks to spec, the one holding up the line now is product. Fix product and engineering, but validation is still done by hand? It jams at validation. And it doesn’t stop at tech: if we put a lot out and marketing can’t announce it at the same pace, the bottleneck moves to marketing. Speeding up one stretch doesn’t undo the traffic jam. It just pushes it to the next one.

Two pipelines from product to marketing showing the bottleneck jumping from product to validation as each stage is accelerated
Speeding up one stretch just pushes the jam to the next.

So at the end of April, we started rebuilding all of tech. Product, design, data, quality. Not just engineering. If AI goes to the center, it goes to the center of the whole flow, not one piece.

What’s coming

In the next articles, I’ll open up each part of this. What a “harness” is, the infrastructure that makes AI actually deliver instead of just pitching in here and there. How the work of each role changes when AI becomes the one building, and the human becomes the one steering and reviewing. And why the right question when something breaks stopped being “what do I do now” and became “what was missing from the context so this doesn’t happen again”.

The shift is running, with hits and misses. I’ll tell you both here, as it happens. It’s not a recipe. It’s what we’re living. If it works as a map for someone else who builds, even better.

I'll email you whenever there's new writing. No spam.

Spam-protected.