What AI Coding Tools Actually Do Well

AI coding tools improve my productivity by 20-30%. That's significant. Here's where they earn their keep:

• Boilerplate and repetition. Generating config files, scaffolding components, writing the seventh variation of a similar function — AI handles this faster than I can type.
• Translating intent to code. Describing what I want in plain English and getting a reasonable first draft saves time, especially in languages or frameworks I don't use daily.
• Debugging and refactoring. AI can spot patterns in error messages, suggest fixes, and restructure code faster than manual search-and-replace.
• Documentation. Generating comments, README files, and API docs from existing code is one of AI's strongest use cases — it reads code better than most humans write about it.

Where The Marketing Diverges From Reality

The claim that AI will replace developers is wrong. The claim that AI makes fewer errors than humans is misleading. AI makes different errors — and those errors can be more dangerous precisely because they look correct on casual inspection.

In 2025, I asked an AI to generate unit tests for a small project. The tests passed. They also silently replaced two production HTML files with empty skeletons. If I'd committed without checking, the application would have broken in production. The AI did exactly what I asked — generate tests — and destroyed files in the process because my prompt didn't say "without breaking anything else." That shouldn't be necessary.

This is not an isolated incident. Every developer using AI tools has a story like this. The difference is whether they caught it before it shipped.

The "Vibe Coding" Problem

There's a trend of developers — especially junior ones — writing entire applications by prompting AI and accepting whatever comes back. The code works. They don't understand it. When something breaks six months later, nobody can fix it because nobody ever understood it in the first place.

This is technical debt on a scale we haven't seen before. At least with legacy code written by humans, someone understood it when they wrote it. With AI-generated code that was never reviewed by someone who understood it, you have a codebase that nobody has ever understood.

Security Vulnerabilities

AI models are trained on public code, which includes vulnerable code. When you ask an AI to generate a database query, there is a measurable probability it will generate one that's vulnerable to SQL injection. When you ask it to handle user input, it may skip sanitization. The AI doesn't know what's secure — it knows what's common, and insecure patterns are very common in training data.

Worse: if your entire team uses the same AI tool, the same class of vulnerability gets injected across your entire codebase. A single flaw in the model's training becomes a systemic weakness in your product.

Hallucinations

AI models confidently generate calls to APIs that don't exist, reference packages that were never published, and import modules with fabricated names. In 2025, researchers demonstrated that attackers could register the package names that popular AI models hallucinate, turning AI hallucinations into a supply chain attack vector. If your AI suggests npm install helpful-utils and that package was registered by an attacker who noticed the same hallucination pattern — you've just installed malware.

Intellectual Property

AI models trained on open source code sometimes reproduce that code verbatim, including code under licenses that are incompatible with your project. If your proprietary product ships with GPL-licensed code that an AI copied without attribution, you have potential legal exposure that the case law has not yet resolved — Doe v. GitHub (2022) was largely dismissed but the questions it raised about training-data provenance and downstream license inheritance remain open and will be tested again. The AI doesn't track provenance and neither do most developers who accept its suggestions. Whichever way the case law eventually settles, the safe assumption today is that you are responsible for what your shipped code contains, regardless of how it got there.

The Monoculture Risk

When millions of developers use the same handful of AI models, the code they produce converges. The same architectural patterns, the same library choices, the same approaches to common problems. This creates a monoculture — and monocultures are fragile. A single vulnerability in a pattern that an AI recommends to everyone becomes a vulnerability in millions of applications simultaneously.

Agentic Coding

The latest generation of AI tools don't just suggest code — they autonomously create files, run commands, modify configurations, and make commits. This is powerful when it works. When it doesn't, the blast radius is much larger than a bad autocomplete suggestion. An agentic AI that decides to "clean up" your infrastructure configuration or "optimize" your database schema can cause real damage before you notice.

Practical Guidance for AI-Assisted Development

None of the risks above mean you shouldn't use AI coding tools. They mean you should use them with the same caution you'd apply to code from a junior developer who's fast but sloppy. Specifically:

• Review everything. Treat AI-generated code as unreviewed code. Don't merge it without the same scrutiny you'd give a pull request from a human. If you can't explain what the code does, don't ship it.
• Understand what you're shipping. If AI wrote it and you don't understand it, you own the technical debt. Either learn what it does or rewrite the parts you don't understand.
• Include security context in prompts. Don't ask for "a function to query the database." Ask for "a function to query the database using parameterized queries to prevent SQL injection." The AI won't add security measures you don't ask for.
• Watch for hallucinated dependencies. Before you npm install or pip install a package the AI suggested, verify it exists and is what you think it is. Check the publisher, the download count, and the source code.
• Keep humans accountable. AI can't be sued, fired, or held responsible. The human who approved the code can. Structure your process so that a human is always accountable for what ships.
• Don't use AI as a crutch for skills you lack. If you don't understand networking, asking AI to write your firewall rules is dangerous. AI amplifies competence — it doesn't replace it.
• Limit agentic scope. If your AI tool can create files, run commands, and make commits, constrain what it's allowed to do. Review its actions before they take effect. A confirmation step between "AI proposes" and "change happens" prevents most catastrophic mistakes.
• Rotate and diversify. Don't rely on a single AI model for all your code. Different models have different strengths and weaknesses. Using multiple tools reduces the monoculture risk.

The Bottom Line

AI coding tools are the most significant productivity enhancement since the IDE. Use them. But use them the way you'd use power tools — with respect for what they can do to you if you're not paying attention. The developers and organizations that thrive will be the ones that leverage AI's speed while maintaining human judgment about what's correct, secure, and maintainable.

The goal is not to trust AI-generated code. The goal is to verify it efficiently enough that the productivity gain isn't eaten by the review overhead. Get that balance right and AI is a genuine force multiplier. Get it wrong and you're shipping code nobody understands with vulnerabilities nobody checked for.