Why your AI coding tool is probably making you slower
A cynical look at Copilot, Cursor, and the reality of high-throughput engineering.
By git11 Engineering · Thu Mar 05 2026 · 7 min read
Most engineering blogs are lies written by marketing teams. This isn’t that.
At git11, we spend all day analyzing how developers actually interact with their repos. We see the commits, the refactors, and the messy reverts when a LLM hallucinates a library that doesn't exist.
I’ve spent the last six months rotating between GitHub Copilot, Cursor, and raw Claude 3.5 Sonnet to see which one actually reduces my time to PR. Most of them don't. They just change where the bottleneck is.
The Copilot Problem: Autocomplete is a distraction
GitHub Copilot is the incumbent. It's safe. Your IT department already approved it. It’s also fundamentally built on an outdated premise: that ghost-text autocomplete is the optimal UI for AI.
It isn't. Autocomplete forces you to stay in 'micro-manager mode.' You’re constantly evaluating small snippets of code every three seconds.
This kills your flow. You stop thinking about the architecture of your payment_processor.go and start debating whether the AI’s suggested variable name idx is better than i.
Copilot’s multi-file context is still surprisingly poor. If you have a deep dependency chain—say, a React component calling a hook that calls a utility function in a separate package—Copilot often loses the thread.
It’s good for boilerplate. It’s great for writing unit tests where the pattern is obvious. For actual feature logic? It’s a glorified snippet manager.
Cursor and the IDE-as-the-Model
Cursor is the only tool that feels like it was built by people who actually write code for a living. By forking VS Code, they solved the context problem that plugins can't.
Indexing is the differentiator. When I hit Cmd+K and ask for a refactor, Cursor knows about my .env.example and my obscure InternalService class because it’s indexed the entire local graph.
Use the '@' symbol. This is the UI pattern everyone else is going to steal. Explicitly tagging @Files or @Codebase stops the AI from guessing.
However, Cursor has a major flaw: it makes you lazy. Because it's so easy to generate 50 lines of code, you stop reading them.
I’ve seen junior devs merge massive blocks of 'working' code that contain logic bombs because they didn't want to audit the AI. Cursor is a power tool. If you don't know how to use it, you'll lose a finger.
The Context Window Myth
Every AI company brags about their context window. 200k tokens. 1 million tokens. It doesn't matter.
Large context windows are often just a graveyard for relevant data. Just because a model can fit your entire repo into its memory doesn't mean it understands the hierarchy.
We found that 'RAG' (Retrieval-Augmented Generation) based on high-quality AST parsing—like what we do at git11—is vastly superior to just dumping 50 files into a prompt.
If the tool doesn't understand the difference between a method definition and a method call, it’s just guessing. Don't fall for the 'Long Context' marketing. Focus on 'Relevant Context.'
Stop using Chat for debugging
Stop pasting stack traces into a chat sidebar. It’s a waste of time.
If you're using a tool that requires you to copy-paste from your terminal into a window, you've already lost. Use the inline terminal integration.
In Cursor, Cmd+Shift+L in the terminal to 'Fix with AI' is the only way to live. It reads the error, looks at the specific line in your file, and offers the diff.
If your AI tool doesn't have access to your local shell and your LSP, it's just a fancy version of StackOverflow from 2014.
The hidden cost of 'AI Generated' code
Here is a metric no one wants to talk about: Code Churn.
Since the rise of these tools, we've noticed a 20% increase in 'Fixup' commits. These are commits that happen within 60 minutes of a primary merge to fix a bug the AI introduced.
We’re writing code faster, but we’re also writing more garbage. You end up spending the time you 'saved' on debugging side effects you didn't see coming.
If you use an AI assistant to write a function, you are now the 100% owner of that code. If you can’t explain every line of the output, don't commit it. Period.
What actually works
If you want to be fast, use this stack:
- Use Cursor for the IDE. The Composer feature (
Cmd+I) is the best way to handle multi-file changes. 2. Use Claude 3.5 Sonnet as the underlying model.
GPT-4o is currently too wordy and fails at complex logic more often. 3. Turn off ghost-text autocomplete. It’s a cognitive tax you shouldn't pay. Trigger the AI manually when you actually need it.
Don't expect the tool to do the engineering. Expect it to do the typing.
Your job is still to think. The moment you let the AI think for you, your codebase starts its slow death crawl toward unmaintainable technical debt.