Building a Slab Inventory with AI: Where Quick Success Tips Over

With AI, a stock list or a small slab gallery can be built in an afternoon today. It works as long as one person uses it and nothing unusual happens. In the daily work of a stone business, something unusual happens all the time, for example when two salespeople offer the same slab. That is where the errors in the program begin, and every quick repair can create further errors.

The appeal: hours instead of months

“Vibe coding” is what AI researcher Andrej Karpathy called, in February 2025, what many people are trying today: describing in everyday language what the program should do, and the AI writes the code, which is adopted without being read. After an afternoon there is often a table with material, format and thickness, with photo and filter.

For some tasks that is exactly right: a quick overview for a trade fair presence or an analysis of the contacts collected at a trade fair. As soon as such data is meant to flow into a running project, it gets tricky. Fraunhofer IESE calls rapid prototyping a strength and at the same time warns that the prototype ends up in the final system. “The risks increase with the complexity and criticality of the application.” A slab inventory used for selling is both.

The curve: enthusiasm, daily work, errors

Then daily work arrives, and with it cases nobody thought of while describing the program:

• A slab is not an item. Every slab is a one-off with its own contour and its own veining. A list that records “material, 20 m²” does not know which slab matches which.
• Block sequences. A bookmatch needs the mirror-image, consecutive slabs of a block; a calm blending needs slabs from the same block. If one of them goes out on its own, exactly its neighbour is missing in the surface.
• Offcuts come back. After cutting, an offcut with a new contour remains. New entry, change or deduction? The answer controls stock, price and photo.
• Slabs break, locations change. One slab breaks while being moved, another stands in a different rack. In the system both are still there unchanged, and an offer keeps running.
• Two salespeople, one slab. As soon as more than one person sells, reservations visible to everyone are needed.
• One thing affects the other. A process that works for floor tiles in square metres does not automatically work for skirting in linear metres. What is correct in the offer must also be correct in the order, the delivery note and the label.

A case from practice shows how small the trigger can be. A self-written planning program ran flawlessly in several individual projects. When the data of several projects was merged, it stopped. It numbered parts with letters and ran through the alphabet; what comes after Z had never been defined. The error was fixed quickly, but it had consequences for execution and plan display, all of which had to be updated. That is the typical course: the result comes fast. The cases where it gets stuck only come when the business and its staff really use the program.

Each of these cases can be described to the AI, and it delivers a solution. Here lies the trap: in one or more attempts the repair fixes the visible problem and in the background often changes things that worked before. In vibe coding, as Fraunhofer IESE describes it, “error messages are simply passed straight to the AI as a new prompt”. The institute names the declining understanding of the system as a risk: the generated code is hard to follow.

One reason lies in how the AI works. A person who builds a program over months remembers why something was solved the way it was. The AI works with what is in the current conversation. Over many sessions the chat is switched and not everything is handed over, or the conversation gets so long that earlier parts are no longer reliably taken into account. The research team at Chroma tested 18 language models: in all experiments performance dropped the longer the input became. That is exactly where the repairs arise that break something elsewhere.

With every repair the code grows, and because the understanding of the logic is missing, it becomes more complicated than necessary: duplicated sections, detours, loops within loops. An indication from professional software development comes from the code analysis company GitClear, which evaluated 211 million changed lines of code from 2020 to 2024: the share of copied lines rose from 8.3 to 12.3 %, the share of cleaned-up lines fell from 25 % (2021) to under 10 % (2024). This cleaning up is time-consuming, requires expertise and usually exceeds what someone who “just builds it themselves” is willing to do.

That leaves security. Veracode examined code from over 100 AI models: in 45 % of the tests it contained risky security flaws. What that looks like was shown in 2025 by the AI app builder Lovable: in 170 of 1,645 examined applications built with it, access rights were so incomplete that data such as names, phone numbers and payment details were exposed. For a slab inventory that shows customer prices and customer data online, that weighs heavily.

The trap: the more that goes in, the harder it is to get out

A self-built system usually only becomes expensive after launch, in the weeks when one more error is fixed in the evening and a new one is there in the morning. Those hours are missing in sales and on site measuring. The more time has gone in, the harder it is to say: “We stop and take something ready-made.” Psychology calls this the sunk cost effect: the time already invested holds on to people, even when the next step no longer pays off.

Yet it is hard to notice how much time goes in. In a study by the research group METR, 16 experienced developers worked on real tasks in their own large open-source projects that had grown over years, sometimes with and sometimes without AI tools from early 2025. As measured, they took 19 % longer with AI and afterwards still believed they had been 20 % faster. For newer tools the authors now consider the slowdown smaller, but call their own data on this weak. What remains remarkable is the gap between feeling and measurement. If even professionals misjudge their own pace this badly, how reliable is the self-assessment of someone programming for the first time on the side?

Signs of being in too deep:

1. Every week another repair is added, and the list of open errors does not get shorter.
2. Questions about the program always end up with the same colleague, and when that colleague is on holiday, the business waits.
3. After a change, nobody checks the system in every direction, i.e. offer, delivery note and label. Whether something broke only shows in daily work.
4. Nobody has yet added up the hours that have gone into the in-house program and keep going into it.

If more than one point applies, an honest calculation with three figures is worthwhile: the hours that building it in-house costs every month (two weeks of logging is enough), the monthly price of a professional solution and the time the team saves with it in sales and in the warehouse, ideally measured in a trial with the business’s own stock.

What is still to come: the digital product passport

The new European Construction Products Regulation (EU) 2024/3110 (CPR) has applied since 8 January 2026 and brings the digital product passport (DPP) for construction products. According to the Deutsches Institut für Bautechnik (DIBt), it becomes mandatory once the EU Commission has adopted the respective legal act, after an 18-month transition period. That legal act determines which products and which data it covers. What can be foreseen is that product data will have to be available digitally and in a defined form. A self-built solution then faces a conversion that each business has to manage on its own. A provider serving many businesses has to solve it once for all of them.

What speaks for building it yourself

In fairness, there is another side too. A ready-made solution costs money every month for as long as it runs. One depends on a provider and its planning, and one’s own wishes stand alongside those of other customers. And before signing up, the question of how one’s own data comes back out in case of a switch should be settled. Anyone who weighs these points more heavily and has the time for maintenance can build it themselves for good reason, most sensibly where no customer data is involved.

What goes into a grown solution

A purchased solution is not error-free either. The difference lies in who finds and fixes the errors. On a platform, staff from many businesses work every day. That way the processes are tested in real operation, error reports reach the provider and are fixed, for all customers at the same time. The provider lives from this, so it has every reason to be quick. Many teething problems that an in-house program still has ahead of it have already been cured there.

A platform takes in the knowledge of many businesses. Building for many stone businesses means looking closely at the processes and asking how they can be accelerated in principle. For a single business it makes little sense to repeat that work alone. What matters is that the solution can be configured flexibly, so that a small business also finds its own processes in it. In DDL, in use at stone businesses since 2020, every slab is recorded as a one-off with photo, dimensions and block, offcuts go back into stock as new slabs, and anyone offering a reserved slab gets a warning.