AI is becoming an increasingly important part of the day-to-day work of e-commerce development teams. It helps generate code, write tests, analyze existing solutions, create documentation and navigate unfamiliar parts of a project more quickly. In e-commerce platform development, this sounds particularly attractive. Projects are complex, backlogs are long and developer time is expensive. If some of the work can be completed faster with AI, a natural question follows: can artificial intelligence genuinely shorten development time and, as a result, reduce the time and cost of an e-commerce implementation?
It can, but it does not happen automatically.
Generating code faster does not necessarily mean delivering good functionality faster. The solution still needs to be understood, verified, tested and maintained. It also needs to fit the architecture of the entire system and its business logic, which in complex B2B or B2C e-commerce can be far from standard.
So where does AI actually save time in development, and where can a lack of control turn today's time savings into tomorrow's technical debt?
The potential of AI in development is not spread evenly across all tasks.
The greatest gains can be achieved when the problem is well defined, the context is clear and the result can be verified relatively easily. The less explicit the requirements are and the greater the impact of a decision on the architecture of the entire system, the more important the role of an experienced developer becomes.
An e-commerce project involves many elements that are necessary but do not require a solution to be designed from scratch every time.
These may include forms, CRUD operations, basic endpoints, admin panel components or other repetitive parts of an application.
If the project has clearly defined conventions, AI can prepare a large part of this code much faster than a developer writing every element manually.
The key phrase here is "if the project has clearly defined conventions". The model needs to know how code is organized in the project, which patterns are used, how dependencies work and what it should not do. Otherwise, faster code generation may simply mean creating new and inconsistent ways of solving the same problem just as quickly.
We use AI, among other things, to implement code based on prepared and verified Behat scenarios and to generate tests. This allows us to test the code more extensively. Deptrac and PHPAT now play a greater role in our process, and we have also introduced tests for JavaScript components, which previously were not standard for us due to the nature of our projects. AI also helps us with refactoring and organizing code. Entropy appears over time even in projects where we pay close attention to quality. The ability to work with AI in parallel means that we can more often restructure parts of a project so that they follow the rules and dependencies discovered during its development.
AI can reduce the time needed to understand syntax, an API, a library or a part of the stack that a developer does not work with every day. It does not replace architectural knowledge or experience, but it can reduce the time spent searching documentation, looking for the right example or solving simple problems caused by unfamiliarity with the syntax.
The same applies when working with an existing project, often one that is large and has been developed over many years. Understanding dependencies, locating the part of the code responsible for a problem, analyzing an existing implementation or preparing documentation for a change are all tasks where AI can support a developer just as effectively as when writing new code.
The same principle applies here: AI helps you reach an answer faster. The developer still needs to determine whether that answer is correct in the context of the entire system.
AI can also speed up test preparation, particularly when the developer has already clearly defined the behavior that needs to be verified. It can help create initial versions of scenarios for new functionality.
This does not, however, automatically improve quality.
AI-generated tests can also be incomplete or check the code in a way that does not reflect the actual business process. In e-commerce, this is particularly important in areas such as pricing, discounts, payments, product availability, orders and integrations with external systems.
AI can therefore reduce the time required to prepare verification elements, but it does not take responsibility for determining what should be tested and why.
We follow these principles ourselves, although the exact process depends on the project. An example flow starts with using AI to generate Behat scenarios that serve both as acceptance tests and as a functional specification. We also use AI to generate architecture and static analysis tests, unit tests and functional tests. We have also expanded our approach to include testing JavaScript modules, which previously was not a standard part of our process.
The greatest risk appears when we start treating the speed of code generation as equivalent to the speed of development.
With AI, a developer can create a solution in a matter of minutes. But if the code does not fit the architecture, duplicates existing logic, creates unnecessary dependencies or fails to account for edge cases, the team will pay for those savings later.
It is equally important to recognize our own limitations and the areas where we lack expertise. Using AI in development does not give us the skills required to evaluate a solution in a field we were not previously familiar with.
A good example is Open Mercato. When a designer joined the project, she discovered that the system contained as many as 324 shades of red. None of the developers had previously identified this as a problem. When generating the code, no clear rules had been established for color consistency or where colors should be defined. Some shades were stored directly in modules instead of CSS, so subsequent iterations gradually added technical debt to the project.
This leads to a simple principle: if we do not have expertise in a particular area, using AI does not automatically give us that expertise. Without the skills required to verify the result, we may simply introduce solutions into the project faster without being able to properly assess their consequences.
This problem is particularly important in e-commerce, where a single feature rarely works in isolation. Changing the way a price is calculated can affect promotions, the cart, checkout, ERP integration or reporting. A poor architectural decision can therefore affect a much larger part of the system than the size of the generated piece of code might suggest.
In complex e-commerce, one of the most difficult challenges is not writing the code, but understanding the business and correctly representing its rules in the system.
Which system is responsible for pricing? Where should inventory data live? Does a particular rule belong in the e-commerce platform, the ERP or another component? What happens in an exception scenario? How will the solution evolve two years from now?
The model can suggest an answer. However, it does not automatically know the full context of the organization or the consequences of the decisions it makes.
That is why decisions about domain modeling, system responsibility boundaries and key architectural elements still require deliberate decisions from the team.
AI can speed up the implementation of an architectural decision. It should not replace the process in which that decision is made.
This is the paradox of AI-assisted development.
The faster code is generated, the more important code review, testing, standards and architectural consistency become.
If a developer accepts one model suggestion after another without fully understanding them, the initial acceleration can lead to more dependencies, duplication, inconsistent patterns and code that no one wants to change later.
This is where AI and technical debt begin to intersect.
The reason is not that AI-generated code is inherently bad. The problem arises when an organization increases the rate at which code is produced without simultaneously increasing its discipline around architecture, testing and review.
It is also important to remember that not every problem requires the same level of control and understanding. Moving a button, changing a color or implementing a simple business rule involves a different level of risk than changing payments, pricing or other critical elements of the system.
The greater the potential consequences of an error, the more important clear rules, precisely defined expectations and deliberate verification of AI-generated results become. The team therefore needs not only to know how to use AI, but also to be able to assess which tasks can be delegated to it with greater freedom and which require significantly more human oversight.
And this brings us to the most important condition for using AI responsibly in development: the model needs to work in an environment that clearly defines the rules, context and boundaries of its operation. Simply adding Codex, Claude or another tool to the development process does not provide this.
AI can generate code very quickly. The problem is that in a large e-commerce project, it is not enough for the code simply to work.
It also needs to fit the existing architecture, follow established patterns, respect boundaries between modules, handle data correctly and remain safe for future developers to build on for years to come.
This is why greater use of AI increases the importance of something that may seem paradoxical at first: the more code AI helps create, the more structured the environment in which it works needs to be.
The model needs context. It should know not only what it is supposed to build, but also:
how the project is organized,
which conventions apply to the code,
which components it should use,
what it should not change,
what the expected result looks like,
what conditions the code needs to meet before the task can be considered complete.
The best results, however, come when the rules that apply to the project are not only documented, but also executable and automatically verifiable. Wherever possible, it is therefore worth codifying them and incorporating them directly into the software development process, including as part of the CI/CD pipeline.
It is also important that these mechanisms can be easily executed from the CLI. This makes the same rules available with a single command to both the developer and the AI agent. The rules then stop being merely declarations that someone has to remember and become part of a process that can actually be enforced and verified.
Without this, two similar tasks may be solved in two different ways. Each solution may work on its own, but over time the project will begin to lose consistency.
This is why responsible AI-assisted development does not start with choosing a model. It starts with preparing an environment in which the model can operate according to clearly defined rules.
One of the significant changes in how we work with AI is the shift from simple prompting to specification-based development.
An instruction such as "Add the ability for a manager to approve an order" may seem precise enough. In reality, it leaves many questions unanswered.
Which orders require approval? Who is the manager? Are there multiple approval levels? What happens after a rejection? Who receives a notification? Can the action be reversed? Where is the decision history stored?
A developer would need answers to these questions. An AI agent does too.
That is why, in a spec-first development approach, we first work through the expected behavior and constraints of the solution with the agent and only then move on to implementation.
This allows AI to work on a much better-defined problem. It does not eliminate the need for thinking. Quite the opposite. It shifts part of the effort from writing code manually to precisely defining what actually needs to be built.
The specification tells the agent what it needs to do. However, it also needs information about how it should work within a particular codebase.
This is where project instructions for agents, such as AGENTS.md or CLAUDE.md, come in. Such a file can provide the agent with information about, among other things, the repository structure, applicable conventions, how to run tests and the rules for making changes.
This may seem like a small detail, but it addresses one of the fundamental problems with AI-generated code: the model should not have to guess the project's rules from scratch every time.
However, care should be taken to prevent such a file from becoming too extensive. Its contents become part of the context passed to the model, so the more space general instructions occupy, the less remains for the actual task, code and information required to complete it.
In the context of AI in e-commerce development, this is particularly important. A platform may be developed over many years, contain numerous modules, integrations and dependencies, while individual technology decisions may result from specific business requirements. The agent needs to operate within these boundaries rather than create its own with every new task.
The third pillar of responsible AI use is human-in-the-loop.
Not every operation should be performed automatically simply because it is technically possible. This is particularly important when the agent not only prepares a code proposal but can also perform an operation that causes an actual change in the system.
In such situations, a clear control point is needed. A human should be able to see what AI intends to do, what data it is working with and what the result of the operation will be before it is approved.
This is an important distinction between automation and autonomy. The goal does not have to be a system that makes every decision independently. It may be far more valuable to build a process in which AI performs a large part of the work while a human retains control over operations that require accountability.
Good use of AI is not about removing humans from the process. It is about reducing the work that humans do not need to perform while leaving them in control where their decisions actually matter.
These three pillars – spec-first development, clear conventions for agents and human-in-the-loop – distinguish adding AI to an existing process from designing a development process with the assumption that AI will be part of it, in other words an AI-native approach. This is exactly the thinking behind Open Mercato – a framework that has them built into its architecture.
These principles can be described at the architecture level, but a much more interesting question is what happens when a team actually tries to work this way.
During the Open Mercato hackathon, Łukasz Chruściel, together with a team he had never worked with before, had around a day and a half to build a working solution. The result was a system supporting the handling of service requests.
AI was not used as an impressive add-on. It had a specific role in the process. The system could analyze the content of a request and help extract information needed for further handling, such as the nature of the problem, its location or priority. A human remained responsible for planning the work that followed.
This shows where AI is particularly valuable: when there is a need to quickly move from unstructured information to data that can be used as the basis for the next stage of a process.
The hackathon itself was also a test of the development approach. The team used AI tools for developers, such as Codex and Claude, while Łukasz came into the project with no prior experience of Open Mercato or TypeScript. Even so, the solution reached a working state within a short time.
The most important lesson matches the thesis of this article. AI largely removed the barriers caused by unfamiliar syntax and tooling, but it did not take the classic engineering problems off the team's plate: solution quality, sound architecture and good design decisions. Those still remained with people.
From a CTO's perspective, the specific AI tools for developers that the team uses, whether Codex, Claude or something else, are not particularly important. The fact that a team uses AI says nothing on its own about the quality of its development process.
What matters much more is whether the use of AI translates into faster delivery of functionality without compromising quality, security or the platform's ability to evolve further.
This distinction is also important when comparing software house proposals and choosing a technology partner. A statement such as "we use AI in development" can mean very different things: from occasionally generating pieces of code to a process in which agents work from prepared specifications, operate according to defined rules, and the generated code goes through review and testing.
A CTO should therefore not ask only, "Do you use AI?" Much more can be learned by asking at which stages of development AI is used, how the results of its work are controlled and how its actual impact on the time and quality of software delivery is measured.
| Question | Why is it worth asking? |
|---|---|
| What tasks do you use AI for? | Helps distinguish specific applications from a general statement such as "we work with AI." |
| How do you prepare a task before it goes to an agent? | Shows whether the team works with specifications and context or relies mainly on prompting. |
| What project rules does the agent receive? | Helps assess whether the generated code is likely to remain consistent with the project's architecture and conventions. |
| Who is responsible for code review of AI-generated code? | Responsibility for the code should remain clearly defined regardless of how it was created. AI-assisted code should not be subject to less rigorous standards than manually written code. A quality and performance audit shows how to verify this. |
| How do you test code created with AI? | Faster code generation should not mean abandoning quality control. |
| Which decisions do you not delegate to AI? | A mature team should be able to identify not only the opportunities but also the boundaries of AI use. |
This is one of the most important questions from the perspective of a company investing in a new platform.
There is no doubt that AI has reduced the cost of generating code and made some projects that were previously too expensive relative to their business value more accessible.
However, producing code itself has never been the only or the most important challenge in e-commerce software development, with or without AI. Equally important are understanding requirements, distilling business rules, making the right architectural decisions, and taking responsibility for delivering and subsequently maintaining the solution.
And this is where we reach a boundary that AI does not currently remove: a model can generate a solution, but it does not take responsibility for its consequences. Responsibility still remains with the human and the team deciding whether a given solution can be safely implemented and developed further.
That is why there is no simple answer to the question of how AI affects development costs.
If a developer completes a particular task faster, this can reduce the number of hours required to deliver it. However, this does not mean that every company using AI will automatically deliver projects at a lower cost. Development costs also depend on the project scope, architecture, integrations, quality of requirements, testing and the pricing model agreed with the software house.
It is therefore worth separating development productivity from project price. AI can improve the former. How it affects the latter depends on how a particular project is organized and billed.
From a CTO's perspective, the more important outcome may not only be lower costs, but also a shorter time-to-market, the ability to deliver more within the same budget or more team capacity for problems that genuinely require experience and architectural thinking.
If an organization wants to determine whether a new development approach will actually deliver value in its specific case, it does not always have to start with a large project.
One option is a limited Proof of Concept, in which the team takes a specific business or technical problem and checks how quickly, and at what level of quality, a working solution can be prepared.
Choosing the right problem is crucial. A good PoC should not focus on something trivial or on functionality that can easily be replicated using standard solutions already available on the market. Such a test tells you little about whether the selected architecture or platform can handle the actual challenges of the project.
A much more valuable approach is to use the PoC to address the most complex, risky or difficult-to-replicate element of the planned solution. In other words, rather than avoiding the hardest problem, it is worth confronting it at the PoC stage.
If the feasibility of this particular element can be confirmed, the PoC answers the most important question: does this technology direction actually make sense for our project?
With this approach, it is worth defining the success criteria in advance. Not only "did we manage to build something?", but also: how long did the implementation take, how much of the work was completed with AI support, how much work was subsequently required for verification, whether the solution meets the quality requirements and whether it can be safely developed further. In Open Mercato projects, this kind of test takes the form of an AI-PoC workshop, during which a working prototype is built with AI support within a few days.
Yes, AI speeds up software development, but only for some tasks – particularly those that are well defined, repetitive or involve working with existing code and documentation.
However, this does not automatically shorten the entire project. The outcome depends on the quality of the requirements, the architecture, how AI is used and the process for verifying the generated code.
It can, if faster code generation is not accompanied by architectural control, testing and code review.
Using AI does not inherently lead to technical debt. The risk appears when a team accepts solutions without sufficient verification or allows agents to create inconsistent patterns across different parts of the project.
Using an AI tool primarily means adding another form of support to a developer's work.
In an AI-native approach, the entire development process and environment are designed with the assumption that agents will be the primary, or even the only, way code is produced. This requires, among other things, appropriate context, specifications, conventions, control mechanisms and clearly defined boundaries of responsibility.
AI can help implement business logic, but it should not decide what that logic should look like.
In complex e-commerce, rules concerning pricing, orders, permissions, integrations or B2B processes result from a specific business model. They first need to be properly understood and designed, and only then should AI be used to support their implementation.
It is worth asking which tasks AI is used for, how context is prepared for agents, who verifies the generated code, what tests it needs to pass and which decisions remain with humans.
A mature partner should be able to explain both the benefits and the limitations of its approach.
Until recently, building a custom CRM, ERP, or operational backend meant months wiring up low-level infrastructure. Open...
Read more →
Increasingly, engineering teams maintaining e-commerce platforms based on Sylius 1.x are reaching a critical point where...
Read more →
If you’ve ever had that gut feeling that your e-commerce system isn’t quite right, you’re probably onto something. Maybe...
Read more →
