A few days ago, I created a first version of my website mainly with coding assistants such as Codex and CoWork. It worked, the overall direction was in place, and I could easily have kept improving it step by step.
Yet only a few days later, I decided to rebuild almost all of it. The first version was neither bad nor unusable. I had simply developed new ideas, and starting again on a cleaner foundation looked faster than adapting what was already there.
That is the part that struck me most. Development speed is impressive, of course, but the deeper change may lie elsewhere: when rebuilding a project becomes almost as easy as correcting it, our relationship with software starts to change quite seriously.
Rebuilding the site instead of modifying the old one
Not long ago, a website like this would probably have required several weeks of work with a provider. The project would have needed defining, mockups preparing, interactions explaining, then several rounds of delivery and corrections. Any major change would also have raised the question of cost. Once a structure has been approved and developed, asking for a complete rethink becomes a much harder decision.
In my case, I could build a first version, use it as a thinking tool, identify what worked and what did not quite match my intention, then restart once the idea became clearer. The first version was not wasted work. It helped me understand the project, test an organisation and clarify what I wanted next.
At the same time, I began adding applications and small games to the site, also built extremely quickly with several AI tools, including CoWork, GLM and Gemini. Decisions like these become much easier when they no longer represent days or weeks of additional development.
Visible progress from one project to the next
I regularly use several assisted-programming models and tools, and their progress is becoming difficult to ignore. In one year, generated code has improved, but that is only one part of the change. Tools understand requests better, produce more coherent interfaces, make fewer errors and are increasingly able to repair an existing project without breaking what already works.
The visual results have improved too. Models once needed extremely precise guidance to avoid generic interfaces. A clear direction still matters, obviously, but some tools can now produce a usable first visual foundation very quickly, with hierarchy, spacing and interactions that already hold together.
This reminds me of what happened with image generation and then video. Early versions mostly demonstrated the principle; soon afterwards, the tools became genuinely usable in projects. Code appears to be following a similar path, although the consequences are different because software is more than its appearance. It must work, preserve data, handle errors and remain understandable when we return to it weeks later. For now, that still requires checking the output and correcting it regularly. Even so, the speed at which problems can be solved already changes the way we work.
Models do not all work in the same way
One of the most interesting things about using several models every day is how differently they still behave. Some understand a visual request particularly well and quickly build an interface close to what I imagined. Others are better at the overall structure of an application, file organisation or the way functions should communicate.
Some models are excellent at taking over an existing codebase, locating a problem and suggesting a clean fix, while being less convincing when asked to design the project from scratch. The ranking is not always what release dates or general benchmarks would suggest. On a precise task, an apparently older model can still outperform a newer one, and a few weeks later the situation may change again.
Choosing the model therefore becomes part of the work. I rarely use a single tool for everything. I may begin with the one that best understands the general structure, switch to another for the interface, then use a third to solve a specific problem. This workflow remains unstable because performance changes quickly and responses can be unpredictable, but it is already faster than forcing one model through every stage.
The work increasingly begins before the code
Generating code quickly does not remove the need to think about the project. In my experience, that thinking becomes even more important. When development represented most of the time and cost, attention naturally focused on technical feasibility: whether a feature was realistic, how long it would take and whether it justified the effort.
Today, a first version can appear much earlier. The problem moves towards defining what we actually want to build. We still need to understand the need, the people who will use the tool, the menus, screens, interactions and priorities. An AI can propose many things, but it does not naturally know the objective, the audience or why one feature matters more than another. It can also produce a perfectly functional interface that does not truly solve the original problem.
The human role is gradually moving towards conception, art direction, decisions and corrections. Code remains important, but it is no longer necessarily the main obstacle. My own process is becoming quite natural: I first work on the idea and the general organisation, define the main features, screens and interactions, then select the tool that seems best suited to a first version. After that, I correct as I go by looking at the result instead of trying to predict everything perfectly in advance.
Creating software for one precise need
This experience made me think above all about the lifespan of the software we use. Today, when we need even a very simple tool, the usual instinct is to search for an existing one. We compare products, install one, learn it, sometimes create an account or accept a subscription, and adapt our workflow to the publisher’s choices.
For many needs, that will remain the sensible approach. Rebuilding a complex, maintained product on your own would be absurd. But the situation may evolve quickly for very specific tools: a calculator adapted to a profession, a special converter, an analysis tool, a filing system or a small application that automates one repetitive task.
An architect could create a measurement tool that matches their way of working. A craftsperson could build a quotation system limited to their own activity. Someone working in property rentals could make an interface organised around exactly the information they need. In my projects, it might be a storyboard, a speed-painting generator, a small educational game or an application designed for one training course.
These tools would not necessarily be complete products intended to be sold and maintained for years. They could answer a temporary need, be used for a few days or months, then be abandoned. The phrase disposable software may sound negative because it suggests poor design or unreliability. I mean something else: a tool whose lifespan matches the real need. The aim is not always to create a universal solution, but simply the software required at a particular moment.
Autonomy beyond developers
This evolution does not only affect people who already work in software. A teacher can create a tool to explain a concept. A designer can automate a very specific part of a workflow. A student can build an interface to classify or analyse research data. A researcher can adapt a tool to an experiment without waiting for a commercial product to add the required feature.
The result will not always be perfect, and these tools cannot all be used in sensitive contexts or at scale without further checks. There is an important difference between a small personal application and software that must be secured, maintained and used by thousands of people. Nevertheless, a new form of autonomy is already becoming possible.
The situation resembles what happened with AI-generated images. Many people had long wanted to illustrate a book, make a comic or short film, or simply tell a story visually without having the technical skills to do it alone. Generative tools did not replace creative work, but they allowed more people to move from an idea to a first realisation. Code may follow the same path. People who have imagined a particular tool for years will be able to begin making it themselves, even if they do not consider themselves developers.
What this may change for software professions
It is still difficult to know how far this will go. Developers, web designers and automation specialists retain essential expertise, especially when a project has many users, sensitive data or complex architecture. Understanding needs, usability, security, user experience and maintenance cannot be solved by simply asking a model to generate code.
Still, part of the technical work can already be completed much faster. Value may shift further towards understanding a project, structuring a solution, making sound decisions and verifying the result. For small websites and simple applications, the boundary between designer and developer is already becoming less clear. Someone who knows their field and knows precisely what they want can now produce a first version that previously required several specialists.
Technical expertise will probably remain necessary much longer on larger projects, even as teams use the same tools to move faster. There are also broader limits: assistants can generate insecure code, misunderstand an instruction or modify a part of the project that should have remained untouched. They can also be used for malicious purposes.
These reservations matter, but they do not change the trend I observe in my own projects. I already knew coding assistants could create a site or a small application. What I had not fully anticipated was how easily I could revisit those projects, modify them and sometimes rebuild them completely whenever a better idea appeared.
That possibility will probably have the greatest impact on the way I work. Software itself may become less precious simply because producing a new version becomes easier. The idea, the understanding of the need and the way the tool fits into a real project will matter more. Eventually, creating a small application could become almost as ordinary as preparing a document, building a spreadsheet or generating an image to illustrate an idea.
For now, I am still testing this way of working, but choosing to rebuild my website only a few days after creating it already shows that something has changed.