The Vibe Coding Phenomenon and Why This Book Matters
I stumbled upon Beyond Coding by Addy Osmani quite coincidentally through a LinkedIn post. The post immediately caught my attention because vibe coding and how AI is transforming the software engineering industry is dominating discussions nowadays. Hundreds, if not thousands, of posts on LinkedIn and videos on YouTube are dedicated to this hot topic.
The discourse around vibe coding tends to be polarized into two opposite camps. On one side, most people rave about the magic of vibe coding—how easy it is to create very cool applications, most often games, with one or a few prompts and without writing a single line of code, or without any prior knowledge of programming, let alone software engineering. On the other side stand the pessimists who question the viability and sustainability of this approach.
My initial reaction was dismissive. I thought to myself that this is yet another book jumping on the trendy topic of vibe coding. However, the fact that this book is published by O'Reilly gives it credibility. I've never been disappointed by a book published by this editor, and their reputation for quality technical content is well-earned. This publisher's endorsement was enough to pique my curiosity, and I decided to read the book to see what it had to offer.
Vibe Coding vs. AI-Assisted Software Engineering
One of the most valuable contributions of Osmani's book is the distinction he makes between vibe coding and AI-assisted software engineering. Understanding this difference is crucial for anyone working in or entering the field.
Vibe coding, as the author defines it, is building an application with one or a few prompts, without writing a single line of code and without the need to know anything about programming, frameworks, or libraries. This approach has democratized the creation of apps and made this activity accessible to anybody, regardless of their technical background.
AI-assisted software engineering (AISE), on the other hand, is more than coding, as the name already hints. In AISE, the engineer is still in the loop and their job goes far beyond prompting AI. Hence the title of the book, "Beyond Coding." I prefer the term "AI-assisted software engineering" to "vibe coding." The latter expression might make many people believe that it is now possible to build production-ready, reliable, secure, optimized, and maintainable software by writing a single or maybe a couple of prompts and then AI will take care of everything else for you.
The book reveals that about 97% of developers, according to some study, have already embraced AI in their daily tasks. Osmani classifies these developers into two categories: bootstrappers and iterators. Bootstrappers will typically scaffold an application—either a prototype or a minimum viable product (MVP)—then they might fall back to a more traditional, AI-free software engineering process. Iterators, on the other hand, use AI as a pair programmer. AI helps the engineer with scaffolding the app, then implementing routine features like a CRUD API, writing unit tests, and typically performing tasks that are usually delegated to junior engineers, but not only those tasks as we will see later in this post.
Osmani provides another classification, this time of AI usage in companies. He defines three classes: AI as a first drafter, where AI is used to quickly scaffold a new application and the engineering process then resumes in a traditional way; AI as a pair programmer, where AI is involved in advising on design decisions, implementing rote tasks, writing unit tests, and documenting the code; and AI as a validator, where AI is mostly used as a code reviewer.
The author also introduces the concept of intent-oriented programming, where users and engineers communicate their intent to AI. This is often called prompt engineering or the art of prompting. I personally prefer the expression "art of prompting." This is about communicating very precisely and in a structured way one's ideas, intentions, and expectations. It is a must-have soft skill from now on. A chapter of the book is devoted to this art of prompting, but ultimately this cannot be learned in a conventional sense. There are general guidelines to write good prompts, but as LLMs keep changing rapidly, techniques that are necessary today might not be in the future as LLMs become more sophisticated. Though, I doubt that LLMs will be able to read the mind of an engineer anytime soon. Telepathic AI is not around the corner, yet.
Best Practices and Warnings for Professional AI-Assisted Development
The author provides multiple pieces of advice and tips to effectively use AI in a professional environment. Here are some key takeaways that stood out.
Engineers must be very responsible when using AI. Osmani insists throughout his book on the fact that code generated by AI needs to be carefully reviewed. One should never trust AI, especially on critical tasks like sanitization of input, security, and non-trivial algorithms. AI never takes blame—the engineer using the AI becomes the owner of AI-generated code as if they wrote it themselves.
Engineers must never merge AI-generated code that they do not understand. This is also a great learning opportunity for engineers when the AI slightly pushes them outside of their comfort zone by using technologies that they are not familiar with. When AI is used to scaffold an app, the dependencies installed by AI should be reviewed. AI tends to use older libraries that were the latest version when the models were pre-trained. Older libraries might have security vulnerabilities. Conversely, when AI uses a relatively new library, it tends to be not good at using it since it did not see many usage examples in its training data. Engineers should be aware of this weakness and review the code carefully.
Developers should not delegate critical parts of the app to AI, like authentication. Multiple models have different strengths and weaknesses, and developers should have a sense of these and use the right model for the right task. For example, chatbots like ChatGPT tend to be better than coding agents in brainstorming tasks. One model can be used to review the code written by another model, though human reviews are still mandatory. Some teams tag their commit messages with "AI" or "AI-assisted" to let other team members be aware of AI-generated code and pay more attention when reviewing pull requests.
Engineers should resist feature creep. Instead of constantly adding new features to a product, current code needs to be reviewed, refactored, and tests written. In a nutshell, the current AI-generated code needs to be hardened and made production-ready. Some teams alternate between AI-assisted sprints and AI-free sprints to maintain code quality and team skills.
Engineers need to be aware of skills atrophy and they need to code now and then to stay in the loop. Technical debt will very likely accumulate very quickly in projects if engineers are not careful. The extra time that engineers have thanks to delegating routine coding tasks should be used to learn new skills—for example, UX for backend developers, security, new libraries, and frameworks. Engineers will be moving from coders to system designers, architects, and product owners at the same time.
Practical Applications and Personal Takeaways
The author walks through the steps to develop a two-tier web application and demonstrates how AI can be used in each step of the development lifecycle. AI can generate initial UIs from mockups, and some tools exist to this effect. AI can be instructed to write more unit tests to ensure coverage of say at least 80%. AI can scan code for security vulnerabilities, debug issues, and fix bugs. AI can even be integrated into CI/CD pipelines to scan for anti-patterns, security vulnerabilities, and other issues—it's like a linter on steroids.
In conclusion, the book offers a balanced view on AI-assisted software engineering. The tips in the book come from how various teams are using AI in the real world nowadays. The author is a director at Google Cloud AI, and it seems he still codes despite his managerial duties, which adds practical credibility to his insights. The book is exhaustive—it did not leave any aspect of software engineering uncovered, or at least just a few slipped through the net.
Reading "Beyond Coding" inspired me to integrate a bit more AI into my workflow. I used two supervised AI agents to create an application from scratch to manage my personal collection of books. Like 95% of the code was written by AI; however, I tried to apply the advice in the book as much as possible, instructing AI, for example, to refactor many pieces of the code to abide by known design patterns. I also experimented with an autonomous agent, Google Jules, in another project. I will post about both experiments in subsequent posts.