I’ll be upfront about where I land on AI in software development: it’s genuinely changed how I work, and I wouldn’t want to go back. But I also think we’re at a point where the risks deserve as much attention as the hype. So here’s an honest look at both sides, from my own day-to-day experience.

Before and After: What My Day Actually Looks Like

Planning a feature. Before, my approach was to dive in. I’d read the docs, browse forums (Stack Overflow, the GOAT, of course), and mentally break the whole task down into smaller pieces that I’d build and test one by one. It worked, but the planning itself lived mostly in my head, and I’d discover the gaps in my thinking halfway through the build. Now, planning is a conversation. I use planning and brainstorming skills, which are structured workflows the AI follows to help think through a task before writing any code. Instead of me just describing what I want and getting code back, the AI interviews me: it asks questions that push me in the right direction, surfaces the decisions I hadn’t realized I needed to make, and fetches up-to-date documentation on its own. By the time code gets written, the gaps have already been found.

Debugging. The old loop was one every developer knows: copy the stack trace, paste it into Google, open five Stack Overflow tabs, and hope one of them matches your situation. Now I ask the AI directly inside the codebase. Because it can see my actual code and not just the error message, the answer and the fix come much faster. No more translating someone else’s similar-but-not-quite problem into mine.

The order of my work flipped. I used to write code first and document later. Now the writing comes first: I describe and specify what I want up front, and my main job shifts to reviewing what comes back. The thinking that used to happen while typing code now happens before any code exists, and the scrutiny that used to be an afterthought is now the core of what I do.

The bottom-line numbers. Features that used to take me twice as long now ship in half the time. That’s not a cherry-picked best case, that’s the ordinary difference across my regular work.

The Risks Nobody Should Ignore

Here’s where I part ways with the “just let the AI write it” crowd, because there are real risks, and I see them regularly.

Not reviewing what the agent generates. This is the big one. AI-generated code looks confident and polished whether it’s right or wrong. If you’re not actually reading it (really reading it, the way you’d review a teammate’s pull request) you’re shipping code nobody understands. And in my opinion, being able to do that review well requires having written and understood code yourself first. I’d put the bar at somewhere around 2-4 years of real world experience. Skip that foundation and sooner or later you’re looking at security issues, because you won’t recognize the vulnerable pattern when the AI hands it to you.

Logic drift. Over time, AI-generated changes can quietly diverge from how the rest of the codebase does things: different patterns, different conventions, different assumptions. This is why using the right tools and giving the AI enough context matters so much. Every AI coding tool has some version of a project instructions file. With Claude, for example, it’s a file called CLAUDE.md that lives in your repository. Think of it as an on-boarding document for the AI: it describes your project’s architecture, coding conventions, preferred patterns, and anything else a new developer would need to know before touching the code. The agent reads it automatically before it starts working, so instead of guessing how your codebase does things, it follows the rules you’ve written down. Keeping that file accurate and up to date makes a real difference in how consistent the generated code stays with what’s already there.

Skill atrophy. If you lean on AI for everything, you stop practicing. Writing code is a skill you maintain by doing it, and reviewing code is a skill you maintain by doing that too. Developers who outsource both, all day, every day, may find those muscles weaker when they actually need them.

The agreement bias. AI assistants tend to agree with you by default. Suggest an approach, and more often than not the AI will run with it rather than push back, even when your approach is wrong. A good senior developer questions their own choices. An AI usually won’t unless you specifically ask it to, so you have to bring your own healthy skepticism.

The Bottom Line

My take is, for seasoned developers, AI has really improved software development. My process is genuinely different now: planning is a conversation, debugging happens inside the codebase, the spec comes before the code, and features ship in half the time. But the technology rewards developers who already know what they’re doing and punishes those who treat it as a substitute for understanding. The experience, the review discipline, and the healthy skepticism still have to come from a human. When they do, it’s a remarkable combination.