ASCII Art Planning Could Fix AI Coding's Biggest

There's a technique floating around the AI coding community that deserves scrutiny, not because it's revolutionary, but because it surfaces something uncomfortable about how we're building software with large language models. Developer Mark Kashef has been teaching people to draw ASCII art diagrams before asking Claude to write code—boxes, arrows, labels—treating the AI like a contractor who needs blueprints.

The core proposition is straightforward: instead of prompting Claude Code with vague instructions and iterating blindly toward a working product, you sketch what you want first using text-based diagrams. Kashef demonstrates this across four scenarios—analytics dashboards, landing pages, PowerPoint decks, and database schemas. In each case, the ASCII wireframe version produces more predictable results than the control group of "lazy prompts."

What's interesting isn't whether this works—Kashef's examples make a compelling case that it does—but what this technique reveals about the current state of AI-assisted development.

The Token Economics Problem

Kashef emphasizes that this approach "saves you both time and tokens." The token argument matters more than it might seem. When you're working within Claude's context window, every revision burns through your allocation. For complex outputs like PowerPoint decks with custom layouts, Kashef notes you can "find yourself if you iterate five, six, seven times at the end of your context window or completely out of tokens."

This isn't just about cost efficiency. It's about a fundamental mismatch between how these tools are priced and how people naturally work with them. The current model penalizes exploration and iteration—the very activities that lead to better outcomes when you're not entirely sure what you're building.

The ASCII planning technique is essentially a workaround for a pricing structure that discourages the iterative refinement process that has defined good software development for decades. You front-load your thinking into a cheap text diagram so you don't waste expensive tokens on throwaway code.

What "Vibe Coding" Really Costs

Kashef uses the term "vibe coding" to describe what happens when non-technical users prompt AI tools with imprecise instructions and hope for the best. His examples of lazy prompting—"Build me a SaaS dashboard" with minimal specifications—produce predictably mediocre results. The comparison screenshots show garish emoji-laden interfaces that look like they emerged from a design system circa 2015.

"A lot of vibe coding horror stories just come from poor planning," Kashef argues. But there's a tension here worth examining. The promise of AI coding tools has been that they would democratize software development, letting people without technical training build functional applications. If the solution to making these tools work is to learn ASCII wireframing and adopt planning disciplines that mirror traditional software development, we haven't actually eliminated the barriers to entry—we've just shifted them.

The ASCII technique works precisely because it forces users to think systematically about structure, relationships, and visual hierarchy before any code gets written. That's valuable. But it also suggests these tools are less accessible than their marketing implies.

The Database Visualization Case

Kashef's strongest example involves database schema design. He walks through creating an ASCII diagram for a SaaS application with users, products, purchases, and audit logs. The visualization shows table relationships, primary keys, and foreign key connections—concepts that are genuinely difficult for non-technical users to grasp.

"The average person who is non-technical just assumes that the database created is perfect and doesn't really get into the weeds as to how different things are stored," Kashef observes. This matters because database design mistakes are expensive to fix later. Once you have production data flowing through poorly structured tables, refactoring becomes treacherous.

The ASCII approach here serves as a forcing function for understanding. If you can't visualize the relationships between your data entities clearly enough to draw them as boxes and arrows, you probably shouldn't be asking an AI to build your database schema. The diagram isn't just a planning tool—it's a comprehension check.

The Human Taste Factor

There's a revealing moment when Kashef discusses PowerPoint generation. Even when Claude produces aesthetically acceptable slides without ASCII planning, he notes that "the entire direction and structure is completely up to Claude. So it's going to make assumption on assumption."

He frames the human role as adding "that taste factor" that distinguishes good design from adequate design. This gets at something fundamental about how these tools currently work. Claude can execute competently on well-defined specifications, but when you leave decisions to its training data and probabilistic outputs, you get something that reflects statistical averages rather than intentional choices.

The question this raises: if we need to pre-specify structure and design to this degree to get good results, what exactly is the AI contributing? It's not creative direction or architectural thinking. It's translation—converting your ASCII sketch into production code. That's valuable labor, certainly, but it's a narrower capability than the marketing suggests.

What This Means for Policy

From a regulatory perspective, techniques like ASCII planning complicate how we think about AI capability claims. When vendors demonstrate these tools, they rarely show the preparatory work required to get quality outputs. The disconnect between demonstration and reality has implications for how we evaluate AI's impact on employment and skill requirements.

If using these tools effectively requires visualization skills, systematic thinking about data relationships, and understanding of design principles, then the "anyone can build software now" narrative needs qualification. The barriers haven't disappeared—they've been reframed as "planning" rather than "coding."

This matters for workforce development policy, educational priorities, and how we think about AI's democratizing potential. The tools may be genuinely useful for people who already understand software development but want to work faster. For true novices, the learning curve might be steeper than it appears.

Kashef is selling prompt templates and community access, which is standard practice for developer educators. The technique itself is freely describable and replicable—he's monetizing the curation and support layer around it. Whether ASCII planning becomes standard practice or remains a niche optimization depends partly on whether AI coding tools evolve to handle ambiguity better, and partly on whether users are willing to adopt what is effectively a new design discipline.

The technique works. That's not in question. What remains uncertain is whether its necessity represents a temporary limitation of current tools or a permanent feature of how humans and AI will need to collaborate on technical work.

Samira Okonkwo-Barnes covers technology policy and regulation for Buzzrag.