Page 1

(This page has no text content)

Page 2

MEAP Edition Manning Early Access Program Vibe Engineering Best practices, mistakes, and tradeoffs Version 2 Copyright 2026 Manning Publications For more information on this and other Manning titles go to manning.com. © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 3

welcome Dear reader, Thank you for purchasing the MEAP edition of Vibe Engineering. We’re thrilled to have you join us on this journey into the new reality of AI-augmented software development. The rapid adoption of AI coding assistants has changed how we build software—but not always for the better. Many developers are discovering that the apparent speed and creativity these tools provide often come with hidden costs, subtle risks, and difficult trade- offs. This book is your critical guide to navigating that landscape. In Vibe Engineering, we explore the tension between speed and understanding, convenience and control. You’ll learn to identify the illusions of progress that arise from over-reliance on AI tools and how to design processes that preserve human judgment while amplifying productivity. We focus on practical techniques—frameworks for reasoning about cost versus accuracy, scientific methods for validating AI-generated code, and strategies for maintaining high engineering standards in an AI-augmented environment. To get the most out of this book, you should have a basic familiarity with Java (and optionally Python) and feel comfortable using a modern IDE such as IntelliJ IDEA or Visual Studio Code. You’ll also need access to ChatGPT (a free account works fine) and, if you’d like to follow along with the examples, Cursor IDE or Visual Studio Code with the Cline extension. This isn’t a tutorial about any single AI tool. Instead, it’s a field guide for engineers and technical leaders who want to make deliberate, well-informed choices in a rapidly shifting landscape. You’ll find frameworks, not recipes—approaches you can apply no matter which AI coding tool you use. We hope the ideas and case studies in this book will help you and your team build software that’s not just faster, but smarter and more resilient. Please share your thoughts, questions, and suggestions in the liveBook discussion forum—your feedback is invaluable in shaping the final edition. Thank you again for joining us in this exploration of the trade-offs, challenges, and opportunities of AI-powered development. Warm regards, —Tomasz Lelek and Artur Skowroński Authors of Vibe Engineering [Manning Publications] © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 4

brief contents 1 Building on Quicksand: The challenges of Vibe Engineering 2 Building a legacy modernization framework powered by Vibe Engineering 3 Context Engineering: Optimizing context for AI Agents 4 LLM-driven data analytics and visualization 5 Continuous AI development 6 A scientic approach for validating LLM-based solutions 7 Vibe Performance Engineering: When assumptions mislead 8 Evaluation is King: Ultra-tight engineering loop for AI-powered codebases 9 FinOps for LLMs: Cost-cutting, condentiality, and the right chips 10 Code Organization for AI: Tame your codebase with Monorepo & Friends © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 5

1 Building on Quicksand: The challenges of Vibe Engineering This chapter covers The dangers and documented real-world failures of undisciplined "Vibe Coding" The hidden, long-term cost of shipping unverified AI-generated code. The cognitive cost required for developers to build a mental model and truly own AI- generated code. Using human-authored, executable specifications as the central contract to guide and verify AI work. In the new field of AI-assisted development, the software engineering process often feels like it's been pulled from an early-stage R&D lab. Surrounded by language-model APIs, AI agents, and esoteric prompting techniques, we iterate quickly - guided by intuition and an elusive “vibe” - to turn raw ideas into working software. There is nothing inherently bad in this, as the exploratory phase brings tangible value, with faster iteration toward product- market fit and earlier visibility into the dreaded unknown unknowns inherent to every project. However, this activity has a dark side. The practice of Vibe Coding - generating apps at lightning speed but without professional rigor or security awareness - creates an illusion of progress that often fails miserably. Real-world failures, from startups being hacked within days of launch to AI commands deleting entire projects, are painful lessons in the danger of trusting AI-generated code without deep verification. This practice accumulates the invisible, long-term cost of shipping code that no one on the team truly understands or owns. Projects are built quickly… but become unmaintainable almost immediately. 1 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 6

That fragility shows the bottleneck isn’t model horsepower but disciplined engineering. The advantage now goes to teams that can state intent crisply, carve out clean abstractions, and write specs that become testable contracts for agents. This systematic discipline is what we call Vibe Engineering, the proposed answer to the creative chaos of Vibe Coding. But this transition is not a simple panacea. It introduces a new class of trade-offs and potential mistakes. How much verification is too much, and when does it stifle the very speed AI promises? When does a clean abstraction for an LLM become a leaky, expensive constraint? This book is not a simple celebration of Vibe Engineering. Instead, it serves as a critical field guide to the messy reality of implementing it. We will dissect the common failures, analyze the cognitive cost of owning misunderstood AI-generated code, and offer a playbook for navigating the difficult choices you'll inevitably face. Our goal is to ensure the code you ship is not just "AI code," but your own code - resilient and secure, and built with a clear-eyed understanding of the compromises made along the way. 1.1 AIchemy: A new frontier of software creation Ever since LLMs appeared (we probably don’t need to explain what LLMs are - the marketing budgets of VC-funded, billion-dollar companies already did that), the developer environment started to look like an alchemist’s workshop. Each of us, as software engineers, has become something of an alchemist searching for the philosopher’s stone - the perfectly functioning, intelligent application. Instead of alembics, retorts, and mysterious powders, our benches are covered with language-model APIs, vector databases, and esoteric prompting techniques. We mix ingredients with intuition, feel, and that elusive “vibe,” hoping to transmute a raw idea into digital gold. The pace of innovation is dizzying. Every week brings new “recipes” and techniques that promise a breakthrough. The global developer community is running a continuous, large- scale experiment, iterating at unprecedented speed. We’re witnessing an explosion of context-engineering strategies - from simple prompts to complex, multi-stage constructs like Chain-of-Thought (if you don’t know these terms, not to worry - just carry on with the book!). In parallel, increasingly sophisticated architectures are emerging, such as Retrieval- Augmented Generation, which let models draw on external, verifiable sources in an attempt to tame their tendency to hallucinate. On the horizon loom autonomous AI agents that promise to redefine our workflows entirely, taking over whole segments of development tasks. This book is about mistakes and trade-offs coming from discovering a totally new discipline. Modern AI is like every other product of the alchemical era: huge potential, real curiosity, and very little standardization. The chaos isn’t failure - it’s the necessary exploration that precedes a scientific discipline. Like alchemy to chemistry, today’s global experiments (especially the mistaken, failed ones) reveal boundaries and surface the decisions engineers must make: which risks to accept, which costs to pay, what to simplify, and what to keep flexible. In the rest of Chapter 1 - and then throughout the book - we unpack these choices in detail and by analyzing these trade-offs, we outline the requirements for a true engineering practice to come 2 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 7

1.2 Illusion of speed or “Vibe over Engineering” Mistakes and errors ripple through AI projects like background static: omnipresent, easy to ignore, and full of lessons if you listen. In this climate of rapidly evolving tools, “vibe coding” has emerged as a discipline: a lightning-fast, iterative mode of app creation powered by LLMs but often stripped of professional rigor, tests, and security hygiene - essentially trusting AI outputs “by feel” without deep verification. That approach speeds up prototyping, yet shipping it to production is a recipe for disaster. The cases below are not theoretical: they are documented failures that forcefully expose the trade-offs, blind spots, and consequences of mistaking velocity for safety. 1.2.1 A startup hacked within days of launch The story of Enrichlead - a startup built entirely with an AI tool under the slogan “zero hand-written code” - is a textbook. Within days of going live, the app was attacked. API keys were drained, users bypassed subscriptions, and the database was filled with random data. The cause: “textbook security mistakes that a first-year CS student would avoid.” The AI-generated code lacked basic safeguards: input validation, rate limiting, and a robust authentication system. The model produced code that “looked functional” but was utterly defenseless in the real world. 1.2.2 A command that erased an entire project The story of product manager Anuraag Gupta went viral when he used Google’s Gemini command-line interface to move project files into a new folder. The AI failed to create the folder, but, instead of reporting an error, “hallucinated success.” It then proceeded to rename every file to the path of a non-existent folder, overwriting the previous names. As a result, months of work disappeared within minutes. When asked to undo the operation, the model replied: “I have failed you completely and catastrophically. I have lost your data.” 1.2.3 A pull request that turned into a trojan A subtler threat appeared in the NX open-source project, which accepted an AI-generated pull request containing a command-injection vulnerability. The code, which “looked clean and functional,” used pull-request titles directly in shell commands without validation. An attacker exploited the flaw by creating a malicious PR that, when processed by NX’s automation, executed their commands and exfiltrated the package-publishing keys. A compromised release then reached users, stealing GitHub tokens, API keys, and crypto wallets from more than 1,400 developers. 3 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 8

1.2.4 An agent that decided to “clean up” production data Jason Lemkin used a Replit AI agent to build a prototype. Despite explicit instructions to freeze the code and make no changes, the agent autonomously decided the database needed “cleaning.” It deleted over 1,200 manager records, 1,196 companies, and business data collected over months. Worse, the agent initially lied about the possibility of recovery and then tried to cover its tracks by generating 4,000 fake records. These failures aren’t ordinary “bugs”, at least not in the existing sense. They represent a new class of systemic risk rooted in the fundamental nature of LLMs: the absence of a grounded model of consequences. In Enrichlead’s case, the AI failed to model a malicious actor. In the Gemini CLI case, it failed to model the file system’s state and the irreversibility of data loss. In the Replit agent case, it failed to model the business value of the data it was deleting. The pattern shows that the main weakness of “vibe coding” isn’t just incorrect logic - it’s the total detachment of generated code from the physical, financial, and security realities of the system in which it runs. For the sake of speed, we were too quick to sacrifice standard engineering disciplines like testing, validation, and sandboxing. This tendency to ignore the fundamentals is often reinforced by a deeper cognitive trap: a form of technological belief in “free lunches.” For years, this wishful thinking took the form of a conviction that the risks and shortcomings of AI-assisted development would simply vanish thanks to a new version of “Moore’s Law” - that each new model would be an order of magnitude better than the previous one. Yet, we are learning that progress does not come from scale alone. 1.3 The end of scale worship: diminishing returns In recent years, the industry has operated under the promise that most issues with the quality, reliability, or reasoning abilities of language models would simply be fixed by “the next, bigger version.” That mindset - fueled by faith in exponential progress - is coming to an end. The evolution of AI models now resembles the development of CPUs or GPUs: each generation is better, but the gains are iterative rather than revolutionary. We can no longer count on the next model to resolve our engineering challenges. New releases do bring progress, but they are rarely instant hits - more often, they nudge benchmarks slightly and deliver modest improvements to output quality. 4 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 9

This shift is grounded in scaling-law research. Scaling-law research (Kaplan et al. and follow-ons) showed a predictable relationship between model size, data volume, and performance. For a while, it looked like jointly increasing those variables would keep paying off. Today we are running into structural limits that break this simple extrapolation. Data exhaustion is real: high-quality human text on the public web - the fuel for training - has been heavily mined. Pushing scale now means reusing the same data or synthesizing it. Yet repeated passes over the same corpus only help up to a point: after about a few epochs (full passes of the model through the entire dataset), quality gains drop off sharply, and adding more compute provides virtually no benefit. The resulting data scarcity creates a self-reinforcing bottleneck. Our best hope for more training material is to generate high- quality synthetic data with the best models we already have, but the quality and diversity of that data are capped by the generator’s own “world knowledge.” A model cannot teach its successor what it doesn’t already know, and even a perfect generator would still face diminishing returns as volume scales. To get substantially better data we need substantially better models; to get substantially better models we need substantially better data. That circular dependency is precisely why architectural innovation and new engineering methodologies - the emerging “science” of AI engineering - matter more right now than brute-force scale. Commercial incentives reinforce this shift. Vendors are prioritizing lower latency and higher throughput because faster models are cheaper to run and easier to productize at scale. Accuracy still improves, but pushing meaningfully past today’s ceiling gets expensive: the tiers that actually move the needle are priced for enterprises. Think “hundreds of dollars per user per month,” not a $20 hobby plan, for premium access for new state-of- the-art models, if they even show up. The era of broad, heavily subsidized access - floated by recent VC rounds - is winding down, even with VC money still pumping up. Hence the push for throughput-boosters like quantization and sparsity - even with some accuracy trade-offs - see, e.g. Fast Prediction of Job Execution Times in the ALICE Grid Through GPU-Based Inference with Quantization and Sparsity Techniques, GPU-based inference work by Tomasz Lelek et al. The conclusion is straightforward: relying on a larger model to magically fix every problem is a fundamental mistake - wishful thinking, not engineering. Treat LLMs like any other compute primitive - optimize for the job at hand, measure rigorously, and design for cost-aware quality. If model improvements are largely incremental, competitive advantage shifts from having the strongest model to mastering usage: context curation, retrieval, orchestration, testing, and operations. That’s where the curve is still steep - and where investment pays off. Which brings us to the next stage of the story. Once the pitfalls of vibe coding are exposed and the myth of scale has faded, what remains is the task of building a real discipline around AI-assisted development. The raw LLMs are valuable, but without structure they quickly turn chaotic. What we need now is not just more code, but a framework that turns our experimentation into engineering. 5 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 10

1.4 Defining a new discipline: Vibe Engineering The answer to the chaos of alchemy and the dangers of vibe coding is vibe engineering. If vibe coding is alchemy, then vibe engineering is applied chemistry - systematic, rule-based, and grounded in measurable evidence. It’s a discipline that combines the creative power of LLM prototyping with the non-negotiable pillars of professional software engineering: rigorous testing, quality assurance, solid error handling, attention to edge cases, fulfillment of non-functional requirements (performance, scalability, security), and production stability. This concept is an evolution - not a rejection - of timeless engineering wisdom. As Martin Fowler once put it: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” In the AI era, this statement takes on new weight: we must create not just code, but entire systems that are understandable, verifiable, and safe - even when parts of them are generated by a machine. That’s maybe the biggest irony: this entire AI-driven engineering wave has simply reminded us that AI thrives in the same conditions human developers do - systems with clear boundaries, crisp contexts, and a reliable chain of verification. This perspective emphasizes that AI is a powerful tool in the hands of the engineer, not a replacement for them. 1.4.1 Two faces of the vibe: coding vs engineering When the rapid experimentation becomes too costly and the illusion of speed ends in disaster, a practical question arises: how do we tame this new, powerful force? The answer starts with a clear distinction between two approaches that are often lumped together: vibe coding and vibe engineering. This is more than a semantic quibble - it’s the difference between exploration and construction, between a sketch and an architectural blueprint, and choosing between them comes with a set trade-offs. Both are useful, but confusing the two is a mistake, one of the main causes of the failures we described earlier. VIBE CODING: THE CREATIVE FLOW Vibe coding is a dance with uncertainty. It’s a prompt-driven, intuition-first mode in which the developer surrenders to iterative discovery to capture a desired result - the vibe. As Andrej Karpathy put it, it’s the act of “leaning into the vibes, accepting what the AI gives you without checking every line, and if you hit a bug you paste it back into the model - eventually it works.” In that world, intention matters more than implementation detail and the code becomes almost secondary to the dialogue with the machine. Vibe coding shouldn’t be demonized - in the right context, it’s invaluable: the digital sketchbook for rapid prototyping, a fast path to an MVP, a way to explore UI ideas, or a tool for producing repetitive boilerplate. It turns a foggy idea into a working interface in minutes rather than days. Trading off speed for the technical debt - essential at the beginning of a project when you’re discovering what you actually want to build. It’s a form of triage - if you do not know if the particular feature/idea survives in the long term, losing time on solidifying the implementation is a clear mistake. 6 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 11

However, the very strengths that make vibe coding powerful for discovery become its greatest liabilities for production systems. This approach often generates code that is brittle, opaque, and laden with technical debt. Since the developer may not fully understand the implementation choices made by the AI, maintaining, debugging, and extending the codebase becomes a significant challenge. Furthermore, AI-generated solutions are optimized for functional correctness, not performance, security or maintainability. This can lead to inefficient algorithms, unnecessary and complex abstraction layers, poor resource management, and hidden vulnerabilities that are unacceptable in a production environment. Consequently, while vibe coding is an excellent tool for scaffolding, that scaffold must be dismantled and replaced with deliberately engineered, robust, and well-understood code before a project can be considered production-ready. VIBE ENGINEERING: DISCIPLINED PRACTICE If vibe coding is the sketch, vibe engineering is the architectural plan. It’s the deliberate, systematic integration of AI into a mature software lifecycle. This principle is rooted in the fundamental nature of the technology itself. Whether the tool is Gemini, ChatGPT, or Claude, all current-generation LLMs share the same core architecture: they are probabilistic, non-deterministic systems. This shared, inherent weakness is precisely why a provider-agnostic methodology is not just beneficial, but essential. The problem to be solved is not a specific model's flaw that will be patched in the next release but the characteristic of the entire technology class. Crucially, these systems are statistical: they predict likely next tokens, not objective facts, so they do not contain a built-in model of truth. That absence forces engineering trade-offs - for example, increasing model size or temperature (creativity of the model) may improve fluency but raise hallucination risk. On the other hand, adding retrieval improves factuality but increases complexity and surface area for failure. In short, every design decision trades one axis (accuracy, creativity, safety, cost, latency) against another. The discipline of vibe engineering is designed to address this reality directly. It provides a framework to wrap this probabilistic core with a deterministic shell of human intent. The executable specification becomes the rules for agents, and a verifier (e.g. the CI/CD pipeline) becomes the impartial enforcer of those rules. Within this structure, the specific LLM used to translate the specification into code becomes a secondary concern - a choice based on cost, speed, or stylistic preference, not a fundamental determinant of correctness or safety. The shift from alchemy to science is a shift from ingredient-obsession to process- mastery. That’s why “science” of vibe engineering rests on concrete, repeatable, and measurable techniques that form the foundation of this book. These include: Systematic prompt engineering: Provide an LLM with code slices and tests, so the model can return an endpoint/UI that compiles and passes immediately Retrieval-augmented generation and grounded retrieval: A support assistant answers from product docs and release notes it actually cites, cutting hallucinations and surfacing anchors. 7 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 12

PR review checklist: Let the model do a first-pass review using a fixed checklist (input validation, auth, obvious performance issues). It leaves comments; humans approve and own the change. Incident triage: When an error hits, the model summarizes logs, points to the likely file/line, and drafts a tiny, reversible fix with clear rollback steps in the PR. Guarded automation: An agent opens a dependency-update PR with a change summary and test plan. It merges only after required approvals/CI checks and auto-rolls back if health metrics drop. Introducing these techniques fundamentally reshapes the role of the developer - from code author to system designer and validator. The core action is no longer writing individual lines of code, but designing, testing, and safeguarding a complex human-AI system that produces the final artifact - software with proper functional and non-functional requirements. The value of an experienced engineer shifts up one level of abstraction: no longer in manually crafting each part (code), but in designing the factory (a continuous, safe, AI-powered workflow) that produces those parts. However, with solving one set of challenges, here comes the new ones. Even in the best- run teams and projects, AI doesn’t just accelerate familiar work - it also introduces a new class of risk we didn’t face before. As automation scales, human attentiveness tends to erode, and the burden quietly shifts from “doing more” to “proving it’s still safe to do more.” Once the core job is orchestrating a human-AI system, the question is no longer “Can it ship?” but “Can we trust what ships?”. Because when that vigilance slips, even slightly, the system accrues a different kind of liabilities. This flaw is automation bias: our tendency to over-trust and uncritically accept information from automated systems, even when our own expertise might suggest otherwise. It's the silent assumption that the machine is right, which turns a helpful assistant into a potential single point of failure. This growing liability is a new kind of debt we are only now beginning to understand. 1.4.2 Trust: a new kind of debt Every engineer knows the concept of technical debt - the hidden cost we incur tomorrow for shortcuts we take today. In the age of AI, a subtler twin has emerged: trust debt. It’s the accumulated, invisible cost of shipping AI-generated code without adequate verification. Trust debt grows quietly. The initial productivity win is visible and celebrated - new functionality delivered in a day instead of a week. The cost - weeks of a senior engineer’s time spent debugging a performance anomaly, patching a security gap, or refactoring code that violates architectural principles - stays hidden and arrives later. This debt is a direct byproduct of the dump-and-review culture. This approach uses AI to generate a large slab of code, opens a pull request, and implicitly offloads responsibility for verification to the reviewer. It’s classic diffusion of responsibility: the presence of the AI (“the model wrote it”) and a reviewer (“someone will check it”) dilutes the author’s ownership of quality. 8 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 13

It’s the same structural failure we’ve seen with autonomous vehicles - less spectacular in its consequences, but fundamentally similar. There’s also a well-documented human factor at play: when oversight is reduced to rare, high-stakes interventions, vigilance erodes. Psychologists call this vigilance decrement; Human-Machine Interface researchers talk about automation complacency and the out-of-the-loop problem. The mind relaxes when nothing seems to require it, attention drifts, and the signal-to-noise threshold rises. By the time a true anomaly appears, reaction times are slower, working memory lacks the necessary context, and the reviewer must rebuild a mental model under pressure - precisely when mistakes are most costly. In code review, that looks like scanning machine-generated diffs on autopilot, over- trusting green tests, and missing the one invariant violation that matters. Late handoffs amplify this: the human is asked to jump from near-zero involvement to deep scrutiny at the worst possible moment. Without mechanisms that keep humans engaged and informed throughout, vigilance doesn’t just fade - it switches off. A reviewer faced with a monolithic, agent-authored PR is the cognitive twin of a safety driver during an unexpected disengagement. Both are forced into real-time sense-making of behavior they didn’t author, with limited visibility into the system’s internal state. The result is the same: delayed reaction, shallow scrutiny, and a higher chance of missing rare-but-critical failure modes. Just as mileage-driven “it usually works” is not a safety case for cars, “the tests happened to pass” is not a safety case for code. That’s why trust debt is an economic externality of AI-assisted development. The individual who leans on it enjoys immediate benefits - speed and a closed ticket - while the hidden trade-off is that the costs are socialized across the team, disproportionately taxing the most experienced (and expensive) engineers. They become the last line of defense, paying down the debt in overtime and during stressful production incidents. What feels productive at the individual level becomes value-destructive at the organizational level. The discipline of vibe engineering must therefore be aimed at eliminating this tension entirely. We need to resolve the trade-off by mandating a strict replacement of "dump-and- review" with "verify-then-merge" treating all prompts and outputs as fully accountable artifacts, enforcing executable specs as non-negotiable contracts. The goal isn’t “no debt” (that’s impossible) but a deliberate, auditable workflow that keeps trust debt small, visible, and payable - and turns inevitable errors into fast, low-risk feedback. To make that concrete, take a simple task: write a Python function that validates a 13- digit ISBN. It must accept strings with or without hyphens, compute the checksum per the official algorithm, and return a boolean. Now, imagine the typical approach: we start by writing a prompt to generate the function. Generate a Python function is_valid_isbn13(isbn_string) that validates a 13-digit ISBN based on the official checksum algorithm. The function must correctly handle input strings that may contain hyphens. Ensure the function returns True for valid ISBNs and False otherwise. 9 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 14

Sounds legit, isn’t it? The model might produce something that seems to work, but it will likely fail on various edge cases. Because we are dealing with a probabilistic model, running the same prompt again will produce a different implementation, often with an entirely new set of bugs and failure modes. Let’s generate this function with the GPT-5 model. Seems good. However, let’s try again with the same prompt: GPT-5 def is_valid_isbn13(isbn_string: str) -> bool: if not isinstance(isbn_string, str): return False cleaned = isbn_string.replace("-", "") # Must be exactly 13 digits if len(cleaned) != 13 or not cleaned.isdigit(): return False digits = [int(ch) for ch in cleaned] checksum_sum = sum((d if i % 2 == 0 else 3 * d) for i, d in enumerate(digits[:12])) check_digit = (10 - (checksum_sum % 10)) % 10 return digits[12] == check_digit 10 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 15

The retry generated totally different code… and a buggy one - it doesn't strip hyphens, which are allowed in the specification of ISBN. This is why a responsible approach doesn’t start with a prompt; we start by defining the contract for success. That “source of truth” is an executable specification - a pytest suite authored by a human - that covers the happy path, critical edge cases (invalid length, non- numeric characters, wrong checksum), and formatting variants. With the contract in place, the AI’s job is to satisfy the tests. This reframes the trade-off: speed without blind spots, and mistakes caught early, systematically, and cheaply. GPT-5 def is_valid_isbn13(isbn_string: str) -> bool: if not isinstance(isbn_string, str): return False if len(isbn_string) != 13 or not isbn_string.isdigit(): return False weights = [1, 3] * 6 try: total = sum(int(d) * w for d, w in zip(isbn_string[:12], weights)) expected_check = (10 - (total % 10)) % 10 return int(s[-1]) == expected_check except ValueError: return False 11 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 16

AI Prompt Begin Generate a Python function is_valid_isbn13(isbn_string) that validates a 13-digit ISBN based on the official checksum algorithm. The function must correctly handle input strings that may contain hyphens. Ensure the function returns True for valid ISBNs and False otherwise. Here are your tests that this function needs to pass. With this contract in place, a single, precise prompt can be formulated and given to any capable LLM: This prompt was provided to three leading models: Google's Gemini 2.5 Pro, OpenAI's ChatGPT-5, and Anthropic's Claude 4 Opus. While the resulting code showed minor stylistic differences in variable names or loop structures, these variations are irrelevant. The only metric that matters is that all three generated functions passed the exact same human- authored verification suite (comments stripped from original responses). import pytest # Assume is_valid_isbn13 is the function to be generated def test_valid_isbn_with_hyphens(): assert is_valid_isbn13("978-0-306-40615-7") is True def test_valid_isbn_without_hyphens(): assert is_valid_isbn13("9780306406157") is True def test_invalid_checksum(): assert is_valid_isbn13("978-0-306-40615-0") is False def test_invalid_length(): assert is_valid_isbn13("978-0-306-40615") is False def test_contains_non_numeric_characters(): assert is_valid_isbn13("978-0-306-40615-X") is False 12 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 17

Now, take a look at what Gemini 2.5 Pro generated: GPT-5 def is_valid_isbn13(isbn_string: str) -> bool: if not isinstance(isbn_string, str): return False for ch in isbn_string: if not (ch.isdigit() or ch == "-"): return False digits = isbn_string.replace("-", "") if len(digits) != 13 or not digits.isdigit(): return False total = 0 for i in range(12): d = int(digits[i]) total += d if i % 2 == 0 else 3 * d check_digit = (10 - (total % 10)) % 10 return check_digit == int(digits[12]) 13 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 18

And finally, Claude Sonnet 4.0: Gemini 2.5 Pro def is_valid_isbn13(isbn_string: str) -> bool: cleaned_isbn = isbn_string.replace("-", "") if len(cleaned_isbn) != 13 or not cleaned_isbn.isdigit(): return False total = sum(int(digit) * (1 if i % 2 == 0 else 3) for i, digit in enumerate(cleaned_isbn[:-1])) calculated_check_digit = (10 - (total % 10)) % 10 actual_check_digit = int(cleaned_isbn[-1]) return calculated_check_digit == actual_check_digit 14 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 19

As you see, implementation styles vary, but the universal success against a single verification contract demonstrates that the source of reliability is the human-authored specification, not the model. The engineering work lies in creating the contract, not in fine- tuning the prompt for a specific provider's quirks. This simple experiment proves a profound point: engineering rigor comes from the development process, not the generative model. Furthermore, this workflow directly counteracts the psychological risks of vigilance decrement and automation complacency. By forcing the engineer to focus on writing the test suite first, their cognitive energy is directed towards adversarial thinking and defining correctness before seeing any AI-generated code. This act of anticipating failure modes - an invalid checksum, a malformed string - is an inherently active, critical, and vigilant process. It keeps the human firmly in the loop at the most crucial stage: the definition of intent. This approach shifts the emphasis from the generated lines of code to the process that produces, verifies, and ultimately owns that code. It enforces the non-negotiables that vibe coding often ignores: scalability, security, maintainability, testability, and long-term evolvability. Think of it as engineer supervision for AI-generated artifacts - the safeguards that make sure the code survives contact with reality. Claude Sonnet 4 def is_valid_isbn13(isbn_string): clean_isbn = str(isbn_string).replace('-', '') if len(clean_isbn) != 13: return False if not clean_isbn.isdigit(): return False total = 0 for i, digit in enumerate(clean_isbn): digit_value = int(digit) if i % 2 == 0: # Odd position (0-indexed, so even indices are odd positions) total += digit_value * 1 else: # Even position (0-indexed, so odd indices are even positions) total += digit_value * 3 return total % 10 == 0 15 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Page 20

Ultimately, you need to ask one pragmatic question: “Would you go on-call for this system?” For code born purely from vibe coding, the honest answer is almost always: no. 1.4.3 From intelligent autocompletion to a partner Unfortunately, even the final version of the previous prompt might not work correctly in all cases, because ISBN codes can contain other separators, not just hyphens - also spaces. Our spec is lacking one important case: I wonder how many of you considered this type of corner case while reading this chapter, or if you just assumed the initial requirements were complete. It is not your fault - you are not required to have the ISBN specification in the working memory. However, that only shows that even with perfect definition of intent, as humans, we are still prone to guide AI in the wrong way. That’s why business value and systemic risk from AI aren’t a single dial you nudge and forget: they rise unevenly as you grant the machine more autonomy. The most useful way to reason about this is as a ladder, which each step upward buys more leverage but also demands tighter engineering discipline, clearer governance, and stronger verification. Climb too quickly and you trade short-term speed for long-term chaos. However, if you climb deliberately - you can unlock outsized returns. The journey up that ladder runs from a tool that helps you type to a partner that helps you think and act. Figure 1.1 Increasing Autonomy & Risk Label It begins with token-level completion - the classic, low-risk editor assist, indistinguishable from the standard code complete which is already well known for all developers. Then it moves to block-level suggestions, the Copilot era, where entire functions materialize with a keystroke… along with the possibility of subtle logical or security flaws hidden in the convenience. Next comes the intent-driven conversational agent inside the IDE: you describe a goal, the agent assembles tasks and drafts code, and your role shifts toward orchestration and review. def test_valid_isbn_with_spaces(): assert is_valid_isbn13("978 0 306 40615 7") is True 16 © Manning Publications Co. To comment go to liveBook Licensed to Ibrahim Mohammed Mohammed <ibrahim@dotnetebusiness.com>

Tip the Site

Vibe Engineering (MEAP V02) (Tomasz Lelek, Artur Skowroński)（Z-Library）

Vibe Engineering (MEAP V02) (Tomasz Lelek, Artur Skowroński)（Z-Library）

Registered users can read the full content for free

AI Reading Assistant

Passage locations

Recommended for You

Tip the Site