
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.
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:
So I wanted to create a new version of the system for this wider builder audience.
Thinking in the Age of AI: Builder Edition
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.
But software is not just what appears on the screen.
Software also includes:
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.
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.
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.
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:
_____________________________________________________________________
_____________________________________________________________________
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:
_____________________________________________________________________
_____________________________________________________________________
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.
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:
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.
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:
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.
I’m curious how others are seeing this shift.
For non-technical builders:
For engineers:
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.