AI Coding Agents Commit Your Bad Habits Faster

1. Going in blindfolded

Agents want to help. Badly. Give one a task and it starts solving immediately. That exact task, as written, with barely a question or a moment of doubt.

Say I ask for this:

"Build an export feature."

Ten minutes later I have a CSV export with filters, three utility functions and a pile of tests. Looks productive but might be completely wrong.

Maybe the customer never wanted a CSV export. Maybe the real problem was never just "export data" at all, but "I don't want to copy numbers into Excel every Friday afternoon anymore."

Here's the uncomfortable part: I do the same thing. I hear a requirement and start building, because building feels productive and asking questions feels like blocking progress. Yet every piece of software I'm actually proud of started with boring questions. Who needs this? Why? What happens after they click the button? Does it even need to be a button?

The agent skips these questions because I never tell it to ask them. Half the time I skip them too. So lately I've started putting "ask me questions before you write code" into my prompts. It's such a small change but it works wonders. Suddenly the agent wants to know who consumes the export, in which format, and whether it needs to run on a schedule — exactly the questions I should have asked the customer in the first place.

---

2. The slow rot

Skip the questions, optimize for development speed, and the codebase quickly develops a very specific symptom: duplication.

If there's no obvious place where a certain piece of logic belongs, the 10agent won't magically discover one. It writes a helper that already exists two folders away. It builds a second version of the validation logic, because the intended abstraction was never visible in the first place.

And it works. For now. That's exactly what makes it dangerous: duplicate code is a slow bug generator. One copy gets updated, the other doesn't, and six months later nobody remembers which one is "real".

I paid for this lesson. An agent once confidently created a second mapping for database data we already mapped elsewhere. The two implementations drifted apart over time and slowly descriptions went missing, decimals got rounded differently, and at some point the data itself was corrupted. It never reached production because I caught it in time. Still cost me way too much time and a fair amount of nerves.

The fix is is simple. Write down the patterns somewhere the agent can find them. For me that's a short conventions file in the repo root, an AGENTS.md, or whatever your tool reads: where mappings live, which helpers already exist, how we name things. The agent reads it before every task and we should too, from time to time.

---

3. A Band-Aid on a broken leg

Agents are brilliant at making errors disappear. A test fails? Change the assertion. Response is undefined? Bury it under optional chaining. Symptom gone, everyone's happy.

But the visible error is usually just smoke. The fire sits somewhere else: an unclear data model, logic living in the wrong layer, or the fact that nobody can explain whether status = "done" means "approved", "shipped", or "the intern clicked the green thing".

"How do I fix this bug?" is rarely the interesting question. "Why was this bug possible?" is.

And I've applied plenty of Band-Aids without any agent involved. After one workshop I immediately started adding new relations to our entity relationship diagram, then spent two hours making the diagram look consistent again. It held up until the next review, where the real problem became obvious: the ERD was never the issue. We simply hadn't agreed on the domain model yet.

I've lost count of the quick patches I meant to clean up later. Later, in my experience, often means never. The agent didn't teach me that habit, it just executes it faster than I ever could.

---

4. The comfort of complexity

Agents love structure. Ask for a small helper function and you might receive a service, an interface, a factory, a dependency injection layer, plus a README explaining the philosophy behind the helper function.

I'd love to mock that. Except I've built the same thing myself, usually when the problem was unclear and inventing architecture felt safer than making an actual product decision.

Overengineering is sneaky because it looks professional. Layers, patterns, names like AbstractExportStrategyProvider. Sounds important enough to survive the next code review. But complexity isn't quality. Sometimes it's just an elaborate way to postpone a call nobody wanted to make.

Sometimes the right solution is a button. A cron job. Literally "download this CSV and mail it to accounting". Not an extensible plugin architecture for a feature three people use once a month.

The question I try to ask first now: what would the embarrassingly simple version look like?

Usually, that's the version that holds up.

---

Agents write. I decide.

Points 3 and 4 might sound contradictory: avoid quick patches, but also avoid overengineering. They aren't. The goal is the simplest solution that addresses the real problem, and finding that still requires human judgment.

Agents are excellent at making assumptions, producing a first draft, and grinding through repetitive work. Better prompts, project rules and good examples help a lot. They don't replace clarity.

Agents write. I still decide what ships, and I own what lands in production.

That's the actual lesson for me. These agents amplify our shortcuts, our assumptions, our half-written requirements quicker than we ever did. They don't remove the need for engineering judgment.

So before I blame the agent, I check the usual suspects: unclear problem, unclear ownership, unclear root cause. The agent didn't introduce any of that.

It just made it impossible to ignore.