AI-assisted debugging, conversational debugging, incident triage, and edge case discovery

Let me save you some time upfront: I’m not going to tell you it changed my life.

A month ago, I wasn’t even looking for a new AI coding tool. I already had a workflow that worked. Claude.ai for code reviews, Axios for API calls, VS Code for everything else. Then I kept seeing developers talk about Claude Code — the terminal-based version, the one that reads your entire codebase automatically.

Some said it was the best coding assistant available. Others said it wasn’t worth the price. Most reviews were either suspiciously positive or completely dismissive.

So I stopped reading opinions and started testing.

For 30 days, I used Claude Code on a real production project. Not a side project. Not a tutorial app. A form-heavy medical examination system built for a state government — complex conditional logic, multiple examination form components, Java DTO integrations, file upload flows, and zero tolerance for bugs.

I've been using AI for code reviews for over a year. In that time I've learned one uncomfortable truth:

Most developers are using AI wrong for code reviews.

They paste code and ask "is this good?" They get back a wall of generic feedback that could apply to literally any codebase. It feels useful for about 10 seconds, then you realize nothing actionable came out of it.

The problem isn't the AI. It's the prompt.

After hundreds of iterations, I've identified the patterns that separate a mediocre AI code review from one that actually finds bugs, catches security holes, and suggests fixes a senior engineer would be proud of.

Here's what I learned — and the exact prompts I now use daily.

Over the past few months, I’ve been creating projects/applications with AI-powered coding assistants, and the experience has been nothing short of transformative. What started as curiosity has evolved into a fundamental shift in how I approach software development. Here’s what I learned about the capabilities, limitations, and best practices of coding with AI.

I had a draft post sitting in my local repo for a while, where I was about to scream about how AI is overestimated. Well, that post aged pretty badly. I never published it, and looking back at the notes I’m glad I didn’t. So what I’m going to write today will only be about my current workflow and how I actually use AI in my daily work — no hype, no predictions, just what I’ve found useful.

Three years ago, building a new software project felt like preparing for a mountain climb. You packed tools, planned every step, searched Stack Overflow for rope, and hoped the weather held.

In 2026, it feels more like stepping into a high-speed train.

Same destination. Different speed.

I’ve spent more than four years deep in Python development, building automation systems, data tools, internal products, and experimental AI workflows. I’ve written code the slow way, the painful way, and the “why did I do this manually?” way.

And if I’m honest, AI coding tools changed one thing more than anything else:

They didn’t replace coding. They removed friction.

I used AI every day for 30 days as a backend engineer.

Not for side projects or experiments — but in real work: debugging issues, writing code, understanding systems, and reviewing logic.

Some things became 10× faster.
Others actually made me worse.

Here’s what actually changed.

At first, I thought AI would mostly help me write code faster. That’s how it’s usually presented, as a way to speed up implementation or generate code automatically.

But after using it daily for a while, I realized that this is not where it actually brings the most value.

AI doesn’t really change how fast I type code. It changes how I approach problems, especially the parts of the job that are slow, repetitive, or mentally expensive.

The way I think about it today is simple: AI behaves like a very fast junior engineer.

It can generate ideas quickly, suggest implementations, and help explore possibilities. But it doesn’t truly understand the system, the business context, or the consequences of a decision.

Once I started treating it this way, it became much more useful — and much less dangerous.

I used to think AI would replace developers.
Now I use it every day — and it made me a better engineer.

When I started learning web development, everything felt slow:
• Debugging took hours
• Understanding docs was confusing
• Writing boilerplate was repetitive
• Building backend logic felt complex

Then I started using tools like ChatGPT.
And everything changed.

⚡ Faster debugging
⚡ Clear explanations of complex concepts
⚡ Quick boilerplate generation
⚡ Faster learning of frameworks like Next.js and Node.js

But here’s the reality:

AI didn’t replace my skills.
It amplified them.

Because AI still cannot replace:
• System design thinking
• Backend architecture decisions
• Scalability planning
• Real-world problem solving

Lesson
The future of software development belongs to developers who:
✔ Use AI as a tool
✔ Focus on solving real problems
✔ Build scalable systems

AI is not your competitor.
It’s your productivity partner.

Are you using AI in your development workflow?
Or are you still avoiding it?

#AIForDevelopers #SoftwareEngineering #DeveloperProductivity #WebDevelopment #Programming #FutureOfWork #FullStackDevelop

I didn’t start because it was trendy. I started because I was tired of the repetitive friction.

I didn’t pick up AI because everyone was talking about it.

I picked it up because I was doing the same kind of work every day.

Writing similar test cases.
Debugging the same API failures.
Reading requirements that looked complete but clearly weren’t.

At some point, it stops being interesting.

AI didn’t change my role. It just removed a lot of the low-value effort that comes with it.

This is how I actually use it now.

I Don’t Start From Zero Anymore

This is the biggest change for me.

Earlier, every feature meant opening a doc and thinking from scratch. What are the scenarios? What can break? What should I validate?

Now I take the requirement and drop it into tools like ChatGPT or Claude and ask for a rough set of:

Functional scenarios

Negative cases

Edge cases

Collectively, we're only really months into AI-assisted software development, and the abyss is already clearly visible.

I'd say I'm (currently) a 'maximalist traditionalist' - I use AI to help me build better, reusable code as well as deeper test suites than I would previously have had the patience to grind out. I'm getting more of a feeling for when it's bullshitting me. I'm also able to debug things more effectively. Overall, I'd say I'm operating about 1.8x than before, with a probable ceiling of 2.0x. That's a combination of a bit faster, a bit more comprehensive, and a bit more effective all at the same time.

But for the kind of high-stakes embedded codebases I work on, I don't want to ship code I don't understand or can't completely explain or justify. In many ways, my ideal scenario would be finding ways to use AI to help me ship less code than before (i.e. that's compact, easy to understand and share, and better all over).

And so I look across to agentic stuff, and the gap between how I work and how that works seems like an abyss. The appearance of working doesn't mean it is actually working; passing tests doesn't mean the code wasn't gamed to pass those tests; black box code is a liability, not an asset; code review is next to impossible at scale; and so forth.

So where do we go forward from here? I'm guessing traditionalist maximalists like me will find ways of using agentic development for specific kinds of task, such as early prototyping, client-facing UIs, CI support tooling, etc. But that doesn't feel like a major step change.

More and more, I'm coming to think that the programming languages we use aren't fit for purpose at the scale and speed we're now able to develop at. Or perhaps we're missing a whole load of AI development patterns? There's certainly a lot to think about.