Oleksandr TverdokhliebI ship internal tools and side projects with AI sitting in my editor most days. It has genuinely changed how fast I work — and it has also handed me bugs so plausible I nearly merged them. This is my honest accounting of both sides, and where I've landed: AI is a brilliant accelerator and a terrible autopilot.
The discourse around AI coding tends to split into two unhelpful camps. One says junior developers are obsolete and we'll all be "prompting" by next quarter. The other says it's autocomplete with a marketing budget. Neither matches what I actually experience when I build something real. The truth is more useful and less dramatic: the tools are powerful in specific, knowable ways, and dangerous in equally specific, knowable ways. The whole game is knowing which is which before you press merge.
Where it genuinely pays off
Let me start with the honest upside, because it's real and I'd be lying to pretend otherwise. The first win is momentum. The hardest part of a side project at 9pm isn't the hard part — it's the empty file. AI scaffolds the boilerplate, stubs the routes, sketches the config, and suddenly I'm editing instead of staring. For personal projects that would otherwise die in the "I'll start it this weekend" graveyard, that shift from blank page to working skeleton is the difference between shipping and not.
The second is unfamiliar territory. When I drop into a stack I don't use daily — a new framework, an SDK I've never touched, some gnarly CSS layout — AI is a faster, more patient way to learn than bouncing between twelve browser tabs. It shows me the idiomatic shape of a thing, and I learn by reading and adapting rather than by transcribing. The third is refactoring and translation: "rewrite this loop as a comprehension," "convert this script to use the async client," "explain what this regex does." These are mechanical, well-bounded tasks where the AI is fast and I can verify the result at a glance.
None of this is hype. Surveys consistently find developers feel more productive and more fulfilled with these tools in the loop — and that subjective experience matters, because flow and reduced frustration are why side projects survive. But "feels faster" is exactly where the honesty has to get sharper, because the measured picture is messier.
Where it quietly bites
The risks aren't the dramatic ones people imagine. The AI rarely produces obvious garbage — obvious garbage is easy to catch. What it produces is plausible garbage: code that reads beautifully, runs on the happy path, and contains a subtle bug you'd never write yourself because you'd never have been that confident. An off-by-one in a boundary condition. A silently swallowed error. A function that handles the example I gave and quietly mishandles the case I didn't mention. The confidence of the output is the trap.
Then there's hallucinated APIs — methods, parameters, and entire libraries that simply don't exist but look exactly like they should. And the one that should worry anyone shipping to production: security. Multiple analyses have found that a large share of AI-generated code introduces vulnerabilities — Veracode's 2025 review of AI output across many models put it around 45% of cases, echoing earlier academic work on Copilot. SQL injection, command injection, hard-coded secrets — the classics, generated cleanly and confidently. Worse, researchers have found that people using AI assistants tend to write less secure code while feeling more confident it's safe. The false sense of security is the actual vulnerability.
Where it pays off
- Scaffolding and boilerplate — blank page to skeleton fast
- Learning an unfamiliar stack, SDK or framework
- Mechanical refactors and code-to-code translation
- Explaining dense code you didn't write
- Momentum on side projects that would otherwise stall
Where it bites
- Subtle, plausible bugs you'd never write yourself
- Insecure code that reads perfectly clean
- Hallucinated APIs, params and libraries
- Over-trust and a false sense of security
- Skill atrophy, and pasting proprietary code into a box
Two slower-burning risks round it out. Skill atrophy is real — if I let the tool do the thinking on every problem, the muscles I'd use to debug a genuinely novel issue get weaker. And the confidentiality question: pasting proprietary or client code into a tool to "just fix this quickly" is a data-handling decision, not a convenience. I treat where the code goes as seriously as what the code does.
The productivity number deserves a footnote
Here's the uncomfortable nuance. Even as developers report feeling dramatically faster, the team-level delivery metrics don't always agree. Google's DORA research has repeatedly noted that AI adoption amplifies a team's existing habits rather than rescuing them — and that higher individual output can show up downstream as bigger review queues and shakier delivery stability, not faster shipping. More code generated is not more value delivered. It's just more code to review, and review is exactly where AI shifts the work.
I don't read that as "AI doesn't help." I read it as: the bottleneck moves. The constraint stops being how fast you can write a function and becomes how fast you can verify one. If your review discipline doesn't scale with your generation speed, you've just built a faster way to accumulate risk.
Trust, but verify — as an actual loop
So the stance I've settled on isn't "use AI" or "don't." It's a loop with a non-negotiable gate. Generate fast, then treat everything the AI produces as a confident draft from a talented stranger who has never seen your codebase, your security requirements, or your edge cases. Nothing crosses the line into merge without my eyes and, for anything that matters, a test.
In practice that means a few concrete habits. I keep prompts scoped and specific, because a vague ask gets a vague, hallucination-prone answer. I read every generated line as if a colleague wrote it on a deadline — looking hardest at error handling, boundaries, and anything touching auth, input, or secrets. I write or ask for tests on the cases the AI conveniently ignored. And I never paste anything sensitive into a tool I haven't cleared for it.
What I'm taking into 2026
- Generate fast, verify slow. The speed-up is real; spend it buying time for review, not skipping it.
- Treat confidence as a warning, not a signal. The cleanest-looking output is exactly where the subtle bug hides.
- Protect the fundamentals. Keep solving some problems by hand so the debugging muscles don't waste away.
- Guard the inputs. Where the code goes matters as much as whether it works.
I'm not nostalgic about doing things the slow way, and I'm not breathless about the new way either. AI has made me a faster builder and, paradoxically, a more careful one — because the failure mode shifted from "can't get it working" to "got it working a little too easily." Used with discipline, it's the best accelerator I've had in years. Used as an autopilot, it's a confident way to ship someone else's bug under your own name. I know which one I'm choosing.