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.
Top comments (6)
This really resonated with me.
One thing I've been noticing lately is that AI is compressing the distance between "I have an idea" and "I have something I can show someone."
Which is amazing.
But at the same time, I think it's creating a new kind of gap: the gap between building something that looks real and understanding what makes it actually real.
The "prototype illusion" section captures that really well. I can easily imagine two people looking at the same AI-generated prototype and reaching completely different conclusions about how close it is to being production-ready
I also liked that this doesn't frame the future as engineers vs non-engineers. The most interesting future to me isn't one where one side replaces the other, but one where both sides can collaborate with a much better shared understanding of what's visible and what's hidden underneath.
The engineer handoff template is a great idea too. Half the friction I've seen in projects seems to come from people having different mental models of the same thing.
Great read as always Julien 🙌
I am glad this approach resonates with you Aryan. I do believe there is an opportunity here to collaborate between technical and non-technical builders and share insights and understanding.
I believe that the idea of engineers vs non-engineers can be detrimental to progress. I am seeing more and more teams where the lines between PMs and engineers are becoming increasingly blurred with PMs getting involved in the buildng process and engineers embracing the product involvement more.
This is a really useful framing, especially the “prototype illusion.”
The part I’d add is that every AI-generated prototype probably needs an explicit
confidence boundary.
Not just:
But also:
That distinction matters because the prototype illusion is not only visual. It is also
psychological. Once the app looks real, the builder starts to feel like the system is
more understood than it actually is.
The engineer handoff template is strong because it turns “please look at this” into a
much better question: “here is what I think is real, here is what I know is fake, here is
what I do not understand yet.”
That is a much easier starting point for collaboration.
I also like that you are not framing this as engineers vs vibe coders. The better split
might be:
AI lowers the cost of creating the visible layer. But the invisible layer still needs
shared language: data, permissions, failure states, deployment, ownership, maintenance.
That is where this guide feels useful. It gives non-technical builders a way to bring
clearer context instead of just prettier demos.
Well said. I really like the concept of a confidence boundary you introduce here.
I am happy you agree with my framing overall.
The "looks like it works vs. actually works" gap is where I lose the most time too. AI code especially — everything seems fine until you hit an edge case.
Exactly, with this guide I am attempting to reduce that gap with proactive frameworks and exercises.