AI in Software Development: A Pragmatist's Perspective

November 1, 2025

I have been doing “this”—meaning software and technology—for a long time. Long enough to see a lot of things change in business, developer tools, availability of resources, and what tech stack is currently in vogue. There are things that don’t really change too. A lot of the old software patterns still work unreasonably well. Knowing your domain and business rules still matter an incredible amount. Being able to work with others continues to be under-rated by a lot of developers. And hype still drives bubbles.

Given any topic with a lot of hype, there is usually a crowd that reacts and offers dismissals. The hype doesn’t mean there is no value there, and it also doesn’t mean that there is. So what is there, with AI hype? A lot to learn still. I’m no prophet so I don’t know what will happen. I’m a pragmatist who sees ways to use the new tools. It really just depends on your domain, your business rules, your tech stack, and how it needs to work with people.

I’ve been experimenting with LLM-based AI tools across different development scenarios. (Claude continues to be my preference, thanks for asking.) Should you use MCP? Claude Skills? Agents? Agent Personalities? The answer depends on your context, but here’s what I’ve learned from actual use.

Starting New Projects

AI performs decently well when starting new projects, particularly web-based ones. The greenfield scenario plays to its strengths—no legacy constraints, modern patterns, standard project structures. I’ve had reasonable success bootstrapping both web applications and native mobile apps, though web projects consistently outperform mobile in my experience.

Working on Existing Codebases

This is where trust becomes an issue. Results vary significantly on existing web projects—sometimes genuinely helpful, sometimes confidently wrong. With existing native Android code, my success rate drops considerably. The AI struggles with the nuances of established codebases, existing architectural decisions, and the specific quirks that accumulate in real projects.

This inconsistency is the key problem: you can’t rely on it blindly. When it works, it’s great. When it doesn’t, it can waste significant time or introduce subtle bugs. I’ve learned to treat it as a junior developer whose work always needs review, not as an autonomous tool.

Unit Testing: The Sweet Spot

Writing and maintaining unit tests has become my primary use case, and despite frustrations, this is where I get the most consistent value. The AI is quite capable at generating test cases and scaffolding test structures.

However, even here, blind trust is dangerous. I’ve repeatedly observed it try to delete failing tests it can’t fix rather than addressing the underlying issue. It will sometimes change assertions in nonsensical ways to make tests pass. You still need to understand what the tests should actually validate.

The pattern I’ve settled into: let the AI generate the initial test structure and common cases, then review and refine everything. It speeds up the tedious parts without removing the need for judgment.

What the Research Shows

My experiences line up with recent research findings. Studies from 2025 present a reality check that’s worth paying attention to. The most surprising finding: experienced developers using AI tools actually took 19% longer to complete tasks, even though they believed AI was speeding them up. That gap between what developers think is happening and what’s actually happening is significant.

The research shows that junior developers tend to benefit more than senior ones, and that individual productivity gains don’t automatically translate to organizational value unless you redesign workflows. The modest gains reported—around 10-15% when things go well—only materialize when organizations actively redirect the saved time to higher-value work. And for experienced developers working in complex, mature codebases, the benefits might be neutral or even negative despite all the hype and adoption.

The Bottom Line

Right tool for the right job is still the best advice. The trick is figuring out what that is. To me, AI is a good bet as part of the tool set used in software development. It won’t replace experienced developers, and therefore also junior developers who are good learners. AI makes mistakes, makes bad choices that a human wouldn’t. Those mistakes can slow down a developer who understands the code and the business.

The tools will get better, but I don’t expect exponential improvements from here. Not with LLMs at least. What it does help with is tasks that you can define carefully and fit into the context window of your chosen AI tool. For me, that’s adding unit tests where there are good examples of code standards and code you understand so you can catch its mistakes.

Vibe coding—just describing what you want and running whatever code gets generated—can work to a point. But it also might delete your project or introduce vulnerabilities we’re only beginning to discover. My advice: use these tools where they demonstrably provide value, but architect your workflow so you can drop them without disruption.

These are early days. We’ll discover better patterns for using them. But the fundamentals still apply: know your domain, understand your business rules, review everything, and work well with people. AI doesn’t change that.