There’s a second-order effect of all this that I think is more important than the impact on developers, and it’s also the one that most people are not emotionally prepared for. When implementation becomes cheap enough, software stops being a scarce industrial product that you “get” from vendors, and starts behaving more like a medium. Something closer to writing, or illustration, or woodworking. You still need taste, persistence, and judgement, but the barrier to trying an idea drops sharply.

That shift is going to create an explosion in creativity, and not the tidy kind.

It will be messy. It will be uneven. It will produce a lot of mediocre work. It will also unlock a category of software that simply hasn’t been economically viable for most of the history of computing: software built for a small group of people, or even one person, because it fits them.

For most of us, the idea of “software” still carries the assumption of compromise. You buy a tool and it almost does what you need. It has a feature you dislike, a workflow that doesn’t match your brain, a pricing model that feels absurd, an accessibility gap that makes it hostile to people who don’t fit the assumed user profile. You learn the tool anyway, because the alternative is worse. You bend your work around it, because bending the tool around you has historically been expensive.

That’s the part that changes.

From “what tools exist?” to “what do you need?”

Think about how much modern work is shaped by tooling that was never designed for your context. A company adopts a platform, and then the entire organisation quietly adapts itself around the contours of that platform’s assumptions. People build workarounds, spreadsheets, shadow processes, and unofficial guides. Whole roles exist to compensate for mismatches between the tool and the job.

Once implementation becomes cheap, a lot of those mismatches become optional.

Not immediately, and not universally, but enough that the mental model changes. Instead of asking “what tool should we buy?”, the question becomes “what should this tool do for us, and why doesn’t it already?” Once you can ask that question without committing to a six-month project, you start to see opportunities everywhere.

This doesn’t mean every team will build everything. Off-the-shelf tools will still exist, and many of them will still be good. But the centre of gravity shifts. The default assumption that you must accept compromise because building is too expensive becomes less true, and that is a big deal in a world where most software is, frankly, not very good.

Hobby projects stop being a lifetime backlog

Every software hobbyist has a private museum of unfinished ideas. A game that exists as a few sketches and a folder named “prototype2”. A tool you wanted for your own workflow. A plugin you wished existed. A small niche product that would make a community’s life easier, but never felt worth the time investment.

The bottleneck has rarely been imagination. It has been legwork.

There is a lot of unglamorous work in software: scaffolding, wiring, configuration, UI glue, integration with libraries and frameworks, build systems, boring edge cases, and “getting it to a place where it’s even fun to iterate”. When that part becomes cheap, more people will finish things. Not because finishing is effortless, but because the cost of getting to the interesting part drops.

You still need persistence. You still need taste. You still need someone to decide what the thing should be. But the shape of the effort changes, and that changes the kinds of projects people will attempt.

Personal software becomes normal

The most interesting outcome of cheap implementation is not “more software”. It’s more personal software.

A lot of people live with tools that don’t fit them, and the industry has been slow to fix it because personalisation is expensive. That is particularly visible in accessibility. If your needs aren’t captured by a mainstream persona, you often end up with tools that are technically available but practically unusable.

When building becomes cheap, personalisation becomes feasible.

Consider a concrete example: Home Assistant. I love it. It’s powerful, flexible, and it rewards the kind of curiosity that makes home automation fun. It is also dense, and the UI can be punishing. Building dashboards is fiddly and time-consuming, and you can easily spend an evening dragging widgets around and still end up with something that feels like a compromise.

That is exactly the kind of problem an agent can take off your hands. Not by “solving accessibility” in the abstract, but by doing something specific and practical: produce three dashboard designs for how you actually live, implement one, iterate based on screenshots and feedback, and keep refining until the UI matches your needs rather than the default assumptions of a generic tool.

Now widen that idea.

People with motor impairments need different input modalities. People with visual impairments need different output modalities. People with cognitive load issues need interfaces that minimise distraction and complexity. People who are neurodivergent often need tools that align with their particular pattern of focus and organisation, not the pattern assumed by the average product team. Historically, those needs have been addressed slowly, and often only where legislation or market scale forced it.

Cheap software changes the economics. It becomes realistic to create tools that fit smaller communities, and to iterate them quickly based on feedback from the people who actually need them.

The “bad software” problem is real, but it already exists

A predictable response to all of this is: “We’re going to end up with a lot of bad software.”

Yes.

But we already have a lot of bad software, and the difference today is that bad software often becomes the only viable option in a market. You pay for it, you adapt to it, and you carry the friction as a tax on your time and attention.

In a world where building is cheap, the balance of power shifts slightly. You get to be choosier. You get to customise. You get to replace a painful workflow without needing permission from a vendor roadmap. That doesn’t guarantee quality, but it changes the dynamics of who controls the tools.

There is also a subtle point here about taste. If the raw act of implementation becomes cheap, taste becomes more valuable. The differentiator becomes the ability to decide what a tool should be, and to keep iterating until it feels right. That applies to individual hobbyists, teams, and communities.

Who gets to build next?

One of the most exciting things about this shift is that it is not restricted to people who identify as developers.

Product managers are well-positioned, because they already think in terms of needs, constraints, user stories, and acceptance criteria. Designers are well-positioned, because they have strong instincts for interaction and feedback loops, and can steer iteration based on user experience rather than code structure. Domain experts are well-positioned, because they know where the real friction lives, and can describe it in ways that a generalist engineer might miss.

And then there are the people who have historically been locked out entirely, not because they lack ideas, but because they lack the time, money, or technical gatekeeping to turn ideas into working tools. When software creation becomes more conversational and more iterative, more people get to participate. That is a cultural change, not just a technical one.

There’s a saying in the maker community: just go out and make something. The interesting part of the next few years is that this becomes more literal than it has ever been in software. The constraint stops being “can you code?”, and becomes “can you decide what you want, and keep iterating until it exists?”

If that sounds like a creativity explosion waiting to happen, that’s because it is.

Just go out and make something.