Vibe coding as a creative hobby: why playfulness matters more than strategy
A solo presenter argues that falling costs and improving AI tools have turned software-building into a genuine hobby, not just a professional or entrepreneurial pursuit.
Summary
Nate B Jones, host of AI News & Strategy Daily, makes the case that vibe coding — building software using natural language with AI tools — has crossed a threshold in early 2026 where the friction has dropped low enough that building software now feels like play rather than work. He uses the example of Fable, a service that generates Renaissance-style pet portraits, as evidence that playful, non-strategic ideas can find real audiences when the cost of building collapses. Jones argues that the most important skill in this new era is not coding but specification — knowing how to describe what you want clearly — and that the people who thrive will be those who develop "software vision," the ability to notice when a problem is software-shaped. He also identifies two significant failure modes: building without knowing what you actually want, and confusing a working prototype with something ready for real users.
Key Takeaways
FULL TRANSCRIPT
The shift from friction to play
Nate B Jones: Something clicked in the last couple of weeks, and the word I keep reaching for is playfulness with AI — which is probably not what you expect, because the AI discourse is super loud right now and most of it, to be honest, is ominous. Jobs are disappearing, deepfakes, misinformation, existential risk, think pieces that are anxious, comment sections that get angry. I'm not here to dismiss that. The concerns are real and we talk about them a fair bit on this channel. But there's a different story happening in parallel that we miss. It's quieter. It's a little bit odd. And I want to talk about that instead today.
Vibe coding — which is using AI to build software with natural language — has been possible since the earlier part of 2025. But for most of the year, it was still work. You had to fight the tools. You had to babysit the AI through the confusion. You had to debug weird failures that made no sense. You had to learn about databases and backend. The friction was high enough that you had to be serious about what you were building. You wouldn't want to waste that effort on something frivolous.
What's shifted in the last couple of weeks is not just that the tools got better, although they did. It's that the models hold context longer. The agentic patterns have matured. Builder platforms have gotten more reliable. The real change is downstream of all those individual pieces — it's like the Lego bricks came together to make a set. The friction has now dropped enough that building software has stopped feeling like work and started to feel like play. And play produces very different things.
The Fable example: when a joke becomes a product
Last week, a service called Fable started making the rounds. You upload a photo of your pet and it generates a Renaissance portrait with AI — your dog as a baroque duke, your cat as a Flemish noblewoman. This all sounds extremely silly, and it ships to you as a physical print. It's ridiculous. It's delightful. And it's doing a lot of business.
This is not an "identify a market need and execute" story. This is a "wouldn't it be funny if" story. Someone was playing. They built the joke. The internet turned out to have demand for it. And this is the part that caught my attention — not the economics of AI coding, although the economics are real and we'll talk about them elsewhere. The thing underneath is that software has now become cheap enough to make for fun, and people are making different things. They're making weirder things — things that come from play rather than strategy, creative things. And occasionally, because the internet is vast and has appetite for nearly anything interesting, one of those playful things finds a huge audience, just like Fable.
The internet has always been an infinite pool of demand. What's new is that the cost of figuring out that demand has collapsed. You can just try things now. You can build the dumb idea. You can see what happens. And if nobody cares, all you did was lose a weekend. And if they do care — hey, you got something fun.
The satisfaction of making something real
There's a particular kind of satisfaction that comes from making something that works. You have an idea. You figure out the pieces. At some point, the thing you imagined becomes something that exists because you made it. People who build real things for a living know this — carpenters know this, cooks know this, designers, engineers. The material varies, but the satisfaction is recognizable. You had a vision. Now you have a real thing.
For most of software's history, this satisfaction was gated behind years of specialized training. The gap between "I wish this existed" and "I made it exist" was way too wide to cross casually. Most ideas ended up dying in that gap — not because they were necessarily bad, but because the activation energy was way too high.
The gate is open now. The bridge is crossable, and people are just walking through. And they're not just startup founders looking for leverage. A lot of us — and frankly, I'm a vibe coder too — are hobbyists. We're building things for fun and we don't always have a business model insight. Vibe coding really is the hobby of 2025 and now into 2026 that nobody expected.
Software's Instagram moment
A designer can build a personal dashboard that shows the phase of the moon, their Spotify listening stats, how many days until their next vacation — all put together in a way that's fun for them. A retiree can automate their greenhouse irrigation. Someone can make a browser extension that does one absurd thing perfectly, like log every time they find an article that mentions cat grooming. A friend can get a custom Telegram bot that alerts them when concert tickets drop. None of these are necessarily businesses by themselves. They're just projects. They're built for the satisfaction of building. They're used by the maker and maybe a few of their friends.
This is new. For most of software's history, building required enough specialized knowledge that it was primarily professional. Hobbyist programmers technically existed, but "I code for fun" was a very, very niche identity — not a casual weekend activity.
What's emerging now looks a lot like what happened with photography. Taking good photos used to require very serious expertise — exposure, developing, darkrooms. I took that darkroom class in high school. Then cameras got easier. The smartphone made everyone a photographer. Instagram came along. Professional photography still exists, to be sure, but alongside it there's now a vast amateur ecosystem of people who just love taking pictures.
Software is going through its Instagram moment. The professionals aren't going anywhere. Complex systems still require deep expertise. But alongside professional development, there's now space for a service like Fable, for casual creation, building for yourself, for fun, for friends, because you had an idea and now you can make it real.
And because it's play, people try weird stuff. They follow ideas wherever they go. Some of the most interesting software I've seen has this hobbyist energy — it's not always polished, it's not always scalable, but it's genuinely creative in ways that commercial software rarely is. And I think we need that, because one of the things I've observed about commercial software is that it remains stuck in a lot of the design paradigms of the 1990s, 2000s, and 2010s. We have not fully seen what AI-native enterprise software looks like. We haven't had that injection of creative energy. And I wonder if some of it is going to come from people who are playful.
Software vision: seeing problems as software-shaped
Here's the thing about telling someone they can now build any app they want: most people say "cool" and then never think of anything to build. Not because they're uncreative, but because most people's problems aren't software-shaped — and most don't notice when they are.
There's a concept from parkour called parkour vision: the trained ability to see walls as surfaces you can run along, gaps as spaces to jump through, railings as pathways. We saw this memorably with Alex Honnold climbing Taipei 101. He saw the building differently, and so he could climb it. The city looks different to someone using parkour to traverse it because of that vision.
Software vision is like that. Programmers are trained to see repetitive tasks as automation opportunities in the same way Alex is trained to see a skyscraper as a climbable surface. Programmers will look at a manual workflow and think, "I can script this." The rest of us just keep doing it manually.
The people who take to vibe coding aren't necessarily technical. They're people who already have software vision, or who develop it quickly when they don't. They notice when a problem is software-shaped intuitively. "Hey, I keep doing this over and over." "I wish I could see all of this information in one place, but no one would ever build me software that has phases of the moon and also when my next homework assignment is due." "It's annoying that these two systems don't talk to each other."
If you've ever spent an afternoon building a complicated spreadsheet to solve a problem, I bet you have some software vision in you. If you've ever duct-taped together automations — whether that's N8N, Zapier, written macros, or bent a tool to do something it wasn't designed for — that's the disposition. I remember writing bash scripts because my audio drivers wouldn't work back in the early 2000s. That's a software-shaped perspective.
You don't need to know how to code a ton, or even at all now. You need to notice when a problem could be solved by software, and be curious enough to try. The other thing you need is some degree of comfort with ambiguity. Things won't work on the first try. You'll probably describe what you want, get something close but not right, and you'll need to figure out how to refine that description. If you require step-by-step instructions for everything, this part might get frustrating — because you can step-by-step your way into a vibe coding space, but then it's up to you to do that parkour magic and figure out what you want to make. If you're okay with that experimentation, if that iteration is part of the fun for you, you'll do fine.
Two big failure modes
I want to be honest about two big failure modes I see with vibe coding, because oftentimes people will jump all the way over and say there's nothing but vibe coding in the future. I don't think that's true.
The first failure mode is moving so fast you never stop to think. When building is instant — which it's becoming now — the bottleneck shifts to knowing what you actually want. And it's very easy to prompt before you figure that out. So you generate piles of features that don't fit together. You end up hip-deep in a project that doesn't serve any clear purpose. The build-test-iterate loop is so fast now it can feel intoxicating just for its own sake. And you can burn a weekend building software that doesn't really solve a real pain point.
The invitation here, the discipline, is to pause — to describe what you want really plainly before you start prompting. Know why you're building it, even if it's just for fun. Know what it should do, what success looks like. It doesn't have to be monetary. The tools will happily turn vague intentions into their idea of working code, but that may not be your idea at the end of the day.
The second issue is confusing "works on my laptop" with "ready for users." AI is compressing the cost of creating software towards zero, and a working prototype now takes a few minutes or maybe a couple of hours. But AI doesn't compress the cost of owning software in production. Someone will still have to answer for it. So if you want to make something that's not just for you — that actually has users, as Fable now has — then someone has to answer for when that vibe-coded project breaks at 2 a.m. when someone's trying to order a dog picture. Who carries the liability when it fails? Who integrates it with everything else?
For personal projects, if it's truly personal, it doesn't matter. Your greenhouse automation can crash and the worst thing that happens is you go water the tomato plants. Your friend group bot can have bugs and your friends can chuckle. The stakes are low and imperfection is fine. But for something that users are depending on — even for a silly dog picture app — the gap between prototype and production-grade is still real. Security researchers have found that roughly 10% of apps built on some popular vibe coding platforms have vulnerabilities, and I would say that's a low estimate. This is stuff like databases exposed to the public internet, API keys visible to anyone who looked. AI tends to handle the happy path and often misses the edge cases.
This is where platforms like Lovable are making a bet. They're running the same playbook Shopify ran from a strategy perspective — starting with "you can vibe code anything and we'll help you grow up." That's what Shopify did with shops. The tools are extending that bridge toward production: adding authentication, adding security, scaling infrastructure, so you don't have to start over when your little vibe-coded project takes off. The gap is narrowing, but it's not all the way gone yet.
Right now, vibe coding is great for prototyping, great for personal tools, great for experiments, and great for helping you figure out if an idea has legs. If something does catch fire, you may need to level up your understanding, or you may need to bring in someone who can help you go the rest of the way.
The two tool paths
You might be wondering what the tool stack looks like. There are two fundamentally different paths.
The first is the builder platform path — tools like Lovable, Bolt, Replit. You describe what you want in chat and the platform generates the application: front end, back end, increasingly database, deployment, even domain. You never see a terminal. You don't have to see code if you don't want to. This path makes sense if you have zero technical background, you need something fast, or you're building a prototype. The trade-off is control — those platforms optimize for speed to first demo, not for long-term maintainability, and you have to be intentional about that.
The second path has a little more of a curve. It's command-line tools — tools like Claude Code, Cursor, Windsurf. You work in a code editor or a terminal. The AI writes the code, you do see it, you run it locally, you commit to your own repo, and you deploy it when you choose. If you have some technical comfort, this doesn't feel scary. If you want to understand and own what you're building and learn, this is also a great path. It gives you the flexibility to change your tools very easily without starting over. The trade-off is obviously the friction and the setup — there is more of a learning ramp, and you need to be comfortable enough with a command line to run basic operations. But the code truly is yours. It lives in your repo. You get to read it, you get to modify it. For someone who wants to either really learn deeply or build for the long term, this is often the right call. The extra friction up front pays dividends in control and flexibility down the line.
Managing AI context degradation
One more concept worth keeping in mind for both of these paths: AI coding tools degrade over conversation. The model will contradict itself, it will forget what it built. Your solution in both cases is to break work into small tasks and run each task in as fresh a context window as possible. Instead of one long conversation that can meander, make sure you have clear tasking for a particular job and define it precisely.
If you're setting up a full engineering project, this often looks like defining a spec and assigning multiple agents to work on it. But in vibe coding, what it often looks like is writing out what you want to accomplish as a very simple task — in Lovable, "this one thing I want to do," or in Claude Code, "fix this particular thing and tell me when you're done."
What you can actually build
You can build real stuff. You can build a working web application easily in a weekend at this point. You could build a client intake form that saves responses to a database — no problem. You can build an internal tool for a small team. You can build a personal dashboard that pulls data from APIs you're already familiar with. These are not impressive to professional developers, and they don't need to be. They can be very fun little projects if you have that software-shaped mind we talked about.
And yes, you can build something more if you want. I've seen people vibe code an entire customer relationship management app for a small business — not a big business, not something that's hundreds of people, but for a small business it was good enough.
The skill that actually matters: specification
The skill that matters in all this is learning how to prompt to extract the most value. This is intuitive if you're an engineer, but it may not be intuitive if you've never engineered before — because the valuable skill isn't really coding anymore. It's specification.
Experienced developers know how to break problems into pieces so that what is coded is very useful and contributes to a whole. They know what questions to ask: what happens when a user isn't logged in, what if the database is slow. Beginners tend to prompt more vaguely and accept whatever the AI generates.
You don't need to be a professional developer to walk across this bridge, but you do need to develop enough intuition to specify clearly and evaluate with a degree of critical thinking. It's a much smaller gap than learning to code from scratch, and it will close faster with practice. Essentially, you need to build an intuition for building software-shaped things. Start small. Notice what goes wrong. Develop a sense for what questions to ask effectively. The more small projects you work on, the faster you tend to go.
Practical advice for getting started
If I were to give you a few pieces of advice for starting to build:
One — it really is fun. Start with something you actually want. That's going to give you motivation and help you get going.
Two — describe before you build. Actually take the time to write it down.
Three — accept that your early attempts are going to be rough, and that's okay. It's part of building your intuition.
Four — stay in the shallow end until you're comfortable. You don't need to jump to building something really big. Remember, you can be playful.
Five — know when to ask for help. There's a fantastic community of very experienced engineers who also vibe code. They hang out on X, they hang out in Discords. You can ask them and you will get lots of answers.
Where this is all going
I don't know where the software creation hobby is going to go — it's all exploding faster than we can keep track of. Maybe it stays niche. But the tools are going mainstream, and "I built a little app for that" may soon become as common as "I made you a spreadsheet."
What I keep coming back to is the conjunction of three things that haven't all been true before. First, building software is now inherently satisfying — the feeling of making something that just works. That has always been true, but it used to be gated behind years of specialized learning, and that's not the case anymore. Second, the internet has nearly infinite demand for interesting things. That's been true for a while, but finding out what the internet had demand for was historically very expensive — you had to invest real time and money before you knew. Third, the cost of building something is approaching zero for hobby-scale software. That is really new. And making it fun is even newer — it's just a few weeks old.
The cost of experimentation and playfulness has collapsed. If you put all of those together, something new emerges. You can be playful. You can try the idea. If it doesn't work, you didn't lose that much time. If it does, maybe the internet loves your dog pictures.
This isn't really about hustle. This isn't really about an arbitrage opportunity — although you can use these same skills for both of those things. It's closer to what happens when any creative tool becomes widely accessible. Like photography, when people have a smartphone in their pocket, more people take cool pictures, and the things they make are more creative and weirder and more varied, because we're just a very diverse species.
Some people will use this tool and walk through the door and build businesses, and that's fantastic — the startup use cases are real. But the interesting story may be the people who walk through just to make things for fun. They don't necessarily have growth metrics. They just have the pleasure of building their own tools and following the ideas where they lead. The exciting thing to me is that the tools exist now that make that degree of playfulness possible. And the internet truly becomes your playground.