The more I use coding agents at work, the more I notice one thing: they make you stop thinking too early.

I am not saying that we should avoid using coding agents. I use these mfs a lot for bug fixes, rushed features, and dirty work. The speedup is real, and kinda insane, but something feels off.

"Code first, think later"

In traditional development, the order is pretty clear. You think about the interface, the data structure, boundary cases, and tests first, and then you write code. Slower, definitely, but at least you have a whole picture in your head and a much better chance of knowing why the thing works.

Now it is the opposite.

You ask a coding agent to build on top of an existing project, and let me guess, the prompt is gonna be something like:

"Hey my boss just told me to do this, implement it."

Then you drop in some markdown or whatever docs look like a feature request, wait for a while, and boom, the page renders, the API responds. It works. Once it works, you probably will not step back and look at the whole thing the coding agent just generated. Then these kinda so-called feature requirements or bug fixes keep coming one by one, again and again, and congrats, now you have a "shit mountain".

Illustrative engineering complexity by code base size

Code base size	Human-led AI coding	Pure vibe coding
Very small	12	7
Small	22	12
Medium	32	24
Large	42	56
Very large	52	94

Plan mode != Upfront thinking

Upfront thinking is not just writing a todo list or turning on plan mode in a coding agent.

Real upfront thinking is modeling. What is the core object? Which values are real state and which are derived? Where is the module boundary? If we get three similar requirements next month, can this shape absorb them? At which layer should the tests exist? And at which point will this system break?

This part is not sexy. It kills your brain cells like hell, and it will not show up in a weekly report. But it is what makes engineering hold up over time.

Technical debt, still paid by humans

Current coding agents are pretty much all LLM-based. They all have context limits, which means they forget things.

Today you patch a module and push with one commit that looks like +18914 / -7986. Tomorrow you say, "we can clean it up later." But cleanup rarely happens, especially when you are working in a team. The same module might even get reused by other humans or coding agents in no time. And nobody will know why something exists or why a simple refactor breaks everything after just a few weeks.

Then you start using a coding agent to debug it. It reads the git history, sees the commit author, and says, "huh, it was you!" 🤡

Nah fuck off.

Old-school still teaches

I keep seeing people online claiming that zero basics and a few weeks of vibe coding are enough to build production-ready apps. Some even have the nerve to walk into interviews like that 🤷. I do not deny that people learn fast, but getting something to run and building a system are two different things.

Interface design, data modeling, complexity control, and technical debt intuition haven't really become outdated. If anything, they matter even more now.

Implementation is cheaper. So the decisions that keep a system clean are more valuable. Coding agents can write a lot of code, but they do not know what to keep simple, what to not do, and what will be painful to change later.

Final thoughts

I will keep using these tools. They are too useful to ignore. But the easier it becomes to say "just make it work first", the more I need to remind myself not to skip the thinking part.