Good Tech Ideas Can Come From Anybody

There is a version of the AI coding story that is too clean to be trusted.

It says anyone can code now.

The phrase has a democratic shine to it. It sounds generous. It sounds like the gates are finally opening and the old technical priesthood has been made unnecessary by a chat box, a repository, and a few confident verbs.

But the more time I spend around these tools, the less I believe that slogan.

Not because the tools are weak. They are not. AI coding agents can produce real software, explain unfamiliar systems, scaffold prototypes, refactor files, write tests, and collapse the distance between intention and artifact in ways that would have felt unserious a few years ago.

The problem is that coding was never only the act of producing code.

Coding is attention under constraint. It is judgment about tradeoffs. It is knowing when a thing that works is still wrong, when a clever abstraction has become a hiding place, when a generated answer is plausible but unsafe, when a product's shape is fighting the user's actual life. It is naming. It is debugging. It is taste. It is responsibility for what happens after the demo.

AI can help with all of that.

It does not make all of that disappear.

So I do not think everyone can code with AI in the full sense that matters. Some people will not want to. Some will not have the patience for the strange, humbling texture of software. Some will be able to prompt a prototype into existence but not recognize when the system is brittle, insecure, incoherent, or expensive to maintain. Some will be given tools and still be failed by access, training, time, confidence, or the social permission to use them.

The better promise is less dramatic, and probably more radical: a good tech idea can come from anybody.

Most software organizations still behave as if good ideas enter through a narrow doorway. Product managers collect requirements. Designers shape experiences. Engineers build systems. Executives assign priorities. Customers complain in tickets, surveys, support calls, and churn reports. Somewhere in that machinery, lived knowledge is translated into roadmap language.

The translation is necessary.

It is also lossy.

The nurse who knows exactly where a hospital workflow breaks may not know how to model permissions, data schemas, integrations, and edge cases. The teacher who can see the failure mode in classroom software may not know how to turn that frustration into a prototype. The warehouse supervisor, restaurant manager, case worker, field technician, benefits administrator, artist, coach, accountant, parent, or volunteer may understand a problem with painful precision while lacking the technical vocabulary required to be taken seriously by the people who can build.

That gap has always shaped which ideas become software.

Not just because some people could not code, but because they could not make their understanding legible to the systems that fund, evaluate, and implement technology.

AI tools change the first mile.

They let someone move from complaint to sketch, from sketch to workflow, from workflow to rough interface, from rough interface to a small working thing that can be shown, argued with, and improved. The point is not that the first version is production-ready. It usually will not be. The point is that the person closest to the problem can now carry the idea further before it has to pass through someone else's imagination.

Visibility changes the idea itself. A vague request becomes a screen. A screen becomes a conversation. A conversation reveals missing states, bad assumptions, strange edge cases, and the emotional truth of whether anyone would actually use the thing. Software is not only a final product. It is a medium for thinking.

For a long time, access to that medium was unevenly distributed.

AI does not fix the inequality by itself. A model in a browser does not erase organizational politics, capital, domain gatekeeping, platform risk, or the brutal fact that some people have more time and safety to experiment than others. But it does loosen one important knot: the dependency on technical fluency at the earliest stage of an idea.

This is where "anyone can code" starts to feel like the wrong lesson. It keeps the prestige attached to coding and then promises to distribute the prestige more widely. The center of gravity stays the same. The heroic figure is still the person who produces software. Everyone else is invited to become more like them.

But the more interesting shift is not that every person becomes a developer. It is that more kinds of people can become originators.

Ideas do not appear in the world evenly. They come from contact. They come from irritation. They come from watching the same broken process fail on the third Thursday of every month. They come from noticing that a form asks the wrong question, that a dashboard rewards the wrong behavior, that a scheduling system assumes a life nobody has, that a piece of enterprise software turns a simple human need into a ritual of apology.

Those insights are technical before they are code.

They describe systems. They identify constraints. They recognize failure modes. They imagine alternate behavior. They may not come wrapped in architecture diagrams, but they are already about how the world should be organized.

AI tooling can give those insights a better surface.

None of this means we should romanticize the raw idea. A good idea still needs pressure. It needs people who can ask whether it should exist, who benefits, who is exposed, what breaks at scale, what data is being gathered, what maintenance will cost, and whether the prototype's charm is hiding a deeper obligation. The democratization of starting does not remove the need for craft at the finish.

In some ways, it raises the standard. If more people can begin, then the systems around building need better ways to receive beginnings. Teams will need to distinguish between a naive prototype and a useful signal. Engineers will need to become better collaborators with domain expertise that does not speak in technical shorthand. Product leaders will need to stop treating proximity to the problem as anecdotal until it has been laundered through a roadmap document.

The work of software may become less about protecting the doorway and more about improving what happens after someone walks through it. That feels like the healthier version of the AI coding future.

Not a world where craft is declared obsolete. Not a world where every person is expected to become a full-stack developer by Sunday night. Not a world where a model's confidence is mistaken for a system's maturity.

A world where more people can bring the shape of a problem into contact with the shape of a possible tool.

There is still a critic in me that does not trust the easy slogan, and I want that critic to remain. Software is powerful enough that skepticism is a public service. But the critic should not confuse the old gate with the craft itself.

Not everyone can build great software.

But great software can begin with anyone.