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

AI didn’t replace my development workflow. It changed the way I approach it.

AI coding tools have changed dramatically in the last few years.

Today, developers can generate components, debug errors, explore UI ideas, write documentation, and even make changes directly in a Git repository with the help of AI.

But there is one question I kept asking myself:

How can I actually use AI in my daily projects without becoming dependent on it?

After experimenting with different tools, I eventually developed a workflow that works well for me.

Instead of asking one AI tool to do everything, I use different tools for different stages of the project.

My current workflow looks like this:

Idea → ChatGPT → Stitch → MCP → Antigravity → Jules → Human Review

This article explains how I use each part of that workflow and what I have learned from it.

🤖 GitHub Copilot can now trigger agent automations directly from comments

Released last week, Copilot cloud agent automations can now run when a specific comment is added to an issue or pull request

What it enables:
▶️ generate or update documentation
▶️ investigate errors and stack traces
▶️ create follow-up issues automatically
▶️ trigger predefined agent workflows from comments
Instead of manually prompting an agent each time, teams can embed

Copilot directly into the events already happening inside their development workflow

Available across paid GitHub Copilot plans, with admin policy requirements for Business and Enterprise

#GitHubCopilot #AgenticAI #AI #DeveloperTools #Automation

AI didn’t replace me — it changed the way I think, build, and solve problems.

A few years ago, my day as a developer looked very different.

I would spend hours searching Google for solutions, reading Stack Overflow threads, watching YouTube tutorials, and trying different approaches until something finally worked.

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.