AI enables non-engineers to build software, but the real threshold has shifted to "judgment"
AI coding is making it feasible to "build a small tool for yourself," but it has not eliminated software engineering. It has simply moved the hardest work forward—from writing the first version of code to choosing architecture, managing data, setting permissions, and verifying results.
AI product strategist Nate B. Jones attempts to draw a map of personal software that even non-engineers can understand in a 35-minute video. He lists not five specific tools, but five software shapes: a local tool that runs on a single computer, a web app that uses a browser to work across devices, a native mobile app that requires phone capabilities like a camera, notifications, or geolocation, a background service that runs tasks periodically in the background, and a hardware project that connects to sensors or a Raspberry Pi. Video Original Content
This classification is worth noting because it shifts the order of the discussion back to the beginning: ask first where the software will run, who can use it, and where the data will be stored, before deciding whether to use Lovable, Replit, Codex, or Claude Code. Tools are not the starting point; the shape of the problem is.
Why most people should start with a web app
Jones’s advice is that most personal software should start as a web app. The reason isn't that it's the most advanced, but that it can be used on both computers and mobile browsers simultaneously, without the need to deal with App Store submissions and native development from the outset. Only when a product truly requires deeper mobile capabilities does a native app become worth the added complexity. This is Jones’s experiential judgment, not an independent product review.
For example, organizing a batch of files for yourself might only require a local tool; allowing family members to jointly maintain equipment records requires a web app with shared data and login permissions; automatically sorting messages daily is closer to a background service. All three can be generated by AI, but their deployment, data exposure, and failure modes are completely different.
A sentence left in the video description by Jones perfectly points out this demarcation:
"the part that stays yours is the judgment."
AI can write the interface and functions for you, but what is worth doing, where the data should be stored, who can see it, and what constitutes a failure—these remain human judgments.
Being able to run does not mean it is ready for delivery
External data makes this distinction even clearer. The Stack Overflow 2025 Developer Survey shows that 46% of respondents do not trust the accuracy of AI-generated output, while only 33% trust it; 66% cite the main frustration as answers being "almost correct, but not quite correct." This is not a sample of the general non-technical population, yet it demonstrates that even those familiar with development do not view generated results as finished products. Stack Overflow 2025 Developer Survey
A more direct counter-example comes from METR. The research team tasked 16 senior open-source developers with completing 246 real-world tasks within mature projects they were familiar with; the group using early 2025 AI tools took, on average, 19% longer. This study cannot be extrapolated to non-engineers, brand-new small tools, or today's models, but it is sufficient to debunk the claim that "using AI always makes it faster." METR Randomized Controlled Trial
METR also proactively updated its limitations in 2026: a new round of experiments was influenced by participant selection bias, providing only weak evidence for how much acceleration newer tools can bring. In other words, 19% is not a conclusion that AI coding is always slower; what is truly worth keeping is that subjective feelings and demos cannot replace real task verification. METR Follow-up Statement
Security responsibility has not disappeared due to natural language interfaces either. OWASP has listed improper trust in AI-generated code as a new risk to watch, advising the continued adoption of existing code review and security verification methods. OWASP Top 10:2025
How I would start
If I were building personal software for the first time, I would pick a small problem where the results are easy to verify, failure is reversible, and I am not touching payments, medical records, or sensitive personal information. I would select the simplest software shape and do three things:
- Write out the normal flow and at least three failure scenarios clearly.
- Determine where data will be stored, how it will be backed up, and who can access it.
- Test with a copy of real data and retain manual confirmation; do not let the first version perform irreversible actions directly.
The change I see is not that everyone has suddenly become an engineer, but that for the first time, the people closest to the problem can participate in architecture and verification at a very low cost. AI reduces the friction of generating the first version; whether it can become a reliable tool still depends on whether you are willing to undertake the part Jones mentioned: judgment.
Sources
- Nate B. Jones: Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did., published 2026-08-19, accessed 2026-08-21.
- Stack Overflow 2025 Developer Survey — AI, accessed 2026-08-21.
- Becker et al.: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, original version 2025-07-12, accessed 2026-08-21.
- METR: We are Changing our Developer Productivity Experiment Design, published 2026-02-24, accessed 2026-08-21.
- OWASP Top 10:2025 — Next Steps, accessed 2026-08-21.
Editor's Note: This article summarizes public videos and external data and does not represent the author's own practical testing of the speaker's product recommendations.