Over the past few months, I’ve increasingly noticed something through my network:

more people from non-technical backgrounds are building software as AI tooling improves.

• Designers are prototyping product ideas.
• Product managers are testing workflows.
• Founders are building MVPs.
• Operators are creating internal tools.
• People who would not have called themselves “technical” a year ago are now using AI to make ideas tangible.

I think this is genuinely exciting.

It has never been easier to create.

I even attended a hackathon where participants only had 20 minutes to build a demoable product!

This raises the question:

When AI makes building easier, how do we make sure understanding does not disappear?

I recently published Thinking in the Age of AI, a guide for software engineers (you can check out my previous post here).

That guide focused on individual reflection for engineers: how to keep developing technical intuition, reasoning, and judgment while using AI tools.

But the landscape has changed quickly.

AI-assisted building is no longer only an engineering workflow.

It is becoming a builder workflow accessible to all.

And by builders, I mean anyone using AI to turn ideas into software-like artifacts:

• vibe coders
• designers
• product managers
• founders
• operators
• marketers
• students
• non-engineering team members

So I wanted to create a new version of the system for this wider builder audience.

Thinking in the Age of AI: Builder Edition

The opportunity is real

I do not think we should dismiss this shift.

I have spoken with people from all kinds of backgrounds who are actively building now.

People who previously had to wait for engineering time can now create something concrete.

That changes the conversation.

Instead of describing an abstract idea, you can show a flow.

Instead of writing a long product spec, you can prototype the interaction.

Instead of asking “would this work?”, you can test a rough version.

That is powerful.

But there is a trap.

A prototype can look much more complete than it really is.

• The interface may look polished.
• The buttons may respond.
• The demo may feel convincing.
• The generated app may run locally.

But software is not just what appears on the screen.

Software also includes:

• data
• deployment
• behavior
• permissions
• edge cases
• security
• reliability
• failure handling
• maintenance
• ownership
• user trust

AI makes the visible layer easier to create.

But the invisible layer still requires judgment.

There is an opportunity here for both engineers and non-technical builders to collaborate better.

As an engineer, I have felt frustrated in the past when product or design decisions seemed misaligned with technical constraints. I am sure I am not the only one.

And I have also heard the opposite frustration from non-engineers: that engineers can sometimes seem overly cautious, slow, or resistant to ideas that feel obvious from a product or design perspective.

Often, both sides are reacting to incomplete context.

The fact that building is becoming accessible to more people may also be an opportunity to reduce these misalignments.

With the right mindset and shared language, this process can become much more effective.

The prototype illusion

One of the ideas I explore in the guide is what I call the prototype illusion.

This happens when a prototype looks more complete than it really is.

A prototype is allowed to be incomplete.

It is allowed to be messy.

It is allowed to fake things.

The problem starts when the builder does not know what is real and what is fake.

That is where collaboration with engineers can break down.

A designer might show an AI-generated prototype and think:

“This is almost done.”

An engineer might look at the same prototype and think:

“This needs to be rebuilt from scratch.”

Both people may be right from their own perspective.

The issue is not the prototype.

The issue is the missing shared understanding.

2 practical exercises to grow this shared understanding

Here are two exercises from the Builder Edition guide that you can start using immediately.

I chose these two because they address the most common source of friction: a prototype that looks clear to one person but means something very different to someone else.

1. Real vs Fake Functionality Map

This is one of the most important habits for AI-assisted building to fight the prototype illusion.

Use this worksheet after creating a prototype, demo, or AI-generated app.

Time required: 5-10 minutes.

Step 1 — List the Main Features

What does this prototype appear to do?

1. ___________________________________________
2. ___________________________________________
3. ___________________________________________

Step 2 — Classify Each Feature

For each feature, mark whether it is real, mocked, partial, or unknown.

Feature 1: ___________________________________________
☐ Real
☐ Mocked
☐ Partial
☐ Unknown

Notes:
_____________________________________________________________________
_____________________________________________________________________

Feature 2: ___________________________________________

☐ Real
☐ Mocked
☐ Partial
☐ Unknown

Notes:
_____________________________________________________________________
_____________________________________________________________________

Feature 3: ___________________________________________

☐ Real
☐ Mocked
☐ Partial
☐ Unknown

Notes:
_____________________________________________________________________
_____________________________________________________________________

Step 3 — Identify the Illusion

Which part looks more complete than it really is?
_____________________________________________________________________
_____________________________________________________________________

What might someone misunderstand if they saw this demo?
_____________________________________________________________________
_____________________________________________________________________

What should I explicitly say before showing it?
_____________________________________________________________________
_____________________________________________________________________

Step 4 — Clarify the Next Step

What needs to happen before this becomes real software?
☐ Product validation
☐ Design refinement
☐ Engineering review
☐ Database design
☐ Authentication
☐ Permission handling
☐ API integration
☐ Testing
☐ Security review
☐ Performance review
☐ Deployment setup
☐ Other:
_______________________________

Most important next step:
_____________________________________________________________________
_____________________________________________________________________

2. Engineer Handoff Template

This might be the most useful exercise for teams.

The best handoff is not perfect code.

The best handoff is clear context.

Use this when asking an engineer to review, rebuild, extend, or estimate work based
on an AI-generated prototype.

Time required: 10-15 minutes.

Handoff Summary

Feature or prototype name:
_____________________________________________________________________
_____________________________________________________________________

One-sentence summary:
_____________________________________________________________________
_____________________________________________________________________

Who is the target user?
_____________________________________________________________________
_____________________________________________________________________

What problem does this solve?
_____________________________________________________________________
_____________________________________________________________________

Prototype Status

Built with:
_____________________________________________________________________
_____________________________________________________________________

AI tools used:
_____________________________________________________________________
_____________________________________________________________________

What works today?
_____________________________________________________________________
_____________________________________________________________________

What is mocked?
_____________________________________________________________________
_____________________________________________________________________

What is incomplete?
_____________________________________________________________________
_____________________________________________________________________

What is known to be fragile?
_____________________________________________________________________
_____________________________________________________________________

Product Intent

Core user flow:
1. __________________________________________________________________
2. __________________________________________________________________
3. __________________________________________________________________
4. __________________________________________________________________

Must-have behavior:
_____________________________________________________________________
_____________________________________________________________________

Nice-to-have behavior:
_____________________________________________________________________
_____________________________________________________________________

Success criteria:
_____________________________________________________________________
_____________________________________________________________________

Technical Unknowns

I need help understanding:
☐ Database structure
☐ Authentication
☐ Permissions
☐ APIs
☐ Deployment
☐ Security
☐ Performance
☐ Testing
☐ Maintainability
☐ Integration with existing systems
☐ Other: ______________________________

Specific questions:
1. __________________________________________________________________
2. __________________________________________________________________
3. __________________________________________________________________

Review Request

What kind of feedback do I need?
☐ Is this technically feasible?
☐ What would need to be rebuilt?
☐ What risks do you see?
☐ What is the simplest reliable implementation?
☐ What should we not ship as-is?
☐ What assumptions are wrong?
☐ What is the rough complexity?
☐ What should I clarify before this becomes engineering work?

Most important engineering question:
_____________________________________________________________________
_____________________________________________________________________

What engineers wish non-technical builders knew

One section of the guide is called What Engineers Wish You Knew.

Engineers are usually not trying to slow you down.

When they ask about edge cases, permissions, data, security, or failure states, they are not dismissing the idea.

They are thinking about what happens when the idea becomes real.

A working demo is not the same as production-ready software.

Simple-looking features can hide complex systems.

AI-generated prototypes can improve collaboration a lot.

But only if they are presented honestly.

That honesty builds trust.

So what happens to software engineers?

This is the part I’m still thinking through.

If more people can build software-like prototypes, does the world need fewer software engineers?

Maybe in some areas.

But I suspect the role changes more than it disappears.

The value of software engineers may shift even more toward:

• system design
• technical judgment
• reliability
• security
• integration
• maintainability
• reviewing AI-generated work
• helping teams understand trade-offs
• turning prototypes into durable systems

In other words, engineers may spend less time being the only people who can create the first version.

But more time being the people who can make software real, safe, reliable, and maintainable.

That is a different kind of leverage.

It also means non-technical builders and engineers will need better collaboration patterns.

The future may not be “engineers vs vibe coders.”

It may be:

builders create more concrete ideas earlier, and engineers help turn the right ones into real systems.

But for that to work, both sides need shared understanding.

I am generally optimistic, but not because I think the transition will be easy.

Work changes when tools change.

A 2024 MIT study estimated that about 6 out of 10 jobs people do today did not exist in 1940. That does not prove AI will automatically create better outcomes, but it is a useful reminder that roles evolve when technology changes.

My own strategy as an engineer is to become a broader generalist: someone who can understand product, systems, AI workflows, and collaboration across disciplines.

Why I wrote this guide

I wrote Thinking in the Age of AI: Builder Edition because I think this shift is too important to ignore.

AI-assisted building is here.

Non-technical builders are already creating software.

That is not going away.

The question is whether we develop better habits around it.

It includes worksheets, checklists, prompts, and reflection cards to help builders:

• understand what AI generated
• separate real functionality from mocked behavior
• identify hidden technical risk
• avoid common vibe coding traps
• find edge cases earlier
• prepare better engineer handoffs
• know when something needs review

The goal is not to make people afraid of building with AI.

The goal is to help people build with more clarity.

AI can generate prototypes.

Builders must generate clarity.

Discussion

I’m curious how others are seeing this shift.

For non-technical builders:

• Where do you feel most unsure when building with AI?
• Is it code quality, data, security, deployment, edge cases, or knowing when to ask an engineer?

For engineers:

• How do you feel about working with AI-generated prototypes from designers, PMs, founders, or other non-technical builders?
• What makes those handoffs useful vs frustrating?

For everyone:

Do you think the world will need more software engineers, fewer software engineers, or just a different kind of software engineer?

If you want to explore the full set of exercises, prompts, and worksheets, you can get the guide free here.