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 (46)
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.
I can definitely see that happening.
What's interesting is that AI seems to be lowering the barriers on both sides at the same time. PMs can prototype and experiment more directly, while engineers can spend more time thinking about product, user needs, and trade-offs instead of only implementation.
In a weird way, it feels less like the boundaries are disappearing and more like everyone is getting a better view into each other's world.
Which honestly sounds healthier than the old model of throwing requirements over a wall and hoping for the best lol
Curious to see how this evolves over the next few years.
Same, I am very curious to see how this evolves. Ultimately, as in many cases, I see this coming down to organizational culture. If AI tooling is leveraged in a healthy way that encourages collaborations then I can see this happening. On the other hand I can also see AI being used as a way to increase division and tracking between management and engineering in orgs that manipulate AI tools in a negative way.
the gap isn't the coding part. I've seen PMs ship prototypes in a weekend then spend two weeks figuring out why it breaks at scale. what's missing is system thinking, not syntax.
fully agree with you
yeah, and the second phase is where you find out if it's solving the right problem, not just the fastest one.
Systems thinking is the right framing. The data layer is where vibe-coded prototypes break first: demo works on 50 rows, you connect the real source and discover schema drift, nulls everywhere, latency that kills the UX. The prototype looked real. The data didn't care.
Systems thinking is such a valuable skill today and increasingly so. I know that for myself I have been studying this and there is still much to learn and discover in that space
the learning never really stops — every new system rewrites your mental model a bit. the data layer is where theory usually becomes real: prototype works, then scale hits and you trace it back to a schema assumption.
Schema assumptions are the silent killers. Everything downstream inherits the lie.
hardest part is when you share the same schema across multiple agents — every assumption gets inherited N times. by the time you trace the wrong output you're three layers deep into compounded lies with no single point of failure to point at
That's the worst part. Each agent's output looks reasonable in isolation. The compounded lie only shows up end to end, and by then you're debugging a distributed system with no stack trace.
Stack trace exists — just distributed. Every handoff in my fleet logs its full context window and tool responses. What's missing is the join layer. Had to build one manually.
Really like this concept and approach.
Having AI drive coding is becoming the default, not just for non-technical people, but with engineering teams.
I read through your first post and everything you said there is absolutely correct.
One thing that I advise people to do is to slow down and ask questions, and review in-flight. Meaning, don't auto-accept code that comes through but scrutinize as it's being developed. What that forces you do do is examine what the AI is developing and you can catch problems before they become bigger ones.
When I'm reviewing the code, I will ask myself: is this the most efficient way to do this? What has the agent forgotten about b/c it's not in its context?
Another thing that helps is conducting code review with an eye toward developing documentation. Creating explanations for arguments, parameters and returns makes you think about how this intersects with the whole.
Often during these sessions I'll see code that bothers me, or isn't well organized or optimzed. That's an opportunity to improve the codebase by abstracting away certain components, etc.
AI is very good at helping with these tasks. Instructing the AI to document, re-organize, reduce, abstract also forces a cognitive engagement with the codebase. No you're not writing it all yourself, but thinking carefully about what's being communicated.
This is a slower process, and I'm not sure if teams/individuals will have time to do this, but it's been extremely helpful for me.
Note, I've been working with AI assistants heavily for about 4 years, so this might not work for others, but it's been beneficial to me and my work.
Thanks for sharing your learnings Fard. I agree with what you say here. AI is indeed very good for helping with optmizations in your codebase if you know what to ask for and how to evaluate a good from poor output.
I think if we're talking about skill development and intention, that's something that people should optimize for.
This is such an important pivot in the current AI narrative. 'Vibe coding' is incredibly intoxicating because it completely removes the barrier to entry, but as you pointed out, it very quickly hits a ceiling when you try to scale or maintain what you've built.
100% Syed
That's why I believe creating a better shared understanding for technical and non-technical builders is so important to move forward more efficiently together, now that technology is enabling unprecendented capabilities in building.
I liked your real vs fake functionality map because it did a great job of conveying how to map AI code. How do you think about the ideal interaction model of someone that is non technical to technical, for example a PM or founder wanting to implement changes and then there is also the developer that needs to actually stabilize things? Is this the fastest path for collaboration between the two?
In this case it is very important that both parties share an understanding of the pros and cons of shipping within a specific timeline. What are the underlying risks and rewards for each decision? In this case both the PM and developer need to argue their case and align on the best plan forward. This is not easy as both parties generally operate under different incentive structures.
In my guide I present a section with questions you can ask your developer to help build this shared understanding.
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.
This really lands. I ran into this exact divide while building out my own front end/back end system with AI assistance. At first, the visible progress was intoxicating — pages appeared, routes worked, components existed, APIs responded. But the deeper the project got, the more I realized that “it runs” and “it is structurally true” are not the same thing.
That is actually how Scarab emerged for me. I did not start by trying to build a diagnostic system. I found the need for one because the AI could keep producing plausible work while the repo slowly accumulated mismatches: old assumptions, partial implementations, duplicated intent, broken ownership, and code that looked complete but no longer matched the architecture I had declared.
So I agree with your point about non-technical builders needing clearer thinking. The real danger is not that people will prototype. Prototyping is powerful. The danger is that AI makes the surface convincing long before the system underneath has earned trust. At some point, builders need a way to separate visible momentum from actual system truth.
Loved reading this, Julien. I could really relate to the "What engineers wish non-technical builders knew" part. It's easy to look at a prototype and think it's almost done, but there can be so many things happening underneath that aren't obvious at first. Things like security issues, exposed APIs, permissions, and edge cases can get missed pretty easily.
I also agree with your point about software engineers. I don't think we're going away, but I do think the way we work and the value we bring is changing. Interesting perspective and definitely gave me something to think about.
I am glad this post resonated with you Hemapriya.
I am attempting here to embrace a collective approach to merge understanding from both sides, engineering and non-technical.
As you mention, it will be very interesting to see how the role of software engineers will keep evolving over time.
Strong framing. The line about prototypes looking complete before the invisible layer is real landed for me — especially around data, permissions, edge cases, and ownership. As someone building AI products, I’ve seen how fast teams can mistake “demoable” for “production-ready.” Shared language between builders and engineers is probably the real leverage point here.
I am glad you like the framing Vic. Yes I see this as an opportunity to create a better understanding now that non-technical builders are exposed to more technical concepts and terms due to building software being more accessible.
Great perspective on the vibe coding challenge. One practical thing I've noticed is that managing all those AI prompts and copied snippets becomes its own workflow problem.
I built TextStow as a lightweight companion for this — it combines clipboard history with reusable prompt templates ({{variable}} syntax) and text cleanup for messy copied content like PDF breaks, JSON, and URLs. The key difference from a notes app is that everything stays local on the Mac and it's always one shortcut away in the menu bar. Worth comparing if you're juggling lots of AI prompts and copied text daily: textstow.com
nice. I appreciate the local first aspect of the tool.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.