Why Coding Isn’t the Hardest Part of Software Development?

Erica K.

1. Introduction – the AI Demo Experience

I recently attended a presentation, one part of which was about the practical use of AI. Among other things, how to write appropriate prompts[1] to get the most accurate results. As a software engineer, I found the presentation interesting, but there was one point that caught my attention as well — but probably not for the same reason as the people sitting around me.

During the presentation, a website was generated in a few minutes. As an engeineer, I know exactly how much complexity can lie behind a website. It doesn’t matter whether we are talking about a simple landing page, a webshop, or a corporate application integrated with multiple systems.

The reaction of those sitting around me, however, made me think. Several people commented with admiration:

“A few clicks and it’s done in 2-3 minutes?”

I wasn’t surprised. Lately, I’ve been hearing this question more and more often:

“If AI can write code, why do we still need programmers?”

But the demo actually generated an HTML page. It showed the most spectacular part. Not necessarily the most difficult.

Back in 1986, Fred Brooks wrote in his essay No Silver Bullet that the hardest problems in software development are not simply technological problems. Tools can improve and speed up, but the real complexity of business problems still remains.

[1] Prompt: an instruction or request based on which AI generates an answer or result.

2. What People Actually See

Over the years, I have learned that there are both visible and completely invisible parts of my work. Most people see a working website or program. If someone asks me what I do, the answer is usually quickly simplified to “I write code.”

However, development is much more than that.

It is often difficult to understand from the outside why a feature takes longer to create. Especially when the client himself is not entirely sure what he exactly needs, or cannot articulate it well.

With the advent of AI, this question has become even more prominent. Yes, AI can now generate usable code. You don’t have to spend hours browsing forums or digging through documentation for a basic solution. In many cases, a well-worded prompt is enough, and in a few seconds you have the finished code snippet.

But code alone is not software engineering.

3. Behind the Scenes

AI wrote the code. Okay. But who checks if it was really written well? Who sees how it will work in six months? What happens if the needs change or bugs appear?

One of the peculiarities of software development is that the most important work often remains invisible. The user sees a working button. They don’t see the decisions, compromises, and bug-prevention solutions that make that button work reliably.

What Are We Building Anyway?

One of the most important parts of software engineering is not programming, but understanding the problem.

AI can be a huge help if we can articulate exactly what we need. But to do this, we first need to understand the problem.

One important idea of Domain-Driven Design (DDD)[2], for example, is that developers and the business side use a common language. However, this does not mean that business processes can be translated directly into code. In between, there is always a need for interpretation, planning and decisions.

AI can help with this. But it will not understand how a business operates.

[2] DDD (Domain-Driven Design): domain-driven design approach.

What Will Happen In Six Months?

Software rarely remains unchanged. A company develops, new needs emerge, demand changes, new processes are introduced.

The question is therefore not only whether a system works today, but also to what extent it can be modified later.

Martin Fowler uses the concept of technical debt to describe when a quick or convenient technical decision causes significant problems later. The true value of a system can therefore often be measured not in the first version, but in its long-term maintainability.

How Does It Fit Into Other Systems?

Modern software rarely works completely independently. It must connect to external services, APIs, internal systems or third-party systems.

And this is where things get really complicated.

An integration may be technically feasible, but:

is there a suitable API for it,
how much does it cost,
how stable is it,
who runs it,
and what happens if the other system changes?

These are no longer simply programming questions. These are engineering and business decisions.

4. The AI Misconception

Today, we hear a lot about how much AI can speed up our work. And it really is.

As a software engineer, for example, I know exactly how much time it can take to create documentation. Writing it clearly, taking screenshots, redacting sensitive information, formatting everything properly, and polishing the final result. Previously, this could have taken days.

Today, some of these tasks can be automated in a few minutes. AI has made a lot of templated or repetitive work faster. This has made work really more efficient. However, many people assume that expertise has become less valuable as well. However, the price of bad decisions has not decreased.

In fact, in some cases it can even be higher.

Developer Simon Willison has repeatedly emphasized that AI is currently more of an extremely powerful assistant than an independent engineer. Interpreting, checking and integrating the generated code into the system still requires human decisions.

Let’s look at a simple example.

A small business is working with an external development company. The management attends an AI presentation, where a spectacular website is created in minutes. They rightly ask:

“If it’s that easy, why are we paying developers?”

The company finally decides to generate the new webshop itself with the help of AI. At first glance, everything seems to work. However, there is one small flaw: the order cannot be finalized from the cart.

There is no developer testing. No review. No monitoring.

And the result will not be a technological problem, but a business loss.

5. Closing thoughts

AI is not bad. In fact: it is an incredibly useful tool.

The future is clearly heading in this direction, and as a developer, I think it would be a mistake to ignore it. AI accelerates, supports, automates, and takes a lot of monotonous tasks off your shoulders. However, it is also important to understand its limits.

The role of traditional coding will likely continue to shrink. But this does not diminish the value of engineering thinking — it actually enhances it.

Good systems design, problem understanding, decision making, communication, striving for simplicity, and long-term thinking still cannot be automated with a few prompts.

AI quickly and cheaply creates the pieces of the puzzle. But someone still has to put the puzzle together.