The Six Finger Problem

When generative AI first entered the mainstream, the images felt like magic.

With a few words, anyone could create a cinematic landscape, a polished portrait, or an illustration that would once have taken hours of specialized work. We shared the results, marveled at how quickly the technology had advanced, and imagined everything it might make possible.

At first glance, the images looked extraordinary.

Then we looked closer.

The elegant portrait had six fingers. A beach scene included an extra toe. An arm bent in a direction no arm should bend. A face in the background dissolved into something almost—but not quite—human.

The image was impressive enough to earn our confidence before it was accurate enough to deserve it.

We call this the Six Finger Problem.

It is the odd, incorrect, or nonsensical detail that AI places inside an otherwise convincing result. Sometimes it is obvious. Often it is only obvious to someone who knows what the finished work is actually supposed to contain.

That distinction matters far beyond image generation. It matters whenever AI gives advice, recommends a course of action, writes professional material, or builds a product.

The idea in one sentence

If you are not a specialist in the domain, you may not recognize AI’s sixth finger. If you are a specialist, you will usually spot it quickly—and know how to correct it.

This is not an argument against AI. We use it, value it, and believe it has dramatically expanded what founders and small teams can create.

It is an argument for understanding what expertise contributes.

AI can generate an answer. Expertise determines whether that answer belongs.

The same output means different things to different people

Imagine that AI drafts a tax strategy.

An experienced accountant may find the first draft useful. They can identify the sound recommendations, question an assumption that does not fit the client’s situation, catch a rule that has been applied incorrectly, and ask AI to revise the work. The accountant receives speed without surrendering judgment.

A person with no accounting background receives the same confident response but lacks the filter needed to evaluate it. Every recommendation may sound equally credible. The one sentence that does not belong—the sixth finger—can pass unnoticed because nothing about its wording announces that it is wrong.

The same dynamic appears in law, medicine, finance, marketing, architecture, and software engineering.

A specialist does not simply know more facts. A specialist recognizes patterns. They know what good work looks like, which details deserve suspicion, what consequences follow from a decision, and which question should come next.

That is why AI becomes more powerful in expert hands. The expert can keep the useful 90 percent, identify the nonsensical 10 percent, and either correct it directly or guide AI toward a better result.

A non-expert may accept all 100 percent because the output is polished, immediate, and plausible.

Why confidence arrives before correctness

AI is exceptionally good at producing results that look complete.

The image has composition. The explanation has structure. The recommendation has supporting reasons. The code runs. The interface looks polished. The confident presentation encourages us to assume that the underlying work is equally sound.

But AI does not need a complete understanding of the domain to generate a convincing pattern from it. That is how a beautifully rendered hand ends up with six fingers. The system knows enough about what a hand tends to look like to create one that feels right at a glance. It does not always know enough to make every detail anatomically correct.

The same thing happens in code. AI can assemble familiar frameworks, functions, database queries, authentication screens, and deployment instructions into a product that appears coherent. It can produce something that works during a demonstration without understanding every business rule, security boundary, failure condition, or long-term consequence inside the system.

The result can be visually finished and technically unfinished at the same time.

Vibe coding makes the Six Finger Problem harder to see

Vibe coding has given founders an extraordinary new capability. Someone with deep knowledge of a customer problem can describe what they need, build a working interface, connect services, test ideas, and produce a functional prototype without first becoming a software engineer.

That is real progress. The prototype may validate the concept more effectively than months of planning. It can reveal what customers value, clarify the workflow, and prove that the business deserves further investment.

The risk begins when a working prototype is mistaken for a production-ready product.

From the founder’s perspective, the most important flows may appear complete:

• A user can create an account.
• A form saves information.
• A dashboard displays the right numbers.
• A payment succeeds.
• An automated task runs during testing.
• The interface looks credible on a laptop and phone.

Those visible successes answer an important question: can the idea work?

They do not answer the production question: can the business safely depend on how it was built?

The sixth fingers in software rarely appear as an extra button or a visibly broken layout. They are buried in decisions a non-developer has no reason to know they should inspect.

What a seasoned developer sees immediately

An experienced developer does not look only at whether the happy path works. They have spent years seeing how software fails, how small shortcuts compound, and how apparently unrelated decisions collide once real users and real data enter the system.

They look at a working product and begin asking a different set of questions.

Architecture

Where does the business logic live? Are responsibilities clearly separated, or has each new prompt added another dependency to an already tangled flow? Can the product add a second customer type, a new integration, or a higher volume of activity without destabilizing existing behavior?

The sixth finger may be code that works today but makes every future feature slower, riskier, and more expensive.

Data and state

What information is truly persisted? What lives only in memory or temporary storage? What happens when two users change the same record, a request is interrupted, or one step in a multi-step operation fails?

The sixth finger may be an application that appears to save work while quietly losing or overwriting it under conditions the prototype never tested.

Identity and permissions

Can a user log in? That is the visible question. The expert asks whether each user can access only the records and actions appropriate to their role, whether password recovery is dependable, whether sessions are handled safely, and whether administrative privileges are consistently enforced.

The sixth finger may be a polished account area with an authorization gap hidden behind it.

Reliability and background work

What happens when email delivery fails, a scheduled task runs twice, a third-party service times out, or a job stops halfway through? Can the work be retried safely? Will anyone know it failed?

The sixth finger may be an automation that worked ten times during development and silently fails on the eleventh after launch.

Security and compliance

Where are secrets stored? Which dependencies are vulnerable? What sensitive information reaches logs, analytics, backups, emails, and third-party vendors? Are access, audit, retention, encryption, and incident practices consistent across the whole platform?

The sixth finger may be a system that looks secure because it has a login page while exposing risk everywhere else.

Production operations

How is the product tested, deployed, monitored, backed up, restored, and rolled back? Who owns an incident? What information will they have when something breaks at 2 a.m.?

The sixth finger may be a successful launch with no safe way to operate the product the following day.

Working software can still contain nonsense

This is the part that can feel counterintuitive: code can run and still be wrong.

It may be wrong for the expected number of users. Wrong for the sensitivity of the data. Wrong for the way the business will expand. Wrong for the reliability customers expect. Wrong for the compliance obligations surrounding the product. Wrong for the team that must maintain it.

AI often cannot resolve those questions from a prompt because they require context, tradeoffs, and responsibility. Even when AI recommends a technically familiar pattern, a seasoned developer still has to determine whether it is the right pattern for this product, this business, and this stage of growth.

That judgment is the software equivalent of counting the fingers.

The developer’s role is not to replace AI—or the founder

The founder understands the problem, the customer, and the opportunity. The prototype captures valuable learning that should not be discarded simply because AI helped create it.

The seasoned developer contributes a different form of expertise. They can inspect what exists, preserve what is sound, identify the hidden nonsense, and create the technical foundation the business actually needs.

AI can remain part of the process. In fact, it often should.

The difference is that AI is now working inside an accountable engineering process:

• Architecture is chosen deliberately instead of emerging from a sequence of prompts.
• Generated code is reviewed in the context of the entire system.
• Security recommendations are verified rather than trusted because they sound conventional.
• Tests cover failure conditions and critical business rules, not only the successful demonstration.
• Infrastructure and dependencies are selected with their operating consequences in mind.
• A qualified person owns the decision that the product is ready to release.

The goal is not human code instead of AI code. The goal is AI-assisted development with an expert who can see the sixth finger.

From impressive prototype to production foundation

A responsible transition to production does not automatically require throwing everything away and starting over.

It begins with a full assessment of the application: codebase, architecture, data model, identity, infrastructure, dependencies, integrations, deployment practices, and critical user journeys.

From there, a seasoned developer can separate the system into three categories.

Preserve what is sound

Some components may already be clear, testable, and suitable for continued use. Product logic, interface decisions, customer language, and validated workflows can all be valuable.

Correct what can be strengthened

Useful code may need better boundaries, validation, error handling, authorization, tests, monitoring, or documentation. These improvements preserve momentum while reducing risk.

Replace what cannot safely carry the business

Some decisions may be too fragile, insecure, or structurally limiting to repair responsibly. Replacing those areas is not a rejection of the prototype. It is the natural next investment after the prototype proved that the concept matters.

The result should be more than cleaner code. It should be a product the business can operate, trust, and grow.

Why this foundation matters for business growth

A weak technical foundation eventually becomes a business constraint.

Marketing cannot confidently drive demand if more users create more outages. Sales cannot make stronger promises if customer access and core workflows are unreliable. Leadership cannot pursue regulated opportunities if sensitive data is handled inconsistently. Product development cannot move quickly if every change creates another regression.

Production readiness creates leverage in the opposite direction.

• Reliable customer journeys protect trust and revenue.
• Clear architecture makes new features easier to add safely.
• Monitoring turns hidden failures into manageable operations.
• Strong access and data controls make larger customers and sensitive use cases more realistic.
• Tested releases let the team improve the product without gambling the existing business.
• Documentation makes the platform understandable to future developers, partners, and investors.

The seasoned developer is not there merely to make the code more elegant. They are there to make sure the software can support the promises the business is preparing to make.

Questions worth answering before production

Before a prototype becomes a production product, the team should have clear answers to questions like these:

• Who can access each type of data, and where is that enforced?
• What information could be lost if a process fails halfway through?
• How will the team know when a customer-facing workflow breaks?
• Can scheduled and background work be retried without duplicate effects?
• Are secrets, dependencies, and production environments configured safely?
• Are backups running, and has restoration actually been tested?
• Which critical workflows have automated tests and human launch checks?
• What sensitive data reaches logs, analytics, email, backups, and vendors?
• How is a release reviewed, deployed, rolled back, and documented?
• Who owns a production incident, and what will they need to resolve it?

Not knowing these answers does not mean the prototype failed. It means the prototype has completed its job and revealed the next work that needs to be done.

Look closely before the business depends on it

The first AI images were exciting because they showed us a future that had suddenly become possible. The sixth finger did not erase that possibility. It reminded us to look more closely.

Vibe-coded products deserve the same perspective.

Celebrate the speed. Preserve the learning. Use the prototype to prove the idea and shape the product. Keep using AI wherever it creates real leverage.

Then, before customers, sensitive data, revenue, and reputation depend on the software, bring in someone who knows what a production system should look like—and who can immediately recognize the detail that does not belong.

That expert eye is what turns an impressive AI-built prototype into a solid production foundation for business growth.