Code got cheap. Knowing why didn't.

Let me say this first, so the rest doesn't get misread: I'm a big fan of what AI makes possible. I've built several products with it that solve real problems for real people. This website was vibe coded. I use these tools every day, and most days they still surprise me.

I'm not against the change. I embrace it, and I try to learn from it as fast as it moves. But the more I use these tools, the more convinced I am of something that sounds almost old fashioned. The process changed. The craft still matters, maybe more than ever.

Nobody is an expert

I'll start with an unpopular opinion. I don't think there are AI tool experts. Not really. Anyone who calls themselves one is, at best, stretching the truth. How can you be an expert in something that changes every single day? What you mastered last month might be obsolete next week, and the thing that didn't work in spring might be the best option by summer.

That's not a complaint. It's just the nature of this moment. And in my opinion, the only attitude that actually works right now is the humility of being a permanent learner. Try things, break things, stay curious, and be ready to drop a habit you were proud of a few weeks ago. The people I see doing well with AI aren't the ones with the most certainty. They're the ones who keep asking questions.

The industry changed, and it isn't going back

It's hard to deny that we're living through a disruptive moment. The industry as we knew it is gone. Teams are smaller. There are fewer engineers and fewer designers in the room, and a lot of the work that used to take a squad and a quarter now takes one person and a long weekend.

That should make business decisions more surgical, not less. When you have fewer people, every choice about what to build carries more weight. There's less room to absorb mistakes, and less time to notice them.

Instead, I've seen the opposite. I've seen businesses push vibe coded features straight into production, on top of products that were already stable. No supervision. No QA. And many times, which is the worst part, without even knowing why they were building that new feature or that new module in the first place. Speed became the goal, and the reason got lost somewhere along the way.

Generating code got cheap. Knowing what's worth building didn't.

Made with AI doesn't mean good, or bad

Not everything made with AI is good. And using AI doesn't make your process bad. Both of those things are true at the same time, and the people who only believe one of them usually end up in trouble.

It all comes down to balance. Success, at least the way I see it in day-to-day work, is having enough experience to find the middle ground. When is the win worth the cost? What are the trade-offs of automating this particular process? Does the person using the product actually benefit from it being automated, or does it just make our life easier?

Those are valid questions, and there are no wrong answers to them. Sometimes the answer is to automate everything. Sometimes it's to automate a part and keep a person in the loop. Sometimes it's to leave it alone. What worries me isn't any of those answers. It's skipping the question.

When everything looks the same

We're in a time when building products and interfaces is easier than ever, and because of that, most of them are starting to look the same. Same layouts, same flows, same tone, same features, sometimes released in the same week.

That's exactly when it matters most to go back to the starting point. Who am I building this for? Why do they need it? And in a world where working lines of code are cheaper than ever, will that person actually want my product?

That last question deserves more attention than it gets. If generating code is now cheap and available to almost anyone, why would someone pay for what I built instead of building their own solution, made to measure, in an afternoon? They know their problem better than I do. The user always knows the problem better than the person building the product. That has always been true, and now they also have the tools to act on it.

Craft is the difference

So what's left to offer? I keep coming back to the same answer: craft. The process evolves, but knowing the trade is what turns a product into something solid and reliable, something a person would actually pay to have.

If it isn't secure, if it isn't well made, there's no difference between your product and the one someone could generate on their own. And there's a trap I've watched teams fall into more than once. AI generated code introduces bugs. Those bugs get fixed with more AI generated code, which introduces new bugs, and so on. Every round looks productive. Every round adds a little more slop. After a while nobody really understands the product anymore, and that's the moment it stops being trustworthy.

Users notice. Maybe not right away, and maybe they couldn't explain it, but they feel it. Something breaks that used to work. A flow that made sense now has an extra step nobody asked for. Trust leaves quietly, and it's very expensive to bring back.

The question we keep skipping

In an era of this much speed, I think we're forgetting to ask ourselves, again and again, what the value of our product really is, and why. Not once at the start of a project, but constantly, every time we're about to ship something new because it's now easy to.

Why should a person pay for this, if they understand their problem better than we do and can build something for themselves? I don't think that question has a single answer. But I'm sure that the teams who keep asking it, with humility and with real knowledge of their craft, are the ones whose products will still be worth using once everyone can build.