In Introducing Dap, @bilby91 described how Crunchloop started using AI agents in real delivery work—and how the results were uneven. What he didn't describe was what happened next: the part where we sat down to figure out why.
Two tracks, one question
At the end of 2025, we split into two lines of investigation. The first was internal: how are our engineers actually using AI tools? What do they prefer? What do they need? What do they avoid? The second was external: how do these tools actually work? What decisions are they making under the hood? What are the real capabilities versus the marketing claims?
Both tracks pointed at the same underlying question: where does AI actually help, and where does it create the illusion of help?
We read papers. We tested tools. We mapped workflows. We compared notes. And at some point, we noticed something: the research kept generating more research. Every answer opened three more questions. We were getting smarter about the landscape without getting closer to a product.
The decision to build
We didn't stop researching. We started building alongside it.
The GitHub UX/UI interface wasn't born from a finished strategy. It came from recognizing that abstract thinking, past a certain point, produces abstract answers. We needed something concrete—a surface to push against. Not because we had the right design, but because having any design forces the questions that matter: does this flow make sense for the people who'll use it? Does this architecture hold when we push on it? What breaks?
Building generated better questions than thinking. That was the shift.
The speed nobody planned for
Here's what we weren't ready for: when engineers who deeply understand their craft start building with AI, the output isn't incrementally faster. It's a different order of magnitude.
Features that would have taken a week materialized in a day. Code that needed careful architecture emerged in hours. The time-to-market on individual pieces shrank in ways our processes couldn't absorb.
This wasn't AI doing the work. This was prepared people using AI as leverage—and the combination producing at a speed the team wasn't organized for.
@ivanetchart wrote about The Debt We Didn't See Coming—the codebase evolving faster than the team's understanding of it. We experienced the organizational version. The code wasn't the problem. The coordination was. Everything we relied on to stay aligned—standups, task boards, review cycles—was designed for a pace that no longer existed.
What it actually felt like
It wasn't chaos. Nobody was stepping on each other's work or building the wrong thing. The code was good. The features worked.
The disorientation was subtler. You'd finish a task and find that three other things had moved while you were heads-down. You'd start a review and realize the context had shifted since the PR was opened. The gap between "I know what the team is doing" and reality kept widening—not because anyone was doing anything wrong, but because everyone was moving fast.
@darrillaga wrote about The Signal Under the Noise—the individual version of this gap, where people produce faster than they understand. This was the team version. We were shipping faster than we could synchronize.
Finding our footing
We're not going to pretend we've solved this. But we've found footing.
The answer wasn't inventing something new. It was going back to the fundamentals of project organization—and being disciplined about them.
A board that makes work visible. Not as a formality—as the single source of truth for what everyone is doing, right now. When the pace is this fast, opacity kills coordination before anyone notices.
A roadmap that connects daily work to outcomes. What are we trying to achieve, by when, and how does each piece converge? Without that, speed just means arriving faster at a destination nobody agreed on.
Daily catchups focused on communication, not status updates. The goal isn't "what did you do yesterday." It's opening the space to explain the what and the why—so that when someone finishes a task, the rest of the team understands not just that it's done, but where it fits.
None of this is revolutionary. That's the point. The tools didn't change. The discipline required to use them did. When everything moves faster, the basics aren't optional anymore. They're the only thing that holds.
What we're sitting with
In the right hands, AI gives teams the speed to grow the business and deliver value in timelines that weren't possible before. But speed without organization isn't an advantage—it's a risk.
The team has to be ready for it first. Not just technically. Structurally. The processes, the communication, the shared understanding of where everything is going.
And then there's measurement. When the pace changes this much, the old ways of tracking progress stop meaning what they used to. A feature shipped per sprint meant something when sprints were the bottleneck. Now the bottleneck is elsewhere—coordination, coherence, quality of decisions—and we need metrics that reflect that. We're still figuring out what those look like.
Our job is to make sure we're building toward teams that grow fast with AI and deliver value as fast as the tools allow. Organization first, then speed. Measurement that matches the new reality. That's the path we're on.