Here’s what I’ve learned.
The Real Wins
Speed on boilerplate. Setting up auth, building standard CRUD operations, creating API serializers that follow consistent patterns — AI crushes this. On projects heavy in standard patterns, I’m measurably faster.
Less context switching. Looking up library docs, remembering syntax for something I use twice a year, figuring out the right regex — AI handles it inline without breaking my flow. This is underrated.
First drafts of complex queries. I describe what data I need in plain English and get a SQL or ActiveRecord query to start from. Usually needs tweaking, but starting is the hard part.
Catching things in review. AI reads code I’ve written and spots potential issues — performance problems, unhandled edge cases, security concerns. Not a replacement for human review, but useful as a first pass.
The Genuine Limitations
It hallucinates APIs. AI confidently generates code using methods that don’t exist, or that got deprecated three versions ago. This is dangerous because the code looks right. Always run generated code. Don’t just read it.
It can’t understand your business rules. I can describe our pricing model, but if it’s complex enough to need custom software in the first place, the AI is missing nuances that only show up against real data.
It generates plausible-looking tests that test nothing. AI test generation is fast. The tests often assert behavior that isn’t business-critical, or test the implementation instead of the behavior. “This test passes” doesn’t mean “this code is correct.”
Security-sensitive areas need human review. Auth, authorization, input validation, data exposure in APIs — AI can generate these, but they need careful expert review. The cost of getting these wrong is too high.
Architecture is not AI’s strength. “How should I structure this system?” gets you answers that sound reasonable. Whether they’re right for your specific constraints — team size, maintenance burden, future scaling needs — requires context and judgment AI doesn’t have.
Practical Guidelines
When I use AI code generation, I follow some rules:
-
Write a spec before generating. I describe what the code needs to do before asking AI to write it. Forces me to think clearly about requirements and gives the AI better context.
-
Treat generated code like a junior developer’s PR. Read every line. Understand it. Fix what’s wrong. Don’t merge code you don’t understand.
-
Run the tests. Not just check that they pass — run the application and verify the behavior. AI tests often pass on generated code because the code and tests share the same incorrect assumptions.
-
Write the business logic myself. Scaffolding, setup, standard patterns — AI. Business rules, domain logic, edge case handling — me. This is where the money is and where mistakes cost the most.
-
Use it for exploration, not authority. When I’m deciding between approaches, AI is a good thinking partner. But it’s not an authority. “The AI suggested this” is not justification for an architectural decision.
The Compounding Effect
The best thing about AI assistance isn’t any single time savings — it’s the compounding.
Moving faster on boilerplate means more time on hard problems. More time on hard problems means better software. Better software means fewer production incidents. Fewer incidents means more time building, not fixing.
Over a project, this compounds into a meaningfully better outcome. Not because AI wrote the application, but because it handled the tedious parts and left more of my capacity for the work that matters.
What This Means for Pricing and Timeline
Faster development means I can take more projects and, in some cases, pass savings along. Doesn’t mean I’m cutting quality — means the quality work happens faster.
For clients, this is a genuine win. You get production-grade software built by someone with 20 years of experience, delivered faster than it would’ve been three years ago.
Reach out if you’re working on a custom software project and want to talk about what AI-assisted development looks like in practice.