THE Vibe Coding Book

“The modern software developer has become a poet, their audience—AI”

me

I have come around to reading a book on “vibe-coding.” I was mid doomscroll when I found a meme about an average web developer heralding this book in the future. I also saw it was on O’Reilly1, which my university has free access to.

So I gave it a shot and read through Beyond Vibe Coding. The book and author are surprisingly lucid on the topic of “AI Coding” and even more surprising that the book itself was not vibe-coded— at least in some chapters2.

The book itself touches on the “vibe-coding vs. AI assistance,” the current limitations of AI, and some practical tips. It is currently still WIP, so it’s a short read. Here are my thoughts on each chapter.

Ch 1: Vibe Coding

There is a difference between “vibe-coding” and having it assist you. “Vibe-coding” is when you have a hazy outline of what you want the computer to do, but have a good understanding of how you want it to “behave.” That is, you are an abstraction above simply “speaking” to the computer, you just want it to “do” what you want it to.

“AI-assisted” coding then is helping you express what the computer should be “thinking” and not simply its “behavior.” That is, you prioritize how the computer is “computing” its outputs rather than just behaviourally verifying it.

Programming with Intent

This section irked me, given the preceding discussion of “vibe-coding” vs. “AI-assisted.” Osmani claims that the two are distinct on the basis that vibe-coding is more “intent” based than AI-assisted programming.

I, frankly, think this is an incorrect separating factor. Normal programming and vibe-coding both express intent; One in code syntax and the other in English. The real distinction is how much you can assume the program you interact with knows to interpret your syntax. Hence the real distinction is “declarative” vs. “imperative.”

Domain Specific Languages

This topic wasn’t in the book, but I wanted to reflect on it without making a whole other blog.

Domain Specific Languages are declarative languages whose syntax is used to express “intent” in a very specfic “domain.” Because of that property, they are highly effective and useful for doing specific operations, in many ways similar to English.

HCL (Hashicorp Configuration Language), SQL (Structured Query Language), YAML (Yet Another Markup Language), and friends are examples of DSLs. These languages are powerful, and people use them everywhere because they are simple. Ultimately, though, what an AI does is different from “imperative” and even “declarative” coding, which is why I’m skeptical.

Transpilation

Consequently, many people treat “AI” as an English-to-code transpiler. I think that’s a wrong view. Even though you can input English and get whatever syntax out, it still isn’t doing what a typical “transpiler” does.

The mathematical idea of a formal translator has been shot down by this image:

Secondly, even if you say the code generation is a declarative transpiler, it doesn’t maintain intent “isomorphically” to whatever language you wanted it to generate.3

CH 3-4: 70%/30%

70% Problem

AI is still not a “silver bullet.” It has not solved the problem of “essential complexity”, rather helps along with “accidental complexity” and in many cases even contributes to it. The “70% problem” here is the idea that AI can get you 70% of the way, but after a critical point, any more usage simply fails.

The common scenario of vibe-coding is that it will easily generate an MVP for you, but as features start to add up and many more chats are spawned, it will ultimately collapse. This phenomenon is largely due to the fact that the AI might understand your intent, but not the “10,000 ft” view of what you’re trying to express.

Diagram as Code

The solution to the above problem, and frankly, when there will be no more human software engineers, is when AI can take “Diagram as Code.”

You see the same thing in the “No-code” space for web design, where all you need is a web designer constructing UI interfaces using UX principles. Traditionally, you would have a web developer build out the UI because under the UI is a web browser that intakes HTML/CSS/JS.

So all the jobs left are the ones that do “conceptual” work, a layer above what we would call “developer” work; Essentially, they only care about if the app is functioning how it’s supposed to, not how it is functioning.

Diagram as Code is that, but for “system design.” The idea is that all you would need is a software architect that understands how to wire everything up conceptually; Have them draw a diagram of that system and pass it into some AI tool that writes it all, deploys it, and tacks on all the extras you want. Ultimately, a CEO could describe a business function and have the AI build out the system.

The 30%

Given the previous chapter, it is no surprise that the author then advocates to learn more of the “conceptual” ways that abstract the underlying software developer, in other words: become a designer.

Funnily enough, I have read 3/4 of the books the author recommends:

There is a disclaimer, though, and a rather lucid one. The fact is that having well-founded and solid software developer skills will never hurt in the long run. It would be incredibly easy to offload “critical thinking” to an AI, but incredibly hurtful, especially in your early career, to do so.

It’s not like debugging as a skill is going to go away; I, for one, think it will now be the most important skill. And to do debugging, you actually need to know the syntax and a conceptual understanding of the language. So yes, AI is coming, but I still believe it is a tad-bit overhyped.

“You can teach a physicist finance, but you can’t teach a finance person physics.”

Jim Simons


  1. Not the auto parts company. ↩

  2. You can tell because there are still very human typos throughout, unless that is to trick the reader. ↩

  3. In a way, you can say it is declarative, but still a bit iffy, I think conceptually. ↩