Technology

AI Coding Tools: Are They Actually Making Developers More Productive?

After over 25 years of writing code the old fashioned way, I have spent the last year working with AI coding assistants on real projects. Here is what actually happened to my productivity.

AI Coding Tools: Are They Actually Making Developers More Productive?

AI coding tools are everywhere. GitHub Copilot, Claude, Cursor, Cody, Amazon CodeWhisperer. Every tech company on the planet is selling some flavour of AI assisted development. The marketing promises are enormous. Ten times productivity. Write code at the speed of thought. Never write boilerplate again.

I have been using these tools for real work across my businesses for the past year. Not for toy projects or demos. For production code in CampSuite, for Dynamics 365 plugin development, for building features that actual customers depend on. And the honest answer about whether they make you more productive is: it depends entirely on how you use them and what you were doing before.

Where AI coding tools genuinely help

Let me start with the good stuff, because there is genuinely good stuff. When AI coding tools work, they work brilliantly. The problem is that the situations where they shine are not always the ones the marketing materials describe.

Boilerplate and repetitive patterns

This is the obvious one and it is real. If you are writing your fifteenth API endpoint, your tenth database migration, your hundredth unit test setup, AI tools are fantastic. They recognise the pattern, fill in the blanks, and you press tab. What used to take fifteen minutes of tedious typing now takes thirty seconds of reviewing a suggestion.

In my Dynamics 365 work, this has been genuinely transformative. Plugin registration, entity mapping, workflow activities. There is so much ceremony in the Dynamics ecosystem that an AI assistant can knock out in seconds. The code is not complicated. It is just verbose. AI tools are perfect for verbose.

Learning unfamiliar codebases

This surprised me. One of the most valuable things about AI coding tools is not the code they write but the code they explain. When I pick up a project I have not looked at in six months, or when I am reviewing someone else's work, being able to ask "what does this function do and why" and get a sensible answer is genuinely useful.

It is like having a patient junior developer sitting next to you who has read every file in the repository and never gets annoyed when you ask obvious questions. For someone who works across multiple codebases like I do, this alone justifies the subscription cost.

Scaffolding and prototyping

When I am validating a business idea or building a quick proof of concept, AI tools let me get to something functional dramatically faster. I wrote about validating business ideas before building and one of the key points was speed. The faster you can get something in front of a potential customer, the faster you learn whether the idea has legs. AI tools have genuinely compressed that timeline.

Last month I prototyped a feature for CampSuite that would have taken me two days to scaffold manually. With AI assistance, I had a working prototype in four hours. Not production ready, mind you. But good enough to show a customer and get feedback. That is a meaningful difference.

Where AI coding tools fall flat

Now for the uncomfortable bit. Because for every hour these tools save me, there are situations where they cost me time, introduce bugs, or actively make the codebase worse.

Complex business logic

AI tools are great at patterns. They are terrible at understanding why your business works the way it does. When I am writing pricing logic for CampSuite that needs to handle seasonal rates, group discounts, multi night stays and VAT across different jurisdictions, the AI suggestions are worse than useless. They look right. They compile. They pass the obvious test cases. And then they silently get edge cases wrong in ways that cost real money.

I have caught billing bugs in AI generated code that would have undercharged customers by several percent. Not because the AI is stupid but because it does not understand the business rules. It sees a pattern and fills it in. Business logic is not a pattern. It is a set of specific decisions that someone made for specific reasons, and those reasons are not in the code.

The false confidence problem

This is the one that worries me most. AI generated code looks professional. It has good variable names. It follows conventions. It looks like code a senior developer would write. And because it looks good, developers trust it more than they should.

I have watched experienced developers accept AI suggestions without really reading them, because the code looks clean and the tests pass. Then three weeks later someone finds a subtle concurrency issue or a security hole that was hiding in plain sight. The AI did not introduce a bug. It introduced confidence in code that nobody properly reviewed.

Junior developers are especially vulnerable to this. They do not have the experience to spot the subtle wrongness. They see clean code, they see it works, they move on. And the codebase accumulates technical debt that nobody recognises as technical debt because it all looks so damn professional.

Architecture decisions

AI tools are fundamentally reactive. They respond to what you are doing right now. They do not think about where your system is heading. Ask an AI to help you add a caching layer and it will happily write one. It will not ask whether you actually need caching, whether your database queries are the real problem, or whether you are adding complexity you do not need.

The best architectural decisions come from understanding the full context of a system. What the business needs. Where the pain points are. What the team can maintain. AI tools have none of this context. They optimise locally. Good architecture requires thinking globally.

What AI coding tools actually change about the job

Here is what I think the real story is, and it is more nuanced than "AI makes you faster" or "AI is overhyped."

The work shifts from writing to reviewing

With AI tools, I spend less time typing and more time reading. That sounds like a win but it is actually a different skill that not everyone has developed. Writing code forces you to think through every line. Reviewing AI code requires you to spot what is wrong with code that already looks correct. That is harder, not easier.

If you are a senior developer with years of pattern recognition and a good nose for when something smells wrong, this shift works in your favour. You can review faster than you can write. But if you are early in your career and still building that intuition, relying on AI to write the code means you are not building the mental muscles you will need later.

The productivity gap widens

Good developers get more productive with AI tools. Mediocre developers do not get much benefit and might actually get worse. This is because AI tools amplify your existing abilities. If you know exactly what you want and can quickly evaluate whether the AI gave you the right thing, you move faster. If you are not sure what you want, the AI cannot help you figure it out. It just generates code that might or might not be what you need.

I have seen this play out on my own teams. The developers who were already strong got meaningfully faster with AI tools. The ones who were still learning did not speed up much and occasionally shipped worse code because they trusted suggestions they should not have.

Some skills become more valuable, not less

If AI can generate decent code quickly, what becomes the scarce resource? Judgement. Knowing what to build. Understanding the business context. Designing systems that work at scale. Debugging the weird stuff. These skills are worth more now, not less.

This is actually good news for experienced developers and consultants. If you can think clearly about what needs building and why, AI tools make you dramatically more effective. The thinking was always the hard part. The typing was just the implementation detail.

My practical approach to AI coding tools

After a year of using these tools on real projects, here is how I actually use them day to day.

I use AI freely for boilerplate, test scaffolding, and repetitive code. Tab, tab, tab. Brilliant. Time saved, no drama.

I use AI for first drafts of functions when I know exactly what I want. I describe the requirements clearly, let it generate something, then review and modify. This is genuinely faster than writing from scratch for straightforward logic.

I never let AI write business critical logic without rewriting it myself. Pricing, billing, permissions, data validation. These are the places where subtle bugs cost real money. I write these by hand and I think carefully about every line.

I use AI heavily for learning and exploration. Understanding unfamiliar libraries, exploring API documentation, getting explanations of code I did not write. This is probably the highest value use case that nobody talks about.

I do not use AI for architecture decisions. Those require the kind of deep contextual thinking that AI simply cannot do yet. When I am helping clients with consulting and strategy, the value is in understanding their specific situation and making judgement calls. That is a fundamentally human skill.

The honest bottom line

AI coding tools have made me roughly 20 to 30 percent more productive on the kind of work where productivity is measured in lines of code or features shipped. On the work that actually matters most, the thinking work, the architecture work, the "should we even build this" work, they have made approximately zero difference.

That 20 to 30 percent is real and worth having. I pay for these tools and I will keep paying for them. But the breathless marketing about ten times productivity is fantasy. If you were a good developer before AI tools, you are now a slightly faster good developer. If you were a mediocre developer, you are now a slightly faster mediocre developer who produces more confident looking code that might be wrong.

The tools are useful. They are not magic. Use them where they work, ignore them where they do not, and for the love of all that is holy, review what they generate before you ship it. Your customers are depending on code that works, not code that was written quickly.

More from the blog

Technology9 min read

Why Microservices Are Wrong for Most Small SaaS Products

Read more
Business8 min read

How to Validate a Business Idea Before Building Anything

Read more
Technology8 min read

Choosing a Tech Stack for Your SaaS: A No Nonsense Guide

Read more