Abdul Baset Ghafoori

One thing that annoys me in software is when an action fails and the app gives you absolutely no useful information. "Something went wrong." Okay, but what? Did my session expire? Do I lack permission? Is the server unavailable? Good error messages aren't a small detail. They're part of the product.

Database migrations deserve more attention in code reviews. A bad function can usually be fixed with another commit. A bad migration can leave you dealing with broken data, failed deployments, and a rollback that isn't nearly as simple as you expected. I'd rather spend an extra hour reviewing the migration.

There's a big difference between: "Fix the authentication bug." And: "This endpoint returns 403 for an authenticated user. Trace the authorization check, explain why it fails, and identify the smallest safe fix before editing." Same AI model. Very different instructions. The second gives it boundaries instead of just a goal.

I don't mind AI agents making large changes when there's a good reason. What bothers me is a small bug fix turning into a rewrite of unrelated files. Sometimes the smaller patch is the more thoughtful solution. How are you reviewing the scope of agent-generated changes?

Before merging an AI generated refactor, check four things: - What behavior actually changed? - Did it touch files outside the original scope? - Which tests cover the change? - Could the same result be achieved with fewer edits? A passing test suite is important. It doesn't automatically mean the refactor was a good idea.

Been using @t3dotcodes for over a month and I can't stop shipping the experience makes the flow way enjoyable. @theo One of my favorite updates is the context compaction which is really nice to have when you work on a 500k line codebase, and AI like to drift.

I maintain a codebase with over 500k lines. One thing I've learned is that giving an AI agent more code doesn't necessarily give it better context. A failing test, the relevant files, and a clear description of what should happen are usually far more useful than dumping half the repository into a prompt.

We had two reasonable ways to structure a feature. Here's the tradeoff that mattered more than the framework choice. With AI framework is solved.

I trust AI agents for small, well scoped fixes more than broad refactors. Curious how other teams handle that boundary

Open source stuff is a blessing for Devs, if you are smart enough you'll save a lot of money with it.

When you're working in a 500k line codebase, a cleaner looking refactor can create more work than it saves. Especially with AI agents. They'll happily rewrite six files to fix something that needed ten lines. Before accepting a change, I look at how much existing code it touches. Sometimes the best engineering decision is leaving the rest alone.

The hardest part of maintaining a large codebase isn't writing new code. It's knowing which existing behavior you can safely change.

An AI coding model can feel faster while making you slower. Getting a response in 10 seconds means nothing if you spend the next 20 minutes fixing it. For the next few coding tasks, measure the time to a working result, not just the time to the first response. That's the speed that actually matters.

Before paying for another AI subscription, test the free model on the tasks you actually do. Not a benchmark. Your own code, your own debugging problems, your own workflow. The expensive model might still win, but at least you'll know what you're paying for. Run the same five tasks on both before renewing.

One thing I've noticed with AI coding tools is how easy it is to accept a solution just because it works. But working code isn't always good code. You still need to ask whether it fits the existing architecture, whether it's maintainable, and whether the complexity is actually necessary. That's where experience matters.

I've started appreciating boring code a lot more. Not every problem needs another abstraction or a clever design pattern. If someone can open a file six months later and understand what's happening without digging through half the codebase, that's good engineering.

TypeScript should make a codebase easier to understand. If a simple data structure needs five generic helpers and a long explanation, something has probably gone wrong. Sometimes a boring, straightforward type is exactly what you need.

This would be a game changer. One thing that I liked about using AI with a frameworks like Laravel once in a while is the structure is really easy for AI to understand and work with, since there aren't a million ways to structure it like next or react.

One thing worth being careful about in Next.js is where your code runs. Keep database access and secrets on the server. Pass client components only the data they actually need. It's a simple boundary, but it prevents a lot of unnecessary complexity.

I think one of the most underrated things in software engineering is knowing what not to change. Especially now with AI coding agents. It's easy to generate a lot of code, but that doesn't always mean you're making things better. Sometimes the best fix is just a few lines.