With AI, anyone can build. Designing is still a craft

An AI can write a function in seconds. Many conclude it can build an entire piece of software.

That confuses two crafts. Writing a line of code and designing a system that still stands in five years are not the same job.

This article is not against AI. We use it ourselves, every day, in house. The question is not whether to do without it. The question is what it actually replaces, and what it does not.

What AI really changed in software development

Generative AI made writing code accessible to almost anyone. Someone with no technical training can now get a script, a page, an automation, simply by describing what they want.

That is a real change, and a useful one. Tasks that took hours take minutes. Ideas that sat on paper become prototypes in an evening.

At Lunnar, this tool is part of the daily routine. It helps build faster once we know what to build, the same way a machine assists a craftsman without deciding for them what to make.

But producing code was never the hard part of a software project. The hard part is knowing which code to write, in what order, with what limits, and why.

AI answers “how to do it” very well. It does not answer “should this be done, and this way”.

The confusion is not new. It already existed with no-code, which made assembling tools accessible without making the thinking behind it accessible. AI simply amplifies the phenomenon, at another scale.

The architect analogy: building is not designing

An architect does not lay a brick. They draw a plan that decides where each brick goes, what the building will have to carry, and how it will age. A tool that generates code does roughly what unlimited access to materials and labor does: it executes fast, it does not think about the structure.

Having every material in the world does not tell you where to lay the foundations. It does not tell you what the building will have to carry in five years either, when you have three times the users, twice the data, and regulation that has changed.

An architect with unlimited materials would move faster. They would not draw fewer plans for it. The opposite, in fact: the faster the construction, the more solid the plan has to be before starting, or you go fast in the wrong direction.

The plan comes before the foundations

Before the first line of code, someone has to decide: how the data is structured, what must stay separate, what must talk to what, what must be protected first.

These decisions do not show right away. They only surface later, when the system grows and every early choice bears on everything built on top of it.

A badly thought out plan is not written in one sentence to an AI. It is drawn by understanding a business, its real friction, and what it will become over the next few years.

What breaks when nobody drew the plans

Three things break, almost always in this order.

Technical debt. Code that works today, but that nobody can change without breaking everything around it, because it was never meant to move.

Security. Holes that stay invisible in normal use, and open the moment somebody looks for them. They are not added afterwards, they are thought through from the structure onward.

Inconsistent data. The same information stored in two places, ending up contradicting itself. A customer with two addresses, an order with two statuses. Nobody knows which one is true anymore.

These three problems almost never show on day one. They show six months or two years later, once fixing them has become expensive.

The faster the tool was built, the sooner they arrive. That is no accident: speed of construction and soundness of the plan do not offset one another.

3 signs a project was coded without being designed

These signals usually show up together, on tools built fast, with no design step first.

Nobody can explain why a feature was built this way. The code works, but the reasoning behind it is lost. Every change becomes a gamble.

Each new request takes longer than the last. The system was not meant to grow, so every addition works around what is already there, a little more painfully each time.

The same bugs come back after being fixed. A sign the problem was never handled at the root, only patched at the surface, because nobody took the time to understand the cause.

None of these three shows up in a demo. They surface in use, often after the tool has taken an important place in the company's day to day. That is what makes them expensive: you find them too late to fix them cheaply.

What a designer actually does

Designing means deciding the structure before writing, with an eye on what the system will carry for years, not only on what it must do tomorrow.

It means understanding a business from the inside before proposing anything. Settling priorities, cutting what is not needed, choosing what must exist now and what can wait. Laying out the data structure, the security, the automations, before anyone writes a line.

This work happens before the quote, not after. A quote built without this step commits to nothing solid: it prices a hunch, not a verified plan.

That is exactly what our method describes: immersion in your business, then a structuring phase, before any construction. AI then helps us build faster, but it comes after that work, never in its place.

What comes out of it is a tool that exists only for you, whose data stays yours without conditions, and that was built to last. We show what we know how to design as examples, not as a catalogue of modules.

One last point deserves to be said plainly: none of this is against AI. Used after the design, once the plan is set, it genuinely speeds up construction. Used instead of the design, it quickly produces something that will age badly.

To see when an off-the-shelf tool reaches its limits and where custom design takes over, our article on the limits of no-code lays out the concrete thresholds. And if the question left is the price, our article on the cost of custom software puts real numbers on it.

If you have a project where this design step was skipped, or if you are starting from scratch, the simplest thing is to talk it through rather than guess on your own.

Frequently asked questions

Can AI replace a developer?

It replaces part of the code writing, not the design. Deciding the structure of a system, anticipating what it will carry in five years, thinking through security and data consistency remain human work, even with AI as a tool.

What exactly is a software architect?

The person who draws the structure of a system before it is written: how the data is organized, what must stay separate, what must be protected, what must be able to change without breaking everything two years from now.

Does Lunnar use AI to build software?

Yes, in house, to speed up construction once the plan is set. It is not what decides the architecture or the priorities: that design work is done by people, before the first line of code is written.

Why does technical debt appear even with AI generated code?

Because technical debt comes from a lack of structure, not from a lack of writing speed. Code produced fast, with no plan behind it, piles up the same way code written by hand in a rush does.