Over the past few months, I’ve increasingly noticed something through my network:
more people from non-technical backgrounds are building software...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
The worksheets are great. They can an help surface blind spots and shore up understand for builders on what their product is.
Thanks. I tried to make these worksheets as practical as possible, to be used alongside tasks and workflows.
Facts. AI didn't kill coding, it raised the bar.
I used to think "why learn DSA if ChatGPT exists". Then I realized ChatGPT can't debug why my config file breaks prod at 2am.
We still need engineers who understand the "why" behind the code. Great post.
Thanks Partha, I am glad you also see and experience the value of understanding the "why" behind the code.
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.
nice ++
thanks!
Point exactly, Julien! the role of software engineer will not disappear but evolve.
Yes these are exciting times to be in Ben!
yes, it is :)
The jump from describing an idea to showing something that actually runs is huge. Even an ugly prototype changes the conversation — you stop explaining and start pointing at it.
Agree. Easier prototyping unlocks more discussions and potential insights. Knowing which questions to ask and what to look for in a prototype is key.