Circa 370 BC, Socrates famously worried that with the advent of writing on wax-coated clay tablets, people’s cognitive faculties would henceforth decline, since people would not have to remember things any more! And even if people wrote down mistakes, they would now be able to easily correct them, which would lead to people being less careful. Ironically, we only know of this because Plato wrote it down in Phaedrus.
Today we are having the same discussions about vibe coding (rolls eyes).
There is a lot of talk about how to responsibly approach vibe coding by software engineers. I see a lot of professionals either dismissing vibe coding altogether, or embracing it without thought for its consequences. Perhaps the most well-articulated approach is the Outcome Engineering manifesto by legendary engineer Cory Ondrejk.
Observations on vibe coding
After vibe coding an entire app from scratch with only minimal coding on my part, this has prompted me to jot down some thoughts and observations, some of which are my own and some I have found online:
- Vibe coding is the future. It’s not just a fad. You can’t deny the speed and quality benefits. Intelligence is now a commodity. Anyone who doesn’t adapt will be left behind. This worry is reflected in a lot of worrying that I see online by some professionals who think their line of work will become obsolete. The tractor didn’t make farmers disappear (although it did reduce their numbers). The internal combustion engine did reduce the numbers of beasts of burden, but I would argue that’s a good thing, and that’s how we should view coding agents. There will be less junior software engineers and more software architects.
- Vibe coding is a misnomer. It’s not just about the coding (implementation). Systems that exhibit general intelligence can and do assist in all stages of software engineering, not just implementing (coding). Requirements analysis, design, implementation, testing, deployment and decommissioning are all stages where AI can help. Even with the help of AI, requirements gathering is the basis of the art of our profession. For example, the agent won’t know to build a secure and maintainable system, if all you’ve communicated are your functional requirements, forgetting about the non-functional requirements. This is a classic error that novice programmers did even before agentic workflows: software engineering is not the same as coding/programming!
- Sometimes the agents make silly mistakes. Sometimes you have to hold their hand to help them with silly tasks. But other times they will surprise you by spotting hard-to-find bugs, or by thinking outside the box to find novel solutions to problems you didn’t even know you had! As an engineer, you should definitely keep control of your project, and inspect the agent without trusting it blindly. This is where I agree with the o16g manifesto 100%. For example, I like to do the version control manually and look very carefully at diffs using meld at every step. Agents are an interesting mix of smart and stupid. Today Antigravity saved me days of work in just a few hours, by implementing a complex callback mechanism between threads that needed to communicate asynchronously. It did this in seconds when it would have taken me an entire morning. But it also deleted a critical piece of code in my codebase without ever saying why. Without checking the diffs I wouldn’t know. Code review is still a thing!
- It’s best to treat your AI agent as a colleague. Give it context. Ask it open questions. Let it have opinions on what you should build and why. This is where I think o16g will soon look antiquated by the next breed of software engineers. As AI agents get smarter and smarter, they will be suitable to take more high-level decisions. You are now a software architect, and the agents are very good implementers, but they can also contribute to your high-level vision, so listen to their feedback.
- Software engineering is not dead. You still need to know about revision control, issue tracking, methodologies, different types of testing, software metrics, etc. All too often I see people online complaining “Claude code deleted my entire codebase”, and other professionals ask them why they can’t revert to an earlier stage, only to find out that this new breed of vibe coders hasn’t even heard of git! Part of the spectacular failures that we often see in the vibe coding space, are actually user errors.
- Vibe coding will be pervasive. It is not suitable only for this or that type of app. Whether you are writing mission-critical Linux kernel code, or an app for uploading cat videos, eventually AI will have a part in it. Not because it can do magical things that you can’t do, but simply because it’s faster. Just be responsible about it, and embrace the acceleration!
- We are increasingly becoming reliant on a service offered by OpenAI, Anthropic, Google. This is not good, but also not terrible. As long as it’s possible to run local models on GPUs, we can still own the means of production. Even if you yourself are relying on online tools, the fact that some people can run the models locally places an upper limit on what these companies can charge for their services. So I’m a little worried about this trend, but not too much.
Comic relief
It’s a big adjustment. Don’t underestimate it. Don’t ignore it. You will get used to it. It’s not an existential threat. And no, we can’t go back. In fact, if you are an AI naysayer, 1289 is not the only xkcd I recommend. I also recommend 1227 and 1601. So don’t be that guy (or gal)!
Conclusion
If you are not building an app every month you might fall behind in productivity. But it’s such an exciting time to be alive. Software will become cheap, but quality and accountability still matters.
If you have good ideas, if you can identify products that need to be built, if you can produce reliable software faster, and if you can market them, then you are good.
In fact, I am excited about agentic workflows that will offload the marketing effort, because that’s what’s hard about professional software engineering. Building was always the easy part, and has now become easier. Monetizing software was, and still is, hard!