In the previous post, I described building two real systems through conversational AI development and the 80:20 pattern that emerged. AI tools got me most of the way to functional software, but that last stretch to something safe and deployable still required knowledge that prompting alone couldn’t replace.
This post is about what that knowledge actually is. Through detailed documentation of everything that went wrong across both projects, I identified six recurring ways that vibe-coding breaks down, and from those, five areas of knowledge that I think non-technical practitioners genuinely need to develop. Not to become programmers. But to collaborate effectively with AI systems that program on their behalf.
The Six Failure Modes
1. Configuration Blindness
This was the sneakiest failure. The AI would generate code that assumed things existed when they didn’t. Authentication flows that referenced services I hadn’t set up. Database queries against collections that hadn’t been created. API calls to endpoints that weren’t there. The generated code looked perfectly fine. It only failed when you actually ran it and it tried to talk to infrastructure that wasn’t there.
The core issue is that the AI operates within a limited context. It can see the code it’s writing. It can’t see the infrastructure that code depends on. And if you don’t know that infrastructure needs to exist, you’ll never think to ask about it. The AI can’t teach what it can’t see.
2. Permissions Mismatch
Multi-user systems need to distinguish between who can see what and who can do what. Members versus non-members. Editors versus viewers. Public data versus private data. The AI could generate access control that worked for simple cases, but it broke down on edge conditions. What happens when someone leaves a project but their uploaded documents remain? How should file access work through nested folder structures?
In the educational project, this showed up differently: the system needed to prevent students from accessing teacher-only content while still allowing teachers to monitor student interactions. The AI handled the basic scenario but struggled where roles intersected or the same person needed different permissions in different contexts.
3. Data Boundary Violations
Generated code would sometimes expose information that should have stayed private. User email addresses appearing where only display names should show. Search results including details that were supposed to be confidential to project members. The AI treated data as raw material for building features without an inherent sense of what’s sensitive. Privacy wasn’t a property it naturally respected.
4. Dependency Drift
Small changes would cause cascading problems. The AI would update one component in a way that broke assumptions elsewhere. Change how user profiles work and suddenly authentication, membership, and content management all have subtle bugs. These regressions were hard to catch because they appeared in code you weren’t currently looking at. The AI optimises locally while consequences spread globally.
5. Overconfident Unsafe Defaults
The AI would make choices that sounded reasonable but were actually insecure. API keys placed in code that runs in the browser, where anyone could find them. Authentication patterns with known vulnerabilities. Storage rules defaulting to public access when private should have been the safe starting point. The model’s confidence in its outputs didn’t correlate with their actual safety.
In the educational project, where the system served children, unsafe defaults weren’t just technically problematic. They were potentially harmful. Content filtering, data retention, interaction logging: all of these needed careful consideration that the AI didn’t provide.
6. Regeneration Problems
When something broke, asking the AI to fix it sometimes made things worse. Instead of making a targeted fix to the specific issue, the model would rewrite entire sections of code, introducing new bugs while solving old ones. I found that asking to “fix the authentication problem” might trigger changes throughout the system when the actual issue was a single misconfigured setting. The ability to isolate a problem and request a precise correction was the difference between making progress and going in circles.
What You Actually Need to Know
These failure modes aren’t random. They cluster around gaps in knowledge. Working backwards from what went wrong, I identified five areas of understanding that make the difference between vibe-coding that produces something useful and vibe-coding that produces something fragile.
I’ve been calling this the Minimum Viable Literacy framework. Not “minimum” as in the least you can get away with, but as in the smallest set of things that reliably shifts outcomes from impressive demos to functional systems.
Systems Thinking
This turned out to be the most foundational skill. Before you ask an AI to build anything, you need to be able to describe what you’re building in terms of who uses it, what they’re trying to accomplish, and how different parts of the system connect. Without that, your prompts drift into disconnected features that don’t add up to a coherent experience.
When I could clearly describe a user journey from start to finish, the AI produced good results. When I prompted vaguely, I got what I started calling the scaffold problem: attractive interfaces with placeholder logic, impressive surfaces with hollow substance.
You don’t need to know how to build a system. But you do need to know what you’re building, at the level of people, actions, and flows.
Basic Architecture Concepts
Not at implementation depth, but at the level of practical distinctions. Understanding the difference between what happens in your browser and what happens on a server. Between temporary data and permanent data. Between different types of users having different levels of access. Between public information and private information.
These distinctions let you prompt effectively even without technical knowledge. I could ask for “server-side validation” without knowing how to implement it, as long as I understood why checking things only in the browser wasn’t enough.
The knowledge is categorical, not procedural. You don’t need to know how databases work internally. You need to know that storing data permanently requires a database, that databases require setup, and that different kinds of data might need different handling.
Configuration Literacy
This is about recognising that your code depends on things the AI can’t provide. Cloud services need to be set up. Authentication providers need to be configured. API keys need to be obtained and stored securely. The AI can write code that uses all of these things, but it can’t create or configure them for you.
The practitioner who understands this boundary can work within it productively. The practitioner who doesn’t will experience mysterious failures that no amount of re-prompting can solve, because the problem isn’t in the code. It’s in the infrastructure the code depends on.
Error Literacy
When things break (and they will), you need to be able to read an error message, figure out roughly what went wrong, and describe the problem precisely enough for the AI to make a targeted fix rather than rewriting everything.
This was one of the skills that improved most dramatically through practice. Early on, every error triggered a broad “fix it” prompt that produced broad changes that introduced new problems. Learning to say “this specific function returns an error about a missing field” instead of “authentication is broken” dramatically improved how quickly things converged on working.
Safety Literacy
Finally, you need a sense of where risk concentrates. Authentication. Data access rules. API credentials. Privacy boundaries. External service integrations. You don’t need to be a security expert, but you need to know that these areas deserve extra attention and that the AI’s confidence in its own outputs isn’t a reliable indicator of their safety.
The educational project made this visceral. Building something for children meant that content safety, data protection, and interaction monitoring weren’t nice-to-haves. They were requirements. And the AI hadn’t raised any of those concerns on its own.
The Deeper Point
None of this is about learning to program. It’s about developing the judgement, specification, and trust calibration skills that matter when someone (or something) else is doing the implementation. In some ways, it’s closer to learning to be a good client or a good creative director than learning to be a developer.
The interesting educational challenge isn’t teaching people to code. It’s teaching them enough about how software works to direct AI tools effectively, spot problems, and know when something needs expert review before you can put it in front of real people.
In the final post, I’ll talk about where this research is heading: studies with real participants, and the tools I’m building to make the whole process work better.
I’m a PhD researcher at Royal Holloway, University of London, funded through the UKRI Centre for Doctoral Training in AI for Digital Media Inclusion.