Against Cognitive Laziness

AI has already changed the way we work, and developer teams are reorganizing around it fast. That part is not really up for debate anymore.

What is up for debate is how we are using it.

Since the introduction of agentic AI, I keep seeing the same pattern: a POC gets built in a rush, the code receives only a superficial review, it gets shown to the customer, the customer likes it, and suddenly the POC becomes the MVP. Then nobody rewrites it, because now we "need to move fast."

What worries me isn't AI itself. It's that we're slowly outsourcing the part of the job that matters most: understanding what we're building.

The Illusion of "One-Shot" Mastery

People are using complex libraries or domain languages they haven't fully mastered, skipping the deep study, patterns, and practice that used to be required. Now there's this growing belief that you can just prompt a one-shot solution and you're done. Ready to ship. Sell it to the client. Now.

There is a small flaw in that logic.

If it's that easy for you to prompt, the customer can do it too, and eventually they will. The reality is that someone who truly understands the domain will always do a better job than someone who doesn't. The value was never just in writing the code. It's in understanding the problem well enough to know whether the generated solution is actually the right one.

Lately, I've also noticed a growing disregard for the quality of AI output, usually excused by a familiar phrase:

"This is just a POC. Why should I care about architecture?"

To me, that's a risky precedent.

As developers, we grew up trying to craft the best software possible: solving problems, writing clean code, and leaving things in a better state than we found them. Every time I open a PR or solve a task, I think about the next person who will have to touch that code. I want it to be easy to reason about, well structured, and capable of handling the complexity that non-trivial applications inevitably bring.

Have I broken my own rules in the past? Absolutely. I've written code I'm not proud of because I was working fast, alone, and under tight deadlines. I still feel guilty about some of those projects and can't wait to refactor them. I was writing software years before AI-assisted coding existed, back when IntelliSense was the smartest tool in the editor.

Today, with frontier models at our disposal, we have even fewer excuses to abandon good engineering practices. If AI is doing most of the typing, why shouldn't we spend more time thinking about architecture instead?

The "If It Works, It's Good" Trap

If we don't know a technology, we shouldn't just wing it with an agent. We should talk to the team members who do know it, discuss the approach, and think through the architecture together. That's how a solid POC becomes a viable MVP instead of technical debt with a demo.

Working in an agency, the phrase "If it works, it's good" is a constant shadow. But what does that actually mean?

If an unmaintainable AI-generated POC makes it all the way to production, the organization might celebrate the quick win, but we're setting ourselves up for a much bigger loss later.

And who pays for it?

The developers who have to maintain it, debug it, and build new features on top of it. Sometimes they're not even the same developers who rushed it into existence in the first place.

Whenever these concerns come up, the answer is often the same:

"That'll happen in six months. By then we'll have a model that fixes all our problems."

Maybe we will.

It still won't fix poor engineering decisions.

The biggest worry is that this mindset is creeping into engineering teams at every level. Some developers are still fascinated by the novelty of agentic coding and haven't had their first major crash yet. Worse, it's becoming harder to even have an honest discussion about it, especially when PR reviews spend more time on naming than on the architectural problems that will matter later.

Please don't get me wrong: I use AI daily and extensively. I pay for several subscriptions out of my own pocket. It has helped me revive a graveyard of unfinished side projects and finally make progress on them.

I am not anti-AI.

I am against using AI as a substitute for understanding.

The Law of Environment

What does human usage of AI even mean?

To me, it means giving power back to the developer. It means rewiring our brains to actually understand what we're shipping.

One thing I've noticed is that AI thrives in properly structured environments and does a horrific job in messy ones.

Feed an agent a repository with clear patterns, thoughtful architecture, and consistent conventions, and the output is often impressive.

Feed it slop, and it happily produces more slop.

The environment matters more than ever because AI amplifies whatever you give it.

That's why I believe POCs should start with a product mindset. Not because every prototype needs enterprise architecture, but because good foundations compound. AI benefits from them just as much as humans do.

Maybe the truth is that we all wrote our share of slop before AI existed. Every single one of us.

The difference was that we actively tried to get better.

Today, I'm hearing a different question:

"Why should I study this library if AI can do it for me?"

That's the part that worries me the most.

We're delegating our knowledge accumulation, and our skills are slowly atrophying because of it.

If you ever feel this happening, the remedy is personal: take a break, study a library without opening a chat window, learn a new language from a book, and code like we used to.

Not because AI is bad.

Because understanding still matters.

Moving From Silos to Teams

In the workspace, I think we need to humanize the development process again.

For me, that looks like more pair programming and more synchronous code reviews.

We need to break down the silos and move knowledge back into the team. For non-trivial tasks, the author and the reviewer should look at the code together. And I think we should enforce one simple rule:

If you submit a PR, you should be able to explain exactly what it does and why.

That forces us to review our own work. It sharpens our understanding. It creates opportunities to prompt together, share new AI workflows, and learn from one another instead of from isolated chat windows.

Humans using AI, together.

We are slowly getting lazier and more isolated, and that's exactly why this matters.

It's time to share more, protect the craft, and stay human.