About Using AI Humanly

AI is an incredibly powerful tool, and it has definitely changed the way we work. We are becoming more dependent on it every day. 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, things have moved fast, especially for developers. A lot of us are looking for the ultimate workflow to avoid writing code manually and delegate the job to agents. Fair. Who wants to grind through work when something can do it for you?

But 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 it stays that way, 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

It is easier than ever to use a complex library or work inside a domain we haven't fully mastered. Things that once required study and a lot of practice can now appear after a single prompt. It is tempting to treat that as the end of the work. Done. Ready to ship. Sell it to the client: now!

There is a small flaw in that logic.

If it is that easy for us to prompt, the customer can do it too, and eventually they will. Somebody who truly understands the domain will still do a better job than somebody who doesn't. Our value cannot come only from the act of writing code. It has to come from understanding the problem well enough to know whether the generated solution is actually the right one.

Lately, I've also noticed how easy it is to become less careful about the quality of AI output. The excuse is usually a familiar phrase:

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

To me, that's a big red flag. A POC doesn't need to be perfect, of course. But I have seen enough "temporary" code become permanent to know that we should care about how it starts.

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 and under tight deadlines, but also because I was learning and didn't know a better way yet. That is part of writing software: you do it, you see what could be better, you refactor it, and the next time you do it better. I still feel guilty about some old projects, and I cannot wait to get my hands on them again. We wrote slop before AI existed, we still write it, and we will write more. We are human. We are not perfect. The point was never perfection; it was caring enough to notice and trying to improve.

I started coding before AI entered the picture, when IntelliSense felt like real magic. Now that we have frontier models at our disposal, it feels strange to use them as an excuse to care less about structure. If AI is doing much of the typing, shouldn't we have more time to think about what we are building?

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

If we don't know a technology, perhaps the first thing to do is talk to somebody in the team who does. Discuss the approach. Ask for help with the plan. Decide together which technology makes sense. At least then the POC has a solid base and a real chance of becoming an MVP, rather than just a good demo that somebody will have to untangle later.

Working in an agency, I hear the phrase "If it works, it's good" constantly. But what does that actually mean?

If an unmaintainable AI-generated POC makes it all the way to production, everyone can celebrate the quick win: "Look, Ma, no hands!" But we may be setting ourselves up for a much bigger loss later.

And who pays for it?

Usually the developers who have to maintain it, debug it, and build new features on top of it. Sometimes they are not even the same people who created it 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. Maybe in six months there will also be no hunger, and we will have a cure for all the world's ills. Sure.

I hope the models improve. I expect them to. I use them every day, so of course I want them to get better. But waiting for the next model is not a plan, and it will not make a poor engineering decision disappear.

What worries me is that this mindset can creep into engineering teams at every level. Agentic coding is still new enough to be fascinating, and not everyone has had the opportunity to see where it fails. I don't blame anyone for being excited by it. I am excited too. I do think we need to be able to discuss the risks openly, regardless of seniority, and review the decisions that will matter later instead of spending all our energy on names and spacing.

Please don't get me wrong: I use AI daily and extensively. I pay for several subscriptions out of my own pocket. I am somehow addicted to it, if you want to put it like that. It has helped me revive my graveyard of unfinished side projects and convinced me that I might finally complete all of them. Spoiler: false.

I am not anti-AI.

I am against using AI as a substitute for understanding.

The Law of Environment

What does using AI humanly even mean?

To me, it means giving power back to the developer. It means rewiring our brains to understand what we are shipping. We have done this for ages, so why should we stop now?

One thing I've noticed is that AI works beautifully in properly structured environments and does a horrific job in messy ones. Give an agent a repository with clear patterns, thoughtful architecture, and consistent conventions, and the result can be impressive. Give it slop and, well, it happily produces more slop.

I have reviewed code produced without a full understanding of every detail. Still, the result was good because it lived inside a repository built with care, clear patterns, and strong constraints. The environment guided both the agent and the developer toward a better result.

This is why I care so much about the environment. AI amplifies whatever we give it.

I think POCs should start with a product mindset. This doesn't mean that every prototype needs enterprise architecture. It means remembering that the starting point sets the patterns, the ideas, and eventually the way of working. A good base helps the humans, and it helps the AI too.

So no, the difference before AI was not that our code was always good. It wasn't. What mattered was that we noticed, learned something, and tried to make the next thing 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 too much: not only the work, but the accumulation of knowledge and, worse, our ability to accumulate it. That is where cognitive laziness starts for me.

I don't think there is a bulletproof solution. Most of it depends on each of us. If you feel it happening, take a break. Study a library without opening a chat window. Learn a new language from a book. Do what you were doing before the agentic era, at least for a while. Not because AI is bad, but because understanding still matters.

Moving From Silos to Teams

In the workplace, I want us 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 have one simple rule:

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

This means reviewing our own work and rebuilding the context we may have delegated. But it also means prompting together, sharing tools and new AI workflows, and learning from one another instead of sitting alone in our chat windows.

Humans using AI, together.

Together. That is the important part.

We are slowly becoming lazier and more isolated, myself included. I don't think the answer is to use less AI. I want us to use it with more care, share more of what we learn, and remain responsible for what we create.

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