AI lets anyone build software. Why do professionals still matter?

A few years ago, building working software still meant, in practice, hiring a software developer. Now AI can produce a user interface, a database and an API in a few minutes. A first version of an application can appear in a single evening.

This is a huge change. Relatively inexperienced people can now build websites, applications and automations that look like they work. The number of providers is growing, because the technical part looks easy. A quote arrives quickly, a demo arrives quickly, and it can seem as if the software is already finished.

At the same time one question has become more important. If anyone can build software, how do you recognise a professional?

The barrier has come down, and that is a good thing

There is no reason to mourn this. Software development is being democratised. Many problems can now be solved faster and more cheaply than before. A company can try a small tool without a year-long project. An internal specialist can build an automation that previously never happened, because it was “too small to be a software project”.

We use AI every day as well. It speeds up work that used to be done by hand. This article is therefore not a warning against AI. It is a note about what the ability to generate code still does not tell you.

Software that looks like it works and software that holds up in production are different things. The difference does not show in the first demo. It shows in who understands the problem, what happens when things do not go right, and who is accountable for the system a year later.

The problem has to be understood first

The greatest value rarely comes from how quickly the code is written. What matters more is understanding which problem is actually being solved.

A professional starts by asking whose everyday work will become easier, what information is needed, and what can stay as it is. They do not start from the screen. They start from the work: who records, who approves, where information breaks, and what happens if an entry is never made.

They can also say when new software should not be built at all. The answer may be a ready-made product, an integration between two systems you already have, a small automation, or a tightly scoped tool of your own. Sometimes the most sensible answer is to tidy the current way of working before anything new is built.

When producing code is cheap, the temptation is to build. That is how you get systems nobody asked for, which then stay in place because they “already work”. A good practitioner puts the brakes on here. They separate what is possible from what actually makes sense for the customer.

The value of a professional is not that they write everything themselves. It is that they know what should not be written.

Someone has to understand what the code does

AI can write a large amount of working code, quickly. That still does not mean the solution is good. Generated code can rest on poor assumptions. It can leave security thin, make the structure unnecessarily complex, handle errors poorly, or make the database slow.

The code can look finished and still fail when two events happen at the same time. Or when a user does something the demo never tested. Or when an interface returns data in a different shape from yesterday.

A decision-maker does not need the technical names for these cases. What matters is this: if nobody understands what the system does, nobody can fix it either. A professional has to be able to read, assess and, when needed, challenge the code AI produces. Otherwise the company is buying speed, but not understanding.

The interface is not the whole system

A web application is not only the view the user sees. Behind it sit databases, APIs, authentication, access rights, networks, servers, backups, logging, integrations and deployment. If these layers are treated as an afterthought, the software can look finished and still be fragile.

In industry, machines and lines enter the picture as well. Software may connect to a PLC, a robot, a production network or a physical process. The connection may run through OPC UA or a fieldbus. Then a fault does not stay on the screen. It can stop the work, record the wrong quantity, or leave maintenance undone.

The more critical the system, the more important it is to understand these layers. AI helps write parts. It does not replace an understanding of how the parts fit together, and what happens when one of them fails.

In an SME this often shows up as practical questions. Who can see which information? Where does the data live? What happens if the connection from the plant to the office drops? Who notices if a fault appears on the night shift? A modern-looking interface does not answer those questions.

A demo works when everything goes right

A demo looks good when the network works, the user does the expected thing and the data is tidy. In production, connections drop. Users do unexpected things. An API returns an error. The database is briefly unreachable. Integration data arrives in the wrong shape. A physical device behaves differently from what was assumed.

In a professional implementation these situations are thought through in advance. What does the user see when the connection drops? Who is told about the error? Can the work continue, or does it have to stop? Does the system recover on its own, or is a person needed?

This difference does not show in a sales demo. It shows on the first Monday morning, when the hall is running and someone is waiting for the screen to tell the truth. Then it does not help that the code appeared quickly the night before. What helps is that someone thought about the exception before it happened.

A demo proves that something is possible. Production reveals whether it will last.

The cost of software does not end at launch

The real cost of software is not the first version. The code has to be changeable, updatable, monitored and repairable later. Needs change. Equipment changes. People change. Security still has to be looked after after go-live.

What matters more to the customer than the technology used is that the solution stays operational, and that someone understands the whole. If the builder has disappeared and the code was produced without a structure, the next change is expensive. You are no longer buying a feature. You are buying an investigation into what the system actually does.

Responsibility is not a side issue. Someone is accountable for access rights, backups, logging and for the system being transferable. If that responsibility has not been named, it lands on the customer, often unnoticed.

For a professional, AI is leverage

This is not an argument for leaving AI unused. On the contrary. AI makes a good developer substantially more effective.

An experienced practitioner no longer has to spend time writing everything by hand. They can spend more time on structure, on understanding the problem, on testing, and on the value that actually reaches the customer. The routine shortens. The judgement does not.

This also changes the size of the team. A small firm can now deliver solutions that previously needed a clearly larger software team. The condition is the same as before: someone understands the whole, can keep the work in scope and can take responsibility for production.

For an SME this can be an advantage. You do not need to buy a large software house for every need. You do still need to buy competence, not just fast code production. The difference shows in whether the first conversation is about the work, or immediately about the build.

What this means in Kare Digital’s work

Kare Digital uses AI actively in software development. It is not a separate product, and it is not a sales line. It is a way of working faster once the direction is already clear.

The idea is to combine modern AI-assisted development tools with practical software, automation and industrial expertise. The aim is not to build software for the sake of software. The aim is to find the simplest working solution to the customer’s problem.

Sometimes that is a small automation. Sometimes a ready-made product. Sometimes a company-specific tool that connects to existing systems and, where needed, to production equipment. AI speeds up the delivery. Professional judgement decides what is worth delivering.

If the barrier to building is now low, the barrier to building the wrong thing is low as well. So the question is no longer whether someone can make software. The question is whether someone can stand behind it when things do not go right.