For most of my career, building software felt like planning an expedition. You mapped the route before you left. You wrote specs, estimated timelines, reviewed the plan with colleagues. The friction of actually building was high enough that you had to be reasonably sure the destination was worth it before you set out.
That changed for me somewhere in early 2025 — gradually, and then all at once. The tools got reliable enough that building stopped feeling like work and started feeling like exploring.
What play actually produces
There is a word floating around for this: vibe coding. The label sounds frivolous at first. But it captures something real about the mode of thinking that low-friction building enables.
When building is hard, you optimize for the ideas most likely to succeed. When building is easy, you can follow an idea wherever it goes — even the strange ones, even the “wouldn’t it be funny if” ones. One example stands out: a product that generates Renaissance-style portraits of your pet and ships you a physical print. Ridiculous. Reportedly pulling in six figures a month. Not born from a market analysis — someone was playing, the internet turned out to have latent demand for it, and now there is a real business.
This is not an argument that all dumb ideas are secretly good. Most of them are not. The argument is that the cost of probing whether an idea has legs has dropped dramatically. You can try things now. If nobody cares, you lost a weekend.
The skill that actually matters
Here is the counterintuitive part: AI coding tools work better for experienced developers than for beginners. Not because beginners cannot use them, but because the bottleneck shifted.
The bottleneck is no longer coding. It is specification — describing what you want precisely enough that the AI can build it. Experienced developers know how to decompose a problem. They know what questions to ask: what happens when the user is not logged in? What if the database is slow? What if someone enters invalid data? They can evaluate whether the output makes sense.
Beginners tend to prompt vaguely, accept whatever comes back, and hit a wall they cannot debug because the mental model for the problem was never built.
There is a related concept worth naming: software vision. It is the trained ability to look at a manual workflow and think “I should automate this.” It develops not by learning to code but by noticing when a problem is software-shaped. If you have ever built a complicated spreadsheet to solve something, duct-taped together automation tools, or bent an app to do something it was not designed for, you already have the early form of it. The gap between “notices software-shaped problems and can describe them clearly” and “effective builder” is closing faster with practice than the full gap to professional developer.
The honest limitations
Play is not the same as recklessness. Three things can go wrong, and going in with eyes open is what separates a productive weekend from a frustrating one.
Context rot. AI coding tools degrade over long conversations — the model starts contradicting itself, forgetting what it built, suggesting changes that break previous work. For weekend prototypes this may never matter. For anything bigger, the fix is deliberate: break the work into small tasks and run each in a fresh conversation. Memory lives in the codebase, not in the AI’s context window.
The prototype-to-production gap. AI compresses the cost of creating software toward zero. It does nothing to compress the cost of owning software in production. A security researcher scanning publicly-deployed AI-generated apps found vulnerable database configurations in roughly one in ten projects — API keys visible to anyone, databases exposed to the public internet. The pattern is consistent: AI handles the expected path and misses the edge cases. For personal projects, imperfection is usually fine. For anything handling real users and their data, a few hours of professional security review before launch is not optional.
Knowing what you actually want. When building is instant, the bottleneck shifts to clarity of intent. Vague prompting generates working code that misses the point — which is worse than no code at all, because now you have something to maintain.
The 4 prompts that make it safe
Before building anything, run through four questions in writing — not in your head, in writing:
1. Software Vision Check. Is this actually the right project, and is the right person building it? Does this problem genuinely benefit from software, or is the wrong tool being reached for?
2. What You Are Building. Not “a dashboard” — what exactly should this show, what triggers it, what does success look like, and what should happen when something goes wrong?
3. Tool Fit. Builder platform (fast, disposable, no code visible, platform owns deployment) or a code editor with an AI assistant (slower, code is yours, tool-portable, easier to maintain)?
4. Achievability Audit. What can honestly be finished before Monday morning, and what is genuinely out of scope given the current constraints?
The discipline of writing the answers down before touching the tools is the single habit that changed my hit rate the most. Vague prompting generates outputs that miss the point; a clear written spec generates outputs you can actually use.
Where this goes
My guess is that software vision and specification will emerge as standalone skills in the next few years — things people deliberately practice, not just byproducts of learning to code. The amateur software ecosystem forming now (building for yourself, for fun, for friends) will develop its own craft traditions and its own vocabulary for what makes a spec good enough to build from.
The interesting question is not whether AI changes who can build software. It already has. The interesting question is what people actually build when building is finally, genuinely, fun.
Text summarized and optimized using Anthropic’s models and reviewed by a human.