Post
JA EN

"With AI, You Don't Need Designers or Engineers"—When Solo Development Works, and the 5 Ways It Breaks

Posted
By
11 min read
"With AI, You Don't Need Designers or Engineers"—When Solo Development Works, and the 5 Ways It Breaks
  • Who this is for: Engineers and non-engineer founders considering solo development or launching a startup with AI tools
  • Assumed knowledge: Hands-on experience with AI coding tools such as GitHub Copilot, Cursor, or Claude Code
  • Reading time: 11 minutes

Overview

“With AI, you don’t need designers or engineers anymore.” This claim has spread across X and startup communities. The number of solo developers shipping products over a weekend with vibe coding is growing, and you can’t deny the feat.

But the claim loses its accuracy because it drops a crucial qualifier: under what conditions? AI lets one person carry a whole build only inside a specific viable zone, and the moment you step outside it, things break in five familiar ways.

Code that ran in the prototype falls over under production load. In domains like healthcare or finance, no one can verify the answers AI produces. A 2025 Veracode report shows that 45% of AI-generated code contains security vulnerabilities1—but without eyes trained to catch them, the developer never sees them. A few months later, you can no longer read the code you had the AI write, and your users find themselves quietly forced to adapt to a “builder’s-spec” UI.

“You can go solo with AI” isn’t a lie. But there’s a range within which it isn’t a lie. This article maps that range.

The zone where “you can go solo” holds

Before the critique, let’s pin down the viable zone precisely. When the following three conditions are met, solo AI development is a realistic option.

Condition 1: A limited user base (tens to a few hundred users)

In the early phase, requirements for availability, response time, and concurrency are loose; even when something fails, the impact is contained and you can patch it quickly. Cases of solo founders building and monetizing a business with a tiny team (effectively one person) using AI are genuinely on the rise2, and at this scale one person’s productivity is enough to keep things running.

Condition 2: A common domain

E-commerce sites, portfolios, internal tools, information services—in these domains AI has ample training data, and you can trust its output at a practical level. This stands in sharp contrast to specialized domains like medical diagnosis, financial trading, or legal documents (more on this below).

Condition 3: Prototype stage, or technical debt you can defer

Before product-market fit is in sight, speed of hypothesis validation matters more than full scalability. In situations where “it just has to work” is a reasonable bar, AI can readily meet that demand.

When you step outside these three conditions, solo AI development starts sliding into its classic failure patterns.

The 5 patterns where it breaks

Pattern 1: The scaling wall

The first ordeal after a prototype works is that users start to grow.

AI is good at writing code that handles a single request, but designing an architecture that absorbs 10,000 concurrent requests is a different story. N+1 query problems, missing indexes, connection pool exhaustion—none of these are problems at prototype scale, but the symptoms surface the moment you scale. Because the cause is buried deep in the code, asking the AI “why is this slow?” often returns only a surface-level answer.

Retool writes in its own documentation that “an SQL injection in a prototype has a small blast radius, but the same flaw wired to a production Postgres becomes a data breach”3. Scale doesn’t change the severity of a problem—it changes the blast radius.

Handling an incident and running root-cause analysis at the same time, alone, is a situation that AI’s productivity gains don’t dissolve.

Pattern 2: The specialized-domain trap

The problem isn’t that AI “doesn’t have” domain knowledge—it’s that it “can’t verify” it.

Medical diagnostic criteria, the gray zones of financial regulation, loopholes in legal documents—AI generates plausible-sounding answers. Unless the solo developer is an expert in that domain, they can’t notice when those answers are wrong. In legally and financially heavy areas, the guidance is to keep a human in the loop rather than adopting AI’s output as-is4. Frameworks like SOC 2, HIPAA, and financial compliance all ultimately demand human accountability, but if no expert capable of verifying that is in the chain, the requirement becomes a hollow formality.

From an expert’s standpoint, AI is “something that knows, but guarantees no accuracy.” In specialized domains, it doesn’t hold up unless there’s a human in the chain scrutinizing that uncertainty.

Pattern 3: The invisible holes in security

Of all the risks of solo development, this is the one with the most numbers attached.

According to a 2025 Veracode report that evaluated over 100 LLMs across 80 coding tasks, 45% of AI-generated code contained OWASP Top 10 vulnerabilities; in Java, 72% failed, and for XSS-related issues, 86% were vulnerable1. OX Security aggregated multiple studies and put the share of AI-generated code containing vulnerabilities at 62%5.

What’s more serious is that it doesn’t improve as model generations advance. The Veracode report notes that “newer-generation models came to write functionally accurate code, but their security performance stayed flat.” Code “working” and code being “safe” are separate questions.

According to a 2026 report from the Cloud Security Alliance (CSA), the number of CVE (Common Vulnerabilities and Exposures) entries attributable to AI coding tools has surged since the start of 2026, and there have been multiple reported cases of secret leaks in vibe-coded products shipped to production without security review6.

Without eyes to review, these vulnerabilities stay invisible to the developer.

Pattern 4: Code you can no longer read yourself

The first code worked. But three months later, when you go to add a new feature, you can no longer read the code you had it generate—this is a pattern many solo AI developers report.

The “paste it and make it run” working style of vibe coding scatters near-identical code across multiple places. When you delegate refactoring decisions to AI, immediate behavior takes priority over structural consistency. The large-scale empirical study “Debt Behind the AI Boom” (arXiv:2603.28592, 2026) shows that the accumulation of duplicated code and the loss of design intent in AI-generated code accelerate technical debt7.

A LeadDev analysis likewise points out that unverified code accepted faster than it can be reviewed accumulates in the codebase and generates a substantial amount of technical debt8. Design intent doesn’t survive in the code. With every change, the blast radius of the impact is unreadable. As this piles up, the cost of modification starts to exceed the cost of new development.

Pattern 5: UX that becomes “self-spec”

This is what happens most quietly, but most surely, in development without a designer.

When a lone developer hands UI design to AI, the AI generates a UI that is “on average correct.” But a user’s mental model, their information priorities, and the context of error states have to be designed from the perspective of a specific target user, not the average one. Research into the UX of vibe coding (arXiv:2509.10652, 2025) points out, from the perspective of UX professionals, that AI can’t carry over context such as a system’s history, its trade-offs, and its internal constraints—and that when context is lost, output tends to drift toward generic solutions9. The Nielsen Norman Group also notes that AI-driven UI generation produces “artifacts misaligned with intent—broken features, misinterpreted layouts,” and warns of a structural risk in which it becomes unclear who owns the design decisions10.

When you develop alone, test alone, and ship alone, the feedback loop never closes. Even after users have left saying “this is unusable,” the developer keeps feeling that “it works.”

Three questions to judge whether “you can go solo”

When you organize the five patterns, the questions for judgment narrow down.

Question 1: When a security incident hits production, can you investigate the root cause yourself?

If you can’t, you need someone who can run a security review. Even if you can run a security checklist with AI, the check becomes a hollow formality without the ability to understand the nature of a vulnerability and fix it.

Question 2: Are you an expert in that domain, or do you have access to one?

For products that require deep knowledge of medicine, finance, law, or a specific industry, you need a human in the chain who can verify AI’s output. Confirm whether you’ve built the cost of consulting an expert into the cost of the product.

Question 3: Six months from now, could another developer understand your code and take it over?

Judge whether you’re in a phase that can tolerate a “bus factor of 1” (a state where the product stops if you go down), with full awareness of it. In a stage where pivots and feature expansion happen frequently, an understandable codebase translates directly into speed.

Conclusion

If we restate the claim “with AI, you don’t need designers or engineers” accurately, it becomes the proposition: “under specific conditions, for specific early-stage products, you can sometimes make them unnecessary.”

The viable zone exists. In a place where the three conditions—small scale, common domain, prototype stage—are met, the combination of AI and a single developer can sometimes outpace a traditional multi-person team.

But when you step outside the viable zone—when you scale, when the domain grows complex, when production quality is demanded, when users diversify, when the codebase grows—the five patterns arrive not in sequence but all at once.

AI is genuinely powerful, but the wider the gap grows between “what AI is good at” and “what the product needs,” the more the limits of solo development appear. Whether you grasp that gap yourself is what separates the solo developer who isn’t swept along by the hype from the one who pays for it later.

You may also be interested in these related articles:

References

The references corresponding to the citation numbers in the text are listed in order.

  1. 2025 GenAI Code Security Report - Veracode (2025). Evaluated over 100 LLMs across 80 coding tasks. 45% of AI-generated code contained OWASP Top 10 vulnerabilities; Java 72%, XSS 86%. [Reliability: Medium-High] ↩︎ ↩︎2

  2. Solo Founder Index 2026 - ShipSquad (2026). An index aggregating revenue trends (median ARR, etc.) of solo founders leveraging AI. This article cites it not as a statistic on user scale, but as corroborating evidence that solo founders are running viable businesses with AI. [Reliability: Medium] ↩︎

  3. The Risks of Vibe Coding: Security Vulnerabilities and Enterprise Pitfalls - Retool (2026). Explains the security risks of vibe coding and the pitfalls specific to the enterprise. Argues how the blast radius of an SQL injection changes between prototype and production. [Reliability: Medium] ↩︎

  4. Solo Founders Lean On AI To Replace Teams, But Limits Remain - Self Employed (2026). An article on the movement of solo founders replacing teams with AI, and the limit that in legally and financially heavy areas, a human in the loop should be kept. [Reliability: Medium] ↩︎

  5. Vibe Coding Security: Why 62% Of AI-Generated Code Ships With Vulnerabilities - OX Security (2026). Aggregates multiple studies (CMU, CSET, Veracode, etc.) and presents the share of AI-generated code containing vulnerabilities as 62%. Note that this is an integrated figure, not an independent single study. [Reliability: Medium] ↩︎

  6. CSA Research Note: AI-Generated Code Security & Vibe Coding - Cloud Security Alliance Labs (2026). Reports a surge in CVE entries attributable to AI coding (from 6 to 35 between January and March 2026) and cases of secret leaks (over 400). [Reliability: Medium] ↩︎

  7. Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild - arXiv:2603.28592 (2026). A large-scale empirical analysis of AI-generated code across 6,299 repositories and 302,600 commits. Shows that the accumulation of duplicated code and the loss of design intent accelerate technical debt. [Reliability: Medium (preprint)] ↩︎

  8. How AI generated code compounds technical debt - LeadDev (2025). Analyzes how AI-generated code accelerates technical debt through increased duplication and the accumulation of unverified code. [Reliability: Medium] ↩︎

  9. Vibe Coding for UX Design: Understanding UX Professionals’ Perceptions of AI-Assisted Design and Development - arXiv:2509.10652 (2025). [Reliability: Medium (preprint)] ↩︎

  10. GenUI vs. Vibe Coding: Who’s Designing? - Nielsen Norman Group (2025). [Reliability: Medium-High] ↩︎

AI・Technology
AI vibe coding solo development security software quality
This post is licensed under CC BY 4.0 by the author.