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.

Artykuł AI is changing our world pochodzi z serwisu eCommerce Expert.

I come back to this project because it shows well how my work has changed. I know its scope and I remember what we spent our time on. So I can compare specific tasks with how I would approach them now.

A simple directory, a lot of work underneath

The PrestaShop experts directory is a catalogue of certified agencies. A store owner browses their profiles, checks their specialisations and references, and then contacts the chosen contractor. Agencies manage their profiles and take care of how they present themselves against the competition.

From a visitor’s point of view the principle is simple. When building it, though, every stage needs attention: data entry, validation, search and presentation of results. A filter selected on the page must match the parameters in the URL and the database query. A form should accept valid data and catch invalid data. Everything has to work across different language versions.

On top of that comes the admin panel. The directory’s users never see it, but building it took as much work as the public part. These are the tasks that filled week after week for us: necessary, often repetitive, and each one requiring code to be written and checked.

Three people also meant time spent on collaboration

Splitting the tasks let us work in parallel, but it required daily coordination. We waited for code reviews, agreed on solutions and merged changes made in different parts of the application. In the schedule this collaboration looked smaller than it later turned out to be in practice.

That is why three months of work by three people is much more than just writing features. That time also included everything needed to turn separate pieces into one working application.

What the work would look like today

Over recent months I have built myself a set of tools based on language models. I hand a large part of repetitive programming work over to them. For a directory like this I would start by describing the data structure and the rules of operation, and then use that to create the application skeleton, migrations and the admin panel.

These are tasks where today I think in days rather than weeks. The same goes for forms, validation and language versions: a shared description lets me generate related pieces that previously had to be written separately. My job then is to check whether the result matches the assumptions. Places where the solution departs from the typical pattern need particular attention.

The place of testing in the whole process has changed too. Tests used to be left until the end, if there was time, and there rarely was. Now they are written together with the code. I can move straight on to review without waiting for a second developer to finish their task.

Hence my estimate: one month of solo work instead of nine person-months. A large part of that earlier effort went into activities that tools now handle. Working alone also removes the time needed to coordinate three people.

What I account for in that month

I would still need to talk to the people who will use the directory. To agree what an agency profile contains, who can edit it and how search works. The country filter is a good example. Should it indicate where the agency is based, or the market it serves? Both options can be programmed. The choice depends on how a store owner looks for a contractor.

A model can suggest an answer, but without knowing users’ needs it is easy to make a wrong assumption. Writing code faster doesn’t relieve me of making that decision.

In the estimated month I also include reading and checking the generated code. It needs at least as much attention as code written by hand. A solution that looks finished can lull you into a false sense of security, and I am still the one responsible for how it works.

What this comparison says about project pricing

That month is my assessment of a specific project that I know. It shows how much the contractor’s way of working matters to the cost of an implementation. For years we mainly counted the time developers needed to write a solution. Today, for repetitive tasks, that effort can be much smaller.

If you are commissioning a similar panel, ask the contractor to explain what they will spend the quoted time on. How do they use AI? How much work do they plan for defining requirements, and how much for checking the result? You will learn more from that conversation than from the number of hours alone.

This comparison also led me to take a broader look at my profession and how implementations are billed. I write about it in the article AI is changing our world.

Artykuł The project we had three months for pochodzi z serwisu eCommerce Expert.