When AI Makes Us Slower—And Why That Can Actually Help

Late July just handed us a curveball. Even when expectations ran high, open-source maintainers using Claude 3.5 and Cursor Pro took 19% longer with AI—AI actually made them slower. That wasn’t the plan. Folks were ready to move 24% faster, but instead wound up with more minutes on the clock. Hype met cold reality. The mismatch is staring us right in the face.

As someone who uses AI daily to build real things, this result gave me pause. I can’t count how many times I’ve told myself, “This is going to save me an afternoon.” But the gap between what I expect and what actually happens is bigger than I want to admit.

There’s pressure everywhere to prove instant speedups—bosses, product teams, even your own internal stopwatch. It’s tempting to grab a shiny model and hope for rocket fuel. If minutes per task tick up, it feels like you’re moving backwards. But let’s talk nuance, not panic. The real question isn’t how fast we finish a single ticket; it’s what happens to our throughput and rework rate in the weeks after. Are we aiming to improve decision quality with AI so the systems actually hold up, or just putting out fires faster?

Sometimes, slower is smarter.

Where AI Actually Shines: Improve Decision Quality With AI by Front-Loading Clarity for Durability

These days, I don’t just use AI to fill in blanks or rush through work. I treat it like an architectural partner. It’s here, first and foremost, to help me improve decision quality with AI before any code gets shipped. If you just fire off a request and hope for a perfect answer, you’re missing what AI does best. The biggest shifts come when you bring it into the design phase—setting up your system’s structure, spelling out real context, and using the feedback to poke holes in your plans before anyone else does. It’s not glamorous, but when I lean into this approach, I end up avoiding big headaches down the line.

Here’s where that setup work comes in. I spend real minutes—sometimes hours—crafting prompts, building out context docs, wiring up the right interface between my intent and what the AI spits back. On the surface, it feels like busywork, or like I’m wasting time getting nowhere. But it’s like laying out the blueprints for a building instead of just stacking bricks as you go.

That upfront drag only looks slow until you reach the part where everyone else starts tearing up faulty foundations. When my initial context is sharp and the structure is stress-tested early, I see fewer surprises in PR review, cleaner interfaces between modules, and way less arguing about what the spec was supposed to say. In my own work, every minute spent early pays off triple later—I’ve cut rework on major features simply by sweating those initial details with the AI, long before real code hits production.

I used to think setup time was just the price of using smart tools. Now, I see it as the actual enabler—the thing protecting me from hours of clean-up down the road.

Not every slowdown is wasted effort. Sometimes it’s the cost of building something that holds up over time, not just for today’s task.

Here’s the compounding effect in a nutshell: early clarity driven by AI means fewer reversals, cleaner interfaces, and noticeably less PR churn in the weeks that follow. Most engineers rarely use AI’s raw outputs straight—just 2-4% do, while 9-19% refine what they get before shipping (source). The real value comes from iterating and reducing later rework. That time you “lose” up front? You claw it all back—and then some—when you aren’t stuck fixing the same bugs twice.

Bottom line—shift how you measure success. Don’t just count minutes per ticket. Track the rework you avoid and the clarity you compound for the next sprint. That’s where AI actually moves the needle.

Turning Assumptions Into Durable Velocity

Whenever I start a new feature or hunt for a path through legacy code, I kick things off with what I call an assumptions-and-inputs pass—using AI not to guess the solution, but to grill me on what’s missing before a single function gets touched. I’ll drop rough specs, squishy requirements, and let the AI poke at edge cases I hadn’t named. It’s like having a colleague who’s good at catching what you’ve glossed over. You end up turning ambiguity into explicit interfaces and constraints.

This step can feel unreasonably slow when everyone wants you shipping code tomorrow. But it surfaces friction early, exposes blind spots, and tightens system seams so there’s less rework down the line. If you get in the habit of letting AI challenge your plan up front, you won’t spend nights unwinding misaligned modules or chasing vague bugs later. I talk to it as if it’s my team’s sharpest reviewer, not a code monkey—prompting for what could go wrong, not what should go right.

Next, I put together a context pack—glossaries to nail down terminology, a repo map for architectural boundaries, a list of non-goals to prevent scope creep, and prompt templates that encode my actual intent and constraints—all to support AI for architectural decisions. It’s preemptive prompt tuning. You’re setting clear boundaries so the AI works inside your domain, not some fantasy project.

This pre-sorting reminds me of grinding beans and prepping the filter before you even hit brew on the coffee maker. It always feels slower. You just want caffeine in your cup, not another step at 7 a.m. But assembly gets smoother when every part’s lined up. Same goes for AI workflows. When I build embedding indices and lean on smarter retrieval—like using learned estimators for short-form work—everything snaps together faster. Smarter retrieval with learned estimators—like TA-ARE—cuts redundant fetches by 14.9% in short-form work, much like efficient pre-sorting saves time when assembling. It’s the step that’s easy to skip. If you do, you’re inviting extra cycle time and more “where did I put that?” moments.

If you’re watching the clock for the first few days, it can feel all uphill. But the next few weeks play out differently. The slowdown compounds not into wasted time, but into reliable speed. That’s the horizon to commit to if you want your AI strategy to actually stick.

Addressing Objections: Moving Past Risk and Friction

I’ll be straight with you—I still worry about looking slow when I front-load context. There’s this nagging voice in my head that says, “Everyone’s going to see how long you spent setting up, and wonder why you didn’t just bang out the feature.” It’s real. Even in code review, I second-guess myself when I submit a beefy context doc alongside what looks like a basic ticket fix. But every time I short-cut the prep, I pay for it later with fire drills. So yes, upfront work does make you visible, and that can feel risky.

If you want meaningful metrics, track more than immediate ticket speed. Set a longer measurement window—two or three sprints—so you see the actual impact on rework, not just how fast the first draft lands. Make sure the team understands what you’re testing. Framing the goal as reduced churn helps reframe the conversation, so the pressure is about throughput, not minutes.

Minimizing the setup tax starts with tool selection and team habits. Pick tools that plug into your workflow cleanly—Cursor Pro, Claude 3.5—and build out a set of standard context templates. Once the team anchors rituals around reusing scaffolds, that upfront sweat quickly gets distributed and shrinks overall effort.

If you’re unsure where to start, go for greenfield builds, new services, or “no one’s attached yet” integrations. The payoff from clean context work is obvious when you aren’t untangling legacy spaghetti. Every setup minute counts double and your wins show up fast. This way, payoff and learning are both visible, without risking the mainline.

I know this, and I still struggle to ignore the stopwatch when someone pings me about delivery.

Contrasting Contexts: Rolling Out AI for Real Throughput

Last month, I helped launch a greenfield service—brand-new repo, no legacy headaches. We kicked off with a full day set aside just for framing. Not coding, not writing docs, but mapping goals and leaning into AI-assisted system design—putting together system diagrams and stress testing interface boundaries side by side with AI. I won’t lie. It felt like overkill at the time. By hour three, you start itching to push code.

But that upfront grind paid off fast. We caught spec mismatches before they left the whiteboard, tuned our API for clarity and flexibility, and prepopulated prompt packs so the AI stuck to our actual context. In the weeks that followed, it was uncanny how much smoother everything rolled. Fewer “wait, what did you mean here?” reversals, less PR friction, almost zero builds getting patched post-facto. When things did break, everyone knew exactly where to look. Greenfield is a gift for front-loading—each context hour cut days of rework and our feature cadence never got bogged down in surprise pivots or messy retrofits.

Contrast that with a mature repo, where history is half the battle. One engineer I work with has years of codebase knowledge. For them, layering AI into daily workflow barely nudged speed. They mostly used it for documenting edge cases and quick validation experiments. Legacy context meant the design friction was already ironed out. The real gain was in recording tribal knowledge, not sprinting past blockers.

The commitment isn’t to being “faster right now”—it’s to using AI for better decisions that stack up over time. I still believe it’s smarter in the long run.