From Googlevelopment to Vibe Coding: The Amplifier Problem

Thirteen years ago, I wrote a blog post called “Ask a Ninja: Is the Googlevelopment Approach Bad?”. It was a response to Rick Strahl’s “The Search Engine Developer” and Scott Hanselman’s “Am I really a developer or just a good googler?”. We were all wrestling with the same question: Is it okay that we Google so much of what we do? Are we still real developers?

Back then I coined the term “Googlevelopment” and argued that the answer depends on where you are in your journey. Young Padawans should fiddle on their own. Knights should use the force and learn from it. Master Jedis should go back to fiddling again, but at a higher level. I used the German craftsman tradition — Lehrling, Geselle, Meister — and the maxim I share with friends: “Schau in Dich. Schau um Dich. Schau über Dich.”

I still stand by all of that. But the world has moved on, and the question has changed.

From “Am I a developer or just a good Googler?” to “Am I a developer or just a good prompter?”

Nobody talks about Googlevelopment anymore. In 2026, the term is “vibe coding” — a phrase coined by Andrej Karpathy earlier last year, where you describe what you want to an AI, it writes the code, you run it, and if something breaks, you paste the error back in and let the AI fix it. Rinse and repeat. You don’t really read the code. You don’t really understand the code. You just… vibe.

And I get it. I really do. I work with AI every single day. I consult companies on how to integrate Generative AI into their workflows and products. I use Claude, I use Copilot, I build with LLMs professionally. I’m not some old guy shaking his fist at the cloud (pun intended). AI-assisted development is here to stay, and it can be incredibly powerful.

But here’s the thing that keeps me up at night, and the reason I felt the need to revisit this topic after thirteen years:

AI is an amplifier. It amplifies whatever you bring to it.

If you know what you’re doing — if you have twenty-plus years of understanding why code works the way it does, if you’ve debugged race conditions at 2 AM, if you’ve felt the pain of a poorly designed architecture in production — then AI carries you further than you could ever imagine. It’s like strapping a jet engine to a car that already has a solid chassis, good brakes, and a driver who knows the road.

But if you’re a novice? If you’ve never had to understand why your dependency injection container behaves the way it does, never wrestled with a memory leak, never had to think through the implications of a design decision without someone (or something) handing you the answer? Then AI amplifies your Unwissen — your lack of knowledge. And the result isn’t just bad code. It’s a lot more bad code, produced at incredible speed, with a confident sheen that makes it hard to spot what’s wrong.

That’s qualitatively different from Googlevelopment. And it’s way, way worse.

Why this is not the same as Googlevelopment

When you Googled something in 2013, the process had built-in friction that was actually healthy. You had to formulate a search query — which meant you needed to at least vaguely understand the problem domain. You got ten blue links, most of them mediocre. You had to scan results, evaluate quality, maybe click through to a StackOverflow answer with 47 upvotes and a comment thread where someone pointed out an edge case. Then you had to read the code, understand it, and adapt it to your situation.

That friction was a teacher. It wasn’t fun, but it forced you to engage with the material.

Vibe coding removes all of that friction. You describe your problem in natural language — often imprecisely — and get back something that looks complete, compiles, and frequently runs. The feedback loop is so fast and the output so polished that there’s almost no reason to slow down and think. And that’s exactly the problem.

There’s another crucial difference: When you found code on StackOverflow, it had provenance. A human wrote it. Other humans reviewed it. Someone upvoted it, someone commented “this doesn’t work for Unicode strings,” someone else offered an alternative. There was a social quality filter, imperfect as it was.

AI-generated code has no such provenance. It was never tested in a real project. Nobody reviewed it. It’s a statistical best guess based on patterns in training data. It can be confidently, subtly, dangerously wrong — and you won’t know unless you have the skills to evaluate it. Skills you can only build by doing things yourself first.

The Amplifier in Practice

Let me give you a concrete example from my consulting work. I recently saw a team where a junior developer used AI to generate an entire authentication flow. It looked great. Clean code, proper abstractions, even had comments. The AI had generated an implementation using JWT tokens stored in localStorage. For their specific requirements — a web application handling sensitive data — this was a terrible choice. HTTP-only cookies with proper CSRF protection would have been the right approach. But the code worked, the tests passed, and nobody caught it until a security review weeks later.

A senior developer using the same AI tool would have prompted differently, would have specified the security constraints, and — most importantly — would have looked at the generated code and immediately spotted the problem. The AI amplified the senior’s productivity and the junior’s blind spots equally.

Rick Strahl wrote in 2013 that he didn’t miss the old days of figuring everything out on your own. I disagreed with him then and I disagree even more now. Those days of struggling, of typing code without peeking at the solution, of building a sorting algorithm from scratch because you had no choice — those days built the mental models that allow experienced developers to use AI effectively today.

I started programming when I was eight or nine. By fourteen I sold my first program to a doctor — a patient management system. I invented my own sorting algorithm (turned out it was insertion sort, but I didn’t know that back then). I figured out how to talk to a printer. I spent hours formatting output to look nice. It took forever. I learned everything there was to learn about all the little things in that simple application.

That foundation? That’s what makes AI useful to me now. Without it, AI would just be a faster way to produce code I don’t understand.

The Updated Craftsman’s Path

My apprentice-journeyman-master framework from 2013 needs an update. The stages still hold, but the implications are sharper:

The Lehrling (Apprentice) should use AI sparingly and critically. Yes, I said it. If you’re learning, resist the urge to prompt your way through every problem. Write that function yourself. Debug it yourself. Feel the pain. That pain is information. It’s building neural pathways that will serve you for decades. Use AI to explain things, maybe. Use it as a rubber duck. But don’t let it write your code before you’ve proven to yourself that you could write it. You cannot learn to cook by having a chef prepare every meal while you watch.

The Geselle (Journeyman) should use AI as a sparring partner. You know enough to evaluate what it gives you. Challenge it. Ask it “why?” when it suggests something. Use it to explore approaches you haven’t considered. Let it handle the boilerplate while you focus on architecture and design. But stay in the driver’s seat. Always.

The Meister (Master) should leverage AI to its fullest — because at this level, AI becomes a true force multiplier. You understand your domain deeply enough to prompt precisely, to spot hallucinations, to reject elegant-looking nonsense. You can use AI to prototype in hours what used to take weeks, to explore solution spaces you’d never have time for otherwise. And — here’s the new responsibility — the Master should be setting up the guardrails, doing the context engineering, defining the prompts and the review processes that keep the apprentices and yourneymen safe when they use AI.

Schau in Dich. Schau um Dich. Schau über Dich.

The maxim still holds. More than ever, actually.

Schau in Dich — Look inside yourself. Be brutally honest about your own skill level. Do you understand what the AI just generated? Could you have written it yourself, even if it would have taken longer? If the answer is no, you have a problem, and the AI is making it worse by hiding it from you.

Schau um Dich — Look around you. Learn from others, including from AI, but critically. The AI is not a senior colleague. It has no experience. It has no skin in the game. It won’t be on call at 3 AM when its code breaks in production. Treat it as a very well-read intern: potentially useful, but always in need of supervision.

Schau über Dich — Look beyond yourself. And this is where it gets existential. What happens to our craft — to software Handwerk — if the next generation of developers never has to struggle? If they never build a sorting algorithm, never debug a deadlock without help, never experience the deep satisfaction of solving something hard on their own? Do we end up with an entire generation of developers who can orchestrate AI but can’t function without it? And if AI changes tomorrow — if the paradigm shifts, if the tools break, if the models start behaving differently — what then?

No Angst, just Respect

I don’t want to sound like a Schwarzmaler here. AI-assisted development is genuinely transformative. I’ve seen it make good teams great. I’ve used it myself to accomplish things that would have been impossible in the time available. I’m not calling for anyone to go back to writing assembly by candlelight.

But I am calling for Respekt. Respect for the craft. Respect for the learning process. Respect for the fact that tools — no matter how powerful — don’t replace understanding.

In 2013, I concluded with a joke about the bottom line: “Well. This is just a line. At the bottom. For no reason. :)”. Thirteen years later, the topic is too important for a throwaway punchline.

If you’re a senior developer: Use AI. Embrace it. Let it make you faster. But mentor the juniors on your team, and make sure they’re building real skills underneath the AI layer. Be the Meister who teaches the Lehrling.

If you’re just starting out: Slow down. Yes, you can vibe-code your way to a working application in an afternoon. But “working” and “correct” are not the same thing. Neither are “working” and “understood.” Write it yourself first. Feel the struggle. Then use AI to go further. The struggle is not a bug in the learning process — it’s the whole point.

AI is an amplifier. It is in our all responsibility to make it amplify the right things.