DEV Community: Speedcraft Lab

Why I Stopped Using Copilot and Won’t Be Going Back

Speedcraft Lab — Mon, 20 Apr 2026 03:00:00 +0000

What actually changes when your AI assistant can see your entire codebase instead of just the file you’re editing.

Why I Stopped Using Copilot and Won’t Be Going Back

What actually changes when your AI assistant can see your entire codebase instead of just the file you’re editing.

The moment your assistant can ‘see the repo’, you stop rewriting the prompt

You paste the error. Copilot fixes it. You switch files, and it immediately forgets everything you just discussed. So you paste the context again. Now it suggests a pattern that contradicts what you built yesterday. You paste more context. At this point, you’re a prompt engineer first and a developer second.

The AI is working with fragments. It can see the file you’re in, maybe a few open tabs, but it has no idea how your codebase actually fits together.

Every dev hits this wall once a repo passes twenty or thirty files. The tool that felt magical on day one starts feeling like a very fast intern who skipped the onboarding docs and keeps asking you to re explain things you already covered.

By the end of this, you’ll understand why full codebase context changes everything, and how to figure out whether switching tools is worth the hassle for your specific situation.

Where Autocomplete Hits a Ceiling

GitHub Copilot is genuinely impressive for what it does. Line completions, function suggestions, boilerplate generation. For brand new projects or single file scripts, it’s fast and often surprisingly correct.

But here’s where it falls apart. You’re working in a mature codebase. You have established patterns. Naming conventions. A specific way you handle errors, structure services, organize imports. Copilot doesn’t know any of that. It’s guessing based on GitHub’s average code, not your team’s specific reality.

So it suggests a function signature that technically works but violates your team’s conventions. It autocompletes an import from a package you deprecated six months ago. It writes a database query using an ORM pattern you explicitly moved away from.

You can paste context manually, but doing it for every single query breaks your flow. You paste your types, your interfaces, your related files. Then you switch to another file and do it again. And again.

The chat sidebar model treats context as something you provide on demand, message by message. That works for isolated questions. It doesn’t work for sustained coding across a real project. The mental tax of constantly teaching the AI your project structure becomes its own task, running parallel to the actual work you’re trying to do.

What Happens When the AI Can Actually See Your Project

Tools like Cursor and Windsurf take a different approach. They index your entire codebase upfront. When you ask a question or request a change, the AI can search across all your files, understand your project structure, see how everything connects.

You ask for a new API endpoint. Instead of suggesting generic patterns from its training data, the AI looks at your existing endpoints. It matches your naming conventions. Uses your established error handling. Imports from the right places. It’s not guessing what a good endpoint looks like in general. It’s seeing what your endpoints look like specifically.

Multi file editing is where this really shows up. You need to add a field to a data model. That change touches the schema, the API layer, the frontend types, maybe a migration file. With Copilot, you’d make each change manually, maybe asking for help file by file. With Cursor’s Composer mode, you describe the change once and it proposes edits across all the relevant files simultaneously.

I watched a colleague add a new feature flag system last month. Described what they wanted, Composer identified seven files that needed changes, proposed coordinated edits to all of them. It hallucinated two imports, but the structural changes were spot on. Saved probably an hour of mechanical file hopping.

I didn’t expect the relief to feel so immediate. The first time I asked a question and the AI already knew my project structure without me explaining anything, something shifted. Less friction. Less babysitting. More actual thinking about the problem.

The Parts That Aren’t Smooth

The switch comes with heavy trade offs.

Indexing takes time. On a large codebase, initial indexing can run twenty minutes or more. Updates are faster, but you’re still waiting in ways you didn’t wait before. If you pull down repos constantly and want to start coding immediately, this will annoy you.

Privacy gets complicated. Your entire codebase is being processed, potentially sent to external servers depending on your configuration. For proprietary code, this matters. Some teams can’t use these tools at all for compliance reasons. Others run local models at significant performance cost. Neither option is free.

The learning curve surprised me. Composer mode is powerful, but you need to develop a skill for prompting it effectively. Vague requests produce vague results. You end up learning how to describe changes with precision, which is useful but takes time to build.

And sometimes the full context actually makes things worse. The AI sees everything. Including your legacy code. Your workarounds. Your “temporary” hacks from eighteen months ago that somehow became permanent. It might replicate patterns you were trying to move away from.

If you’re working on small projects, mostly solo, writing relatively isolated code, you might not need any of this. Copilot’s simplicity could be an advantage. Not every problem requires the heaviest tool.

How to Know If It’s Worth Switching

If you lose an hour a week to fixing wrong imports and re explaining context, switch tools. If you’re mostly writing new code in small projects, stay where you are. Seriously.

But if you’re maintaining a growing codebase with established patterns, tools that actually see your whole project pay for themselves within a week.

Here’s a simple way to test it. Take a task that touches three or more files. Try it with your current setup, noting every time you manually provide context or correct a suggestion that ignored your conventions. Then try the same type of task in Cursor with indexing enabled.

The difference isn’t always dramatic. But when it clicks, when the AI suggests exactly the pattern you would have written because it actually learned your codebase, the shift is hard to walk back from.

What’s the most time you’ve lost to an AI suggestion that completely ignored something obvious in your project?

Follow for more on the dev tools worth your time.

3 Lines of SQL Wiped Our Entire AWS Database

Speedcraft Lab — Sun, 19 Apr 2026 05:53:35 +0000

Every backend team has this script sitting in their repo right now. Most will not find it until it is too late.

3 Lines of SQL Wiped Our Entire AWS Database

Every backend team has this script sitting in their repo right now. Most will not find it until it is too late.

Row count: 0. Not slow. Not degraded. Zero. The compiler had no errors. Neither did the database.

The Deploy That Couldn’t Go Wrong

The Slack notification wasn’t a monitoring alert. Not a PagerDuty page. Just our CTO, typing in all lowercase, which was somehow worse: “hey can someone check the users table? something looks off.”

I unlocked my phone and opened the AWS RDS console. The row count for our primary users table loaded: 0. Not degraded. Not slow. Zero rows. I scrolled up to make sure I was looking at production. I was.

Hours earlier, I had run what our ticket called a “low-risk schema cleanup.”

The Confidence That Made It Possible

The migration was small. Three lines of SQL to remove a deprecated legacy_auth column we hadn't touched in two years. I had run it in staging. It passed. I reviewed the script twice. We were days from a board demo, and the task felt like housekeeping.

I thought I understood database migrations. I did not.

The WHERE Clause That Wasn’t There

Here is what the migration script was supposed to execute:

DELETE FROM user_sessions WHERE session_type = 'legacy_auth';

Here is what it actually contained:

DELETE FROM user_sessions;

That’s not even the worst part. Our user_sessions table had a foreign key with ON DELETE CASCADE pointing back to users. Which meant when every session row vanished, the cascade tore through the parent table without a single error message. No constraint violation. No alarm. Just silence and a shrinking row count.

I stared at the script for a long time before I understood what I was reading.

The WHERE clause existed in the version I had reviewed. Somewhere between that review and the final execution, I had opened the wrong file. A near-identical filename: migration_cleanup_v2.sql versus migration_cleanup_v2_FINAL.sql. An older draft. A copy I made two weeks earlier when I first scoped the task, then abandoned in favour of the revised version, then apparently reopened by accident when I was in a hurry to ship.

Our DBA pulled the binary logs. The DELETE had executed cleanly, cascade operations completed without error, and I had already closed my laptop and driven home before anyone noticed. Nobody saw it until hours later.

“How long to restore?” our CTO asked on the call.

Nobody answered immediately.

The Silence After

The Slack channel filled up in about four minutes. Our head of support posted first: customers were reporting login failures across the board. Then our backend lead: “RDS looks healthy, no errors but the tables are empty.” Then the CTO, just: “call?”

We had a snapshot policy on RDS. The most recent snapshot existed. But our retention policy had been silently failing for six weeks due to an IAM permission scoping issue nobody had caught. The last valid, restorable snapshot was eleven days old.

What a Missing WHERE Clause Actually Costs

A DELETE without a WHERE clause is not a typo. It is a category of mistake one that results from treating a migration script as a throwaway file rather than as production code subject to the same scrutiny as application logic.

The analogy that stuck with our team: a migration script is not a sticky note. It is a signed contract. You would not countersign a contract without reading every clause. You should not run a migration without diffing the exact file you are executing against your reviewed version not the filename, the actual content.

The structural fix we adopted:

-- Step 1: Run the SELECT equivalent first, confirm affected row count  
SELECT COUNT(*) FROM user_sessions WHERE session_type = 'legacy_auth';  
-- Expected: 4,203. If the number surprises you, stop here.


-- Step 2: Wrap the DELETE in a transaction and verify before committing  
BEGIN;  
DELETE FROM user_sessions WHERE session_type = 'legacy_auth';  
-- Verify: total remaining rows = original count minus expected deletes  
SELECT COUNT(*) FROM user_sessions;  
COMMIT; -- Only after the number matches your expectation

The trade-off worth naming: this pattern requires a human in the loop and does not scale cleanly into automated pipelines. For continuous delivery environments, you want row-count assertions baked into your migration framework as hard failure conditions not as comments in a script that a tired engineer might skip under pressure.

We recovered from the eleven-day-old snapshot in approximately 11 hours, cross-referencing application logs to reconstruct the most recent writes. We recovered most of the data. Not all of it. The board demo moved by one week.

The Next Migration You Run

Before you push your next migration to production, open the exact file you are about to execute — not a reviewed copy, the actual file run the equivalent SELECT for every DELETE or UPDATE it contains, and confirm the affected row count matches what you expected before you proceed. If the number looks wrong, even slightly, treat that discrepancy as a blocker and do not move forward until you have a clear explanation. The sentence you should use in your next PR review or post-mortem: “We need a verified row-count assertion before any destructive migration touches production.”

The Console Tab That’s Still Open

I still have the AWS RDS console bookmarked at the path it was on when I first saw that row count.

Sometimes I open it not to check anything but to remember what zero looks like in a field where three years of users used to be. The script was three lines. The WHERE clause was eleven characters. The recovery was 11 hours. The difference between a clean deploy and a disaster was a filename.

Have you hit this and what did you do differently the next time?

If this resonated, you might also find Why Your Migration Strategy Is Only as Strong as Your Snapshot Policy useful it covers how silent backup failures and database migrations combine to turn recoverable mistakes into all-hands incidents. I’m writing a series on production failure patterns and the concrete process changes that followed each one follow along so you don’t miss the next one. If you want these delivered to your inbox, you can subscribe below.

Follow me for more such content.

The 10-Minute Rule: Why Freelancers Who Track Time in Real-Time Earn 23% More

Speedcraft Lab — Sun, 05 Apr 2026 15:46:04 +0000

The Problem Nobody Talks About

Every freelancer has been there. Friday evening, staring at a blank timesheet, trying to remember what you did on Tuesday morning.

You guess. You round down. And just like that, 3-4 billable hours vanish into thin air. Every. Single. Week.

Over a year, that is roughly 150+ hours of unbilled work. At $100/hr, that is $15,000 left on the table.

The 10-Minute Rule

Here is a dead-simple productivity hack that changed how I bill:

Every time you switch tasks, take 10 seconds to log what you just finished.

Not at the end of the day. Not on Friday. Right now, in the moment.

Why does this work?

Context is fresh - You know exactly what you did and how long it took
No guilt rounding - When you log in real-time, you capture the true duration
Pattern recognition - After a week, you see where your time actually goes

What I Use

I built FillTheTimesheet specifically for this workflow - quick entries, project tagging, and zero friction so logging does not break your flow.

But honestly, even a simple note in your phone beats Friday-evening guesswork.

The Debugging Parallel

This reminds me of something I wrote about recently - I lost 30% of UDP packets in production and only caught it because I had real-time monitoring. Same principle applies to your time: if you are not measuring it live, you are losing it.

Key Takeaway

Stop reconstructing your week from memory. Track in real-time, bill accurately, earn what you deserve.

What is your time tracking strategy? Drop a comment - I would love to hear what works for you.