After Version One
Every few years we convince ourselves that software is about to disappear. Some layer of the industry is declared finished, some profession is supposedly on borrowed time, and everyone is told to adapt. Most of those predictions have aged badly. This time the argument feels more convincing because the change is visible in the work itself. With every new model release, the distance between an idea and a viable artifact gets shorter. Things that once took days can now appear in hours or minutes, and it is easy to look at that acceleration and conclude that building software has mostly been solved.
Software has always moved through layers of abstraction. Higher-level languages moved us away from assembly, frameworks removed repetitive work, and cloud infrastructure made it possible to deploy systems without understanding every machine underneath them. Each shift moved more of the work away from mechanics and toward intent. What is happening with models feels larger than those earlier changes, but the pattern is still useful because it shows how often we mistake one disappearing difficulty for the disappearance of difficulty altogether.
The longer I spend building with these tools, the less I think producing code was ever the central problem. Plenty of software gets built successfully and still goes nowhere. The wrong problem gets solved, early assumptions become structural constraints, complexity accumulates faster than anyone can make sense of it, users behave differently than expected, or the first working version becomes something the team is afraid to disturb. The difficult part is spread across the decisions that follow implementation: what to preserve, what to remove, what to simplify, what to rethink, and what to do when the thing you built meets conditions you did not anticipate.
The tools have still changed my work substantially. They let me explore ideas earlier and reduce the cost of changing direction. More of the work can happen before a team has committed significant time to a particular approach, which means weak ideas can be discarded earlier and useful ones can be tested sooner.
What has not disappeared is the work that happens once something exists. You use it, notice what feels wrong, change it, break something else, watch someone misunderstand it, discover an edge case, reconsider part of the structure, and gradually get a better sense of what the thing needs to become. Faster implementation gives you more opportunities to enter that loop, but it does not remove the loop itself.
Making the first version cheaper is still a meaningful change. More people can try things that would previously have required much more time, money, or technical ability. That changes who gets to participate and how much can be explored before committing serious resources. But lower barriers to starting do not remove the need to develop judgment about what should happen after the start.
That is the part I am most interested in now. As these tools become ordinary, the novelty of producing something from a prompt will matter less. We will still have to decide what is worth building, recognize when a system is becoming harder to reason about, learn from the people using it, and continue changing it long after the initial excitement is gone. Producing the first artifact is getting much easier. Everything that follows still has to be worked through.