Just two years ago I spent most of my working day writing code. Today much more of my time goes into describing what is to be built, checking the results and making decisions. With the help of AI, more code gets written than I used to see in a week. I have to be able to judge whether it is fit to use.
This change affects the whole way projects are delivered. A developer uses their experience differently, an agency has to rethink its pricing, and a client can commission work that previously didn’t fit the budget. Each of these parties, however, has a different job to do.
Experience matters when judging a solution
In my work, defining the task precisely matters more and more. A model needs a description of what the application is supposed to do. If the description is incomplete, the generated code may look correct and still solve a different problem from the one the client came with.
That is why after the code is generated I have to go back to the assumptions and assess the result. This is where I draw on experience from earlier implementations. It helps me recognise a wrong solution before it reaches the store and decide what needs fixing. The speed of writing itself matters less and less in this process.
You can see this in the example of the PrestaShop experts directory I once worked on. Three developers built it over three months. Today I estimate that with current tools I could do the same project alone in a month, including code review. Much of the work back then was repetitive, and that is exactly what is easiest for me to speed up now.
It’s harder to start with simple tasks
This way of working raises the problem of learning the profession. A junior developer used to gain experience on simpler, repetitive tasks. Someone had to do them, and the junior had the chance to write the code themselves and understand how it works.
When a model takes over these tasks, a beginner is expected sooner to assess a finished solution. But that assessment requires knowledge that used to be gained precisely by writing. I don’t yet have a good answer to how this kind of learning should look. What I do see is that the traditional way into the profession needs rethinking.
Pricing has to reflect the new way of working
For years agencies based their quotes on developer hours. They estimated the time needed to complete tasks and multiplied it by a rate. The accuracy of those estimates determined how much was left of the project after costs were covered.
If some tasks can be done several times faster, the old calculations no longer reflect the actual effort. Some agencies lower their prices and take on more work. Others keep their prices, basing their offer more on understanding the client’s needs and taking responsibility for the implementation. There are also contractors who still price projects on the old assumptions.
From the client’s point of view, what counts is an explanation of what the offer includes. How long will it take to understand the needs? How will the code be produced and who will check it? What will the contractor do if a problem appears after launch? The mere statement that AI is used answers none of these questions.
Lower delivery costs open up new possibilities
For a store owner, shorter working time can mean a cheaper module, a warehouse integration or a checkout rebuild. Changes postponed because of cost then become possible within the current budget. It is a very practical result of how these tools have developed.
The saving only makes sense, however, if it covers delivering a working solution together with checking it. Code can be generated quickly without any review too. A module launched after one evening’s work may work until the first platform update or the first unusual order.
I expect to see more and more such cases in audits. Finding the cause of a failure still requires understanding what happened, and it doesn’t get cheaper just because the code itself was written quickly. That is why, when choosing a contractor, I would ask about tests, code review and responsibility for later fixes.
First you need to know what is worth building
Whatever the tools, a store needs a solution that fits the way the company works. The data model has to be designed around its processes. For an ERP integration I still need to talk to the person who knows why the batch number ends up in the notes field. I won’t find that in an example in the documentation.
The same goes for a migration decision. Before I advise changing platforms, rebuilding the store or keeping the current solution, I have to compare the costs of these options. AI helps with doing the work, but without knowledge of the company it won’t choose the right direction for the client.
That is exactly why conversations, decisions and assessing results take up more of my work today. I can build a solution faster, so I want all the more to establish first whether the client really needs it and whether the cost of building it is justified.