AI is here to stay. Do we want it?
I’m not sure we always want AI, Large Language Models or whatever, but we surely need it from time to time. Before I used it, I worked fine without it. Now I would not want to program without it next to me.
Vibe coding? Well…no, and I will tell you why. A useful tool, placed next to other breakthroughs in programming over the decades, such as compilers, abstraction, OOP (or as I like to call it, Objectively Overengineered Problems), the web stack and so on? Of course! It does not replace knowing what you are building.
Vibe coding does not give me good vibes
Ideas are free. Implementation is what counts. That was true before AI, and it is still true now.
What changed is access. Now, more than ever, anyone with an idea also has the tools to at least try to bring it to life. Looking back just four years, to 2022: if you had a brilliant idea for software, a website or anything digital, and lacked the skills to build it, your idea might not have seen daylight. If you were not a programmer, you could not program, and if you were not a writer, you could not write a book.
Now all of that is a few prompts away. Your idea becomes written text (or audio recordings) that you give to an AI model, and the model uses it to start your grand project, your grand app, your grand website. Of course, before long you will rise to the sky like Pegasus, or rather like a unicorn, if you manage to get your hands on some sweet Silicon Valley money.
That access is good news. But a saying goes around: anyone can build a working app, until the first real user shows up. It is half truth and half myth, but mostly true.
A model can produce something you can look at and click through. The gaps appear in what matters: performance with hundreds of simultaneous users, protection of sensitive data, and fixing a critical production bug without breaking ten other features.
A working interface is not a product. It is a prototype, the shell. The product is inside, and building the inside takes solid technical knowledge.
That is why vibe coding, or in short, do-something-without-knowing-what-you-are-doing, is a concept that looks great if you want to brag on YouTube or TikTok. It does not pass the real test: is the application production-ready?
Building a prototype is like building a kit car in your garage. It drives down your driveway just fine. Production-ready software is a car that passes crash tests, has working airbags, handles heavy rain, and holds 80 mph (130 km/h) on the highway for five years without the engine failing. Feeling safe already?
The core idea is simple. If you want to build something that lasts, you cannot just vibe code. You need to use architect mode.
Any software without a solid foundation will crumble. That is why I do not believe in vibe coding for big projects: big projects are built by architects, and although an AI model might prove to be an excellent pen, that pen still needs a human hand to guide it.
A hyper-caffeinated junior developer
I often think of an AI coding model as an inexperienced junior developer who always wants to help. It runs on an unlimited supply of good coffee and rarely asks a question unless it has to. What is not to like?
Picture a junior who has memorized every programming manual and all the documentation on the internet. They write code faster than any person and work around the clock. But they have no real experience, do not know what technical debt is, and too often give you the answer you want to hear instead of the correct one. Congratulations, you have just understood what an AI model is when it comes to programming.
Like any junior, a model needs a senior developer to review its work. With AI, that review matters more. Three habits to watch for:
- Confident wrong answers. Like an eager junior afraid to say “I don’t know,” the model can invent API methods, outdated library parameters or packages that do not exist, rather than admit it is stuck.
- The big picture: Models see only a slice of your system, even with tools that read the repository.
- Over-engineering simple problems. Ask for a small fix and you may get the whole function refactored into a complex design pattern you did not ask for.
With the right guidance, this junior does useful work, and some of it faster and better than we do:
- Drafting boilerplate. Repetitive CRUD operations, standard API endpoints and basic HTML/CSS structures, in seconds.
- Writing unit tests. Dozens of test cases for simple utility functions that developers dislike writing.
- Translating syntax. Converting Python to JavaScript, or updating old syntax to current standards.
- Explaining dense logs. Paste a 100-line stack trace and ask where the null pointer is.
I will talk more about how to use an AI model in programming in another article, because there is a lot to discuss and I do not want to say something now and then repeat myself later. And since we are on the subject of repetition, here is an area where AI models shine brighter than a smartphone screen at 3 a.m.
All your repetitive tasks are belong to me
If the developers of Zero Wing had had access to an LLM back in 1991, gaming history would have lost one of its greatest memes. But while AI is exceptional at preventing atrocious translations, its real programming superpower is far more practical: conquering grunt work. If a task is predictable, repetitive or mind-numbing, AI is ready for it.
AI does not replace developers. What AI does is take over friction work that needs no creative thought, so developers can spend their time on architecture and business logic.
Programming has always carried a hidden setup tax. Before you write the first line of real code, you wire up data models, configure environments, map interfaces and glue APIs together. The work is necessary, and rarely enjoyable, except for the few weirdos among us.
Nobody went to computer science school or learned to code just to spend three hours mapping 50 API fields by hand. Offloading this is a net win for developer happiness.
These tasks are perfect for our little AI robots: predictable, repeatable, the “brainless” tasks, as we used to affectionately call them. Models are trained on millions of lines of code, perhaps billions, and work by pattern recognition and predicting the next token. That makes them experts at ingesting tons of data and processing it to fit everyone’s needs.
Take a catalog of 1,000 e-commerce products. Reformatting descriptions, generating SEO metadata and mapping categories can take a team about three weeks by hand. A model can produce a first pass in about five minutes, and a developer then reviews it.
The same applies to a legacy codebase. A model can refactor hundreds of deprecated API endpoints or update thousands of lines of syntax overnight. A month of tedious migration becomes a few days of pull request reviews, and that review is the part you cannot skip.
What to ask before you hand over real work
If you are about to hand a real product to a development partner, the useful question is not whether they use AI. It is who owns the result when AI wrote part of the code.
AI changes how fast code gets written. It does not change who is responsible for it. We take responsibility for every line we ship, whether a developer typed it or a model drafted it.
Ask any team you consider three questions:
- Who reviews code that AI wrote, and what must it pass before it ships?
- Which tasks go to AI, and which stay with senior developers? Architecture, security-sensitive logic and data handling are the ones to ask about.
- When a critical bug appears in production under real load, who fixes it, and how fast?
The right answers depend on what you are building. If you need a prototype to test an idea this month, a vibe-coded draft may be enough. Treat it as a prototype, and plan the rebuild before real users arrive.
The takeaway: use AI for repetitive work, and keep experienced people responsible for architecture, security and review. The speed on routine tasks is real. The judgment on the foundation is what keeps the product standing.