The Fallacies of AI Coding

AI coding tools are everywhere now.

Agents that write code, open PRs, refactor functions, add tests, and sometimes even attempt to redesign half your system while you’re making coffee.

It’s impressive. It’s powerful. It’s also remarkably easy to misuse.

After spending a lot of time working with AI agents on real production systems, I’ve noticed something interesting: many of the things people say about AI-assisted coding are simply… wrong.

Not maliciously wrong. Just optimistic in a way that ignores how real software systems actually behave.

So here are a few fallacies of AI coding I’ve learned the hard way.

“AI means we don’t need tests anymore”

This one is probably the biggest myth.

Some people say that AI writes the code so quickly that writing tests is unnecessary. Or that AI can “reason” about correctness.

In practice, the opposite is true.

Automated tests and TDD are more important than ever.

Why?

Because tests create a feedback loop.

As developers, we use that feedback loop to validate that the system still behaves correctly as it evolves. But AI agents need that loop even more than we do.

Without tests, the agent is basically coding in the dark.

With tests:

• The agent can validate its own work
• It can refactor safely
• It can detect regressions while changing existing code
• It can explore the codebase without breaking everything

Tests are not just for humans anymore — they are infrastructure for AI development.

If anything, the best workflow is often:

1. Let the AI write tests
2. Let the AI write code to satisfy them
3. Run the tests continuously

The goal has always been the shortest feedback loop possible. AI just makes that principle even more important.

AI should not decide your architecture

AI is very good at writing code.

It is less good at understanding the long-term evolution of your system.

The caveat: this is mostly true for existing systems. When building something new, iterating on architecture with AI can actually work quite well. There's no legacy context to misread, no hidden constraints to violate. A blank slate is where AI architectural thinking tends to shine.

But production codebases are a different story.

They're messy, full of historical decisions, compromises, hidden constraints, and subtle integrations. Architecture emerges over time. If you ask an AI agent to "design the architecture" on top of that, you'll often get something that looks clean and beautiful — and completely incompatible with how your system actually works.

The better approach is:

• You design the feature
• You break it down
• The AI helps implement it

Treat AI as a pair programmer, not as the CTO of your codebase.

Let it help you explore the system and codebase. Design the feature together. Discuss approaches. Explore ideas.

But own the breakdown of the work yourself.

Don’t let AI commit huge changes

AI agents love big commits.

They’ll happily rewrite 20 files, introduce a new abstraction layer, refactor everything, and open a PR with 2,000 lines of changes.

This is a nightmare. Not because the code is necessarily wrong, but because reviewing it becomes impossible.

The solution is simple:

Work in small, committable tasks.

Small tasks give you:

• easier code reviews
• clearer intent
• faster feedback
• safer iterations

If a human shouldn’t commit it all at once, the AI shouldn’t either.

Think “small steps”, not “big magic refactor.”

Iteration beats perfect design

A common instinct when working with AI is to try and design everything first. You start writing long prompts like: "Design the best possible architecture for…" Then you go back and forth discussing design choices.

But there's a problem.

Every conversation with an AI agent has a context window — a hard limit on how much it can hold in memory at once. Long design discussions eat into that budget fast. By the time you've debated three architectural approaches, the agent has less room to actually write, reason about, and iterate on code. You've spent your most valuable resource on talking instead of building.

In practice, the best approach is much simpler:

Don't chase the perfect design. Good code that evolves is better than perfect code that never gets written.

Keep iterations:

• Small
• Specific
• Concrete

One of the best habits when working with AI agents is simply saying: "Let's implement the simplest version first." Then improve it.

CI is even more important now

Running builds and tests locally is great in theory. In reality, most of us end up looking at the CI pipeline to know if everything works.

There's an important distinction here though.

Running a focused set of tests locally — for the specific feature or module you're working on — is fast, cheap, and exactly the right feedback loop. Do that as often as possible.

But running the entire test suite locally on every commit or push is a different story. It's slow, it blocks progress, and it's CI's job. Push and let it do the heavy lifting.

With AI agents, this becomes even more important. If the agent runs every build and test locally for every small change, it becomes:

• Slow
• Expensive
• Token-heavy — build output, test results, and error logs all get fed back into the agent's context window. Stack traces are verbose. They add up fast. A few local runs can silently consume thousands of tokens, leaving less room for actual work — and quietly inflating your costs.

There's another angle here too.

When the agent runs builds locally, it reads everything. When CI runs them, the agent only sees a summary — a pass, a fail, a link. The context stays clean. The reasoning stays sharp.

So close the loop explicitly.

Give your AI agent access to CI results. Instruct it to check the pipeline after pushing. Let it read the failure, fix it, and push again — on its own. That's the full feedback loop working as intended. Without it, you're doing the boring part yourself.

CI is the safety net. It protects the system, validates changes, and allows development to move quickly.

Think of CI as the shared validator for both humans and AI. But only if you actually connect the two.

The concurrency trap

AI makes it very simple and tempting to do many things at once. You can open five tasks, start ten branches, ask the agent to work on everything simultaneously.

Technically, this works... Practically… it doesn’t.

Because there is still a bottleneck: You.

You still need to:

• Review the code
• Validate behavior
• Check UX
• Ensure the changes make sense

Everyone has a natural concurrency factor — the number of tasks they can effectively manage at once.

AI might allow infinite concurrency. Humans do not.

A simple model that works well: one task running autonomously — the agent works independently and opens a PR — and one task locally, where you iterate together. That's usually enough. Any more and the review queue starts backing up.

If you do run multiple autonomous tasks in parallel, keep them isolated. Tasks that touch the same files or modules will conflict. Sequence those, parallelize the rest.

Use AI to close tasks faster, not to open more tasks than you can handle. The bottleneck was never the code. It was always you. AI doesn't change that — it just makes it easier to forget.

And remember: context switching is the ultimate productivity killer.

AI shines at annoying tasks

Where AI really shines is in the things developers tend to procrastinate on.

For example:

• Updating packages with security vulnerabilities
• Fixing API deprecations
• Updating third-party integrations
• Addressing repetitive PR comments
• Fixing small but annoying bugs

These tasks are important, but rarely urgent.

AI agents are perfect for them. They can clean up technical debt, update dependencies, and keep the system healthy — often without requiring much attention.

Here's what that looks like in practice:

Trigger fixes from PR comments

Allow developers to tag the agent directly in GitHub comments:

@agent fix the lint issues
@agent address review comments
@agent update deprecated SDK usage

The agent can push follow-up commits to the same PR while CI validates the result.

Automate vulnerability fixes

Schedule a weekly job that scans dependencies and lets the agent open upgrade PRs for safe patch updates, including a short summary of what changed and why.

Handle repetitive review feedback

If you're leaving the same review comment more than twice, stop. That's a task for the agent. Point it at the PR, describe the pattern, and let it fix it. Consistently, across every file, every time.

The rule of thumb is simple:

If the task is important, repetitive, and easy to validate with CI, it’s a great candidate for AI.

Use AI to remove engineering friction, not to replace engineering judgment.

Let the AI become a force multiplier for engineering hygiene.

Guidelines are your secret weapon

One of the most underrated tools when working with AI agents is repository guidelines.

AI performs dramatically better when it understands:

• Coding standards
• Architecture conventions
• Preferred patterns
• Project structure
• Common workflows

Add guidelines to your repositories. Explain:

• How features should be structured
• How tests should be written
• Naming conventions
• Architectural boundaries

But: don’t try to write everything at once.

Remember iteration? Build the guidelines over time.

A great trick is this:

After completing a task with the AI, ask it to:

“Summarize the lessons from this task and add them as a guideline.”

Over time, your repository becomes a knowledge base for both humans and AI. And the agent will slowly start making better decisions.

Final thoughts

AI coding tools are powerful. But they don't magically replace good engineering practices. In many ways, they amplify them.

The teams that succeed with AI are usually the ones that already have strong foundations. Not because AI is fragile — but because good practices give it room to shine.

Strong testing culture. Clear architecture ownership. Small iterative workflows. Solid CI pipelines.

AI doesn't remove the need for discipline. It just rewards it even more.

And if used correctly, it can turn a good engineering team into a very fast one.

Just don't fall for the fallacies.