DEV Community: ArmelDev

GitLab: two critical flaws in ten days, from discovery to patch

ArmelDev — Wed, 21 Oct 2026 21:00:04 +0000

On October 21, 2026, GitLab released emergency versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. They fix CVE-2026-110264, a critical flaw rated 10.0, the maximum score, which can allow an unauthenticated attacker to execute code on a GitLab server. It is the second flaw of this kind in ten days. Here is what happened, and what to do.

The problem comes from the regular expression engine

Both flaws share the same nature: an integer overflow when compiling a specially crafted regular expression. The component at fault is Onigmo, Ruby's regular expression engine, which GitLab ships in its packages.

CVE-2026-97229 (October 12): the malicious expression goes through the CI/CD configuration, in a .gitlab-ci.yml file. It affects versions 19.2 and later.
CVE-2026-110264 (October 21): a flaw of the same nature, but affecting every version since GitLab 7.0 , released in 2014. According to the detection rules published by GitLab, it can be triggered by a simple Org-mode ( .org ) file, whose rendering passes an expression to the engine.

In both cases, the code runs as GitLab's git system account, which has access to repositories, CI/CD secrets and the instance configuration.

Every self-managed instance is affected

GitLab.com is already patched and GitLab Dedicated customers have nothing to do. Self-managed instances, Community and Enterprise alike, must be updated.

Branch	Fixed version
19.5	19.5.1
19.4	19.4.3
19.3	19.3.6
19.2	19.2.9
19.1	19.1.9
19.0	19.0.10
7.0 to 18.11	18.11.13

Important: the versions released on October 12 (19.4.2, 19.3.5 and 19.2.8) fix the first flaw, but not the second. An instance updated on that date is vulnerable again.

The fixes for 19.2, 19.1, 19.0 and 18.11 are exceptional backports, outside GitLab's usual policy. That alone shows how serious the problem is.

Two other serious flaws in the same update

The October 21 release fixes eleven flaws in total. Two of them, rated high, deserve special attention:

CVE-2026-15723 (CVSS 8.2): an authentication flaw that can allow account takeover when SAML authentication and automatic LDAP linking are enabled. Organizations connecting GitLab to their corporate directory are directly concerned.
CVE-2026-112212 (CVSS 7.5): a cache poisoning issue in OAuth/OIDC discovery, the mechanism used to sign in through an external identity provider.

These flaws are fixed by the same versions: a single update takes care of everything.

From discovery to patch: a tense month

Date	Event
2014	GitLab 7.0 is released. According to the October 21 advisory, every version since then is affected by CVE-2026-110264.
September 23, 2026	GitLab fixes two other critical flaws (CVE-2026-93577 and CVE-2026-89078, CVSS 9.9), exploitable with an authenticated account. According to The Hacker News, researcher joaxcar reported four code execution flaws in GitLab's regular expression engine within a month.
October 12, 2026	CVE-2026-97229 (CVSS 10.0) is fixed in versions 19.4.2, 19.3.5 and 19.2.8.
October 13, 2026	Rapid7 reproduces code execution on the official GitLab CE 19.4.1 image.
October 16, 2026	Researcher Jonah Burgess publishes a proof-of-concept exploit for CVE-2026-97229. Being able to push a branch to a public project on the instance is enough.
October 20, 2026	GitLab publishes two detection rules: "Onigmo native worker crash" and "Org mode render error burst".
October 21, 2026	CVE-2026-110264 (CVSS 10.0) is fixed. It was reported by joaxcar through the HackerOne bug bounty program, and the fix is backported down to the 18.11 branch. The same update fixes ten other flaws, including CVE-2026-15723 (8.2) and CVE-2026-112212 (7.5).
October 21, after the release	GitLab reports no exploitation in the wild. CISA has not added the flaw to its catalog of exploited vulnerabilities.

A public exploit already exists for the first flaw, and both share the same root cause. Assume that exposed instances will be targeted.

Patching: updating is the only real protection

GitLab offers no workaround for CVE-2026-110264. Example for an Omnibus installation on Debian/Ubuntu (replace gitlab-ee with gitlab-ce depending on your edition):

1. Check the installed version

sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"

2. Back up before doing anything

sudo gitlab-backup create
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/

The backup does not include gitlab.rb or gitlab-secrets.json: copy them separately.

3. Update

sudo apt-get update
sudo apt-get install gitlab-ee

If your instance is several versions behind, follow GitLab's official upgrade path rather than jumping straight to the latest version.

4. For Docker, change the image

docker pull gitlab/gitlab-ee:19.5.1-ee.0
docker compose up -d

Adjust the tag to your branch and edition.

5. Check that the fix is active

sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"
sudo gitlab-ctl status

Plan ahead: on a single-node server, versions 19.4.3 and 19.3.6 include database migrations that make GitLab unavailable during the operation. Multi-node installations can follow the zero-downtime upgrade procedure.

Security advice to follow

Before updating

Take inventory of every GitLab instance, including test or forgotten servers.
Handle internet-facing instances first , especially those with public projects.
Take a snapshot or full backup so you can roll back.

While waiting for the fix

Disable open sign-up for new users.
Restrict anonymous access to public projects and prevent untrusted users from creating or editing projects.
If possible, limit access to the instance to a VPN or known IP addresses.
If your instance uses SAML with automatic LDAP linking, review recent sign-ins and newly linked accounts, in light of CVE-2026-15723.

These measures reduce the attack surface, but do not fix the flaws.

After updating

Monitor logs : repeated worker crashes or bursts of errors when rendering .org files are red flags. The two detection rules published by GitLab target exactly these cases.
Look for signs of compromise on instances exposed before the fix: unusual processes started by the git account, recent files in GitLab directories, recently created accounts or access tokens, abnormal outbound connections.
If in doubt, rotate secrets : CI/CD variables, personal and project access tokens, deploy keys, runner registration tokens.

A shared component, a shared risk

As with PHP2Shell the same week, the defect does not come from business code, but from a core component everyone uses without thinking about it: here, Ruby's regular expression engine. A flaw in such a deep building block can stay hidden for years, then hit every version of a product at once.

What now?

If you updated GitLab on October 12, do it again today. And ask yourself one question: do you know exactly how many GitLab instances run in your organization?

Sources: GitLab – October 21 advisory · The Hacker News · Rapid7 · Help Net Security · Cyber Security News · HOL

PHP2Shell: two critical PHP vulnerabilities, from discovery to patch

ArmelDev — Wed, 21 Oct 2026 16:45:05 +0000

On October 21, 2026, the PHP team released emergency updates: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These versions fix two critical vulnerabilities, nicknamed PHP2Shell, that allow remote code execution without authentication. Here is what happened, and what to do.

The flaw is in PHP, not in your code

CVE-2026-109618 : if a request hits the memory_limit at the wrong moment, PHP can leave internal data half-initialized, then treat it as valid. The result: memory corruption.
CVE-2026-109619 : a badly timed fatal error can leave internal state pointing to memory from a previous request. A later request handled by the same worker can then reuse that already-freed memory.

Both are rated 9.2 on CVSS v4.0. On Apache with mod_php, a single request can trigger the attack before the application even runs. Code execution was also confirmed on PHP-FPM through some application code paths.

Because the defect lives in the interpreter, it affects everything running on it: WordPress, Laravel, Drupal, Magento, Joomla and in-house applications. No line of application code can protect against it.

Every version is affected, and some will never be fixed

The problem goes back at least to PHP 5.4. Every installation serving web requests is exposed: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.

Branch	Fixed version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 and earlier	No official fix (end of life)

From discovery to patch: a two-year story

Date	Event
2024	PHP's first external security audit in years, carried out by Quarkslab and funded by the Sovereign Tech Agency through OSTIF. While fixing one of the reported issues, a PHP core developer spots the first signs of the memory-handling defect. An exploit is considered in theory, but no concrete vector is found.
2024 – 2026	Several fixes are explored, but each comes at a cost: compatibility breaks, denial-of-service risk, or changes forced on third-party extensions. Work stops and restarts for months. The PHP Foundation itself acknowledges a structural failure, tied to its decision process and lack of resources.
Early 2026	PHP's code is scanned with AI tools, as part of a partnership with Alpha-Omega.
May 2026	The PHP Foundation creates a team dedicated to ecosystem security.
July 30, 2026	Security firm Calif starts an audit of PHP.
August 11, 2026	Calif reports an unconditional remote code execution with the same root cause as the defect spotted in 2024. OpenAI reports the same root cause the same day. Fixing it becomes the top priority.
August 24 and September 18, 2026	Wiz, then OpenAI, report additional attack vectors.
October 20, around 15:00 UTC	The CVE IDs leak on forums and social media, with a wrong release time and an incorrect score of 10.0. No technical details leak.
October 20, 19:30 UTC	PHP publishes a pre-announcement and moves the release from October 22 to October 21.
October 20, around 20:00 UTC	Calif mistakenly publishes a demo video. Deleted, it gets copied and speeds up exploit development.
October 21, 07:41 UTC	Chainguard breaks the embargo by publishing patched images, making it possible to study the fix before its official release.
October 21, 14:00 UTC	Official release of the fixed versions.
October 21, after the release	watchTowr, Patchstack and Aikido (citing Cloudflare) report exploitation attempts. PHP has not confirmed exploitation, and CISA has not added the CVEs to its catalog of exploited vulnerabilities.

Exploit tools are circulating. Assume that exposed servers will be scanned.

Patching: updating is the only real protection

Several workarounds have circulated, such as disabling session.upload_progress. According to watchTowr, changes to .ini files are not enough to prevent exploitation.

Example on Debian/Ubuntu with Ondřej Surý's packages (replace 8.4 with your version):

1. List installed versions and check the active one

ls /etc/php
php8.4 -v

2. Check that the fixed package is available

sudo apt-get update
apt-cache policy php8.4-fpm

The Candidate line should show the fixed version. If not, the repository is not updated yet: wait and try again.

3. Upgrade every package for that version, keeping your configuration

sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

Repeat for every installed version, even those no site uses.

4. Restart long-running PHP processes

PHP-FPM restarts with the update, but command-line workers do not. For a Laravel application:

php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload

5. Check that the fix is active

php8.4 -v
php-fpm8.4 -v

Ubuntu's automatic security updates do not cover third-party PHP repositories: the update has to be run manually.

Security advice to follow

Before updating

Take inventory of every server, container and VM running PHP, including forgotten internal tools.
Handle internet-facing servers first , then internal ones.
Take a snapshot or backup so you can roll back if something goes wrong.

Depending on your environment

Docker : rebuild images from a patched base image, then redeploy containers. Updating a running container is not enough.
Shared hosting : check the PHP version in the control panel and contact your host if the fix has not been applied yet.
PHP 8.1 or older : migrate to a supported branch, or check that your distribution has backported the fix into its package.

While waiting for the fix

Enable, if possible, web application firewall (WAF) rules. Cloudflare, for example, added emergency rules. This is a temporary layer of protection, not a replacement for the update.
Disable expose_php so the PHP version does not appear in HTTP headers. This makes it harder for attackers to spot you, without fixing the flaw.

After updating

Monitor logs and processes: a PHP process spawning a shell or system commands is a red flag.
Look for signs of compromise on servers exposed before the fix: recent or unknown PHP files (webshells), new scheduled tasks, unusual outbound connections.
If in serious doubt, rebuild the server from a clean backup and rotate secrets (passwords, API keys, .env file).

AI has changed the scale of the problem

The defect had been spotted as early as 2024 without a concrete exploitation path. Recent audits, backed by AI tools, revealed its real impact. According to Wiz, frontier AI models sharply reduced the effort needed to turn this old flaw into an exploit. The PHP Foundation also notes a sharp rise in reports, and points out that the language's security still relies on a handful of funded developers.

What now?

Update your internet-facing servers first, then the rest. And ask yourself one simple question: how many of your servers still run a PHP version that will never receive another fix?

Sources: PHP Foundation · Laravel Forge · php-net.pro · watchTowr · Patchstack · Help Net Security · SOCRadar

With AI, staying in control of your architecture

ArmelDev — Tue, 20 Oct 2026 10:00:04 +0000

I don't let AI decide how my projects are structured. I define it, and the AI follows. Well, most of the time.

Sometimes it steps outside the frame: ignoring a principle, working around a design pattern, adding a layer nobody asked for. It's quickly fixed. But only because I know exactly what I expected.

And that, to me, is where real control lies.

Architecture is decided before the first prompt

Before I open an assistant, I already know how the project is organized: where the business logic lives, how the layers communicate, which patterns I use and why.

AI doesn't have that big picture. It answers what you show it: a file, a function, a question. If you don't give it the frame, it invents one. And that improvised frame changes from one answer to the next.

Architecture can't be delegated. It has to be passed on.

AI follows… until it improvises

Even with clear instructions, AI sometimes drifts. It puts business logic in a controller instead of a service. It creates a useless abstraction. It adds a dependency for something three lines would have covered.

Taken one by one, each of these deviations looks harmless. The code works. But as they pile up, they turn a coherent project into a patchwork that is hard to maintain.

You can only fix quickly what you have clearly defined

Spotting a deviation requires a reference. If I know a given process must go through a service, I see immediately when the AI strays from it. Without that marker, the same code would look perfectly acceptable.

That's why the rules must exist before generation: written conventions, a deliberate folder structure, named principles. The more explicit the frame, the faster the correction.

How fast you correct depends on how clear your frame is.

You are still the architect

AI speeds up writing code. It doesn't carry responsibility for its coherence.

Reviewing, turning down a suggestion, simplifying what got overcomplicated, documenting decisions so they outlive the project: that's the work that keeps a codebase healthy over time.

AI is an excellent builder. But the blueprint of the house stays in our hands.

So, are you the one guiding the AI, or is it slowly drawing your architecture for you?

A good application doesn't start with code

ArmelDev — Wed, 14 Oct 2026 08:06:42 +0000

Introduction

When you're a developer, it's natural to start a project with the technology.

Which stack? Which architecture? Which database? Which API?

These are important questions. But they often come too early.

Before thinking about code, you need to understand what you're trying to build, for whom, and why.

An application can be technically excellent yet solve the wrong problem.

Conversely, a simple solution can have enormous value when it precisely meets a real need.

A good application starts with a problem to understand, not with code to write.

01 — Start with the problem

Before drawing a screen or creating a database, one question must be clear:

What problem are we trying to solve?

A user generally doesn't think in features.

They don't say:

« I need a dynamic form with conditional logic. »

They say instead:

« My sink is clogged. I need to find someone to help me. »

This difference is fundamental.

The product must understand the user's need, rather than asking them to understand how the product works.

02 — Complexity must belong to the system

It's a principle I place a lot of importance on:

Complexity must belong to the system, not to the user.

Let's take a simple example: a person wants to have their phone repaired.

The system may need to know the brand, model, screen condition, battery, or whether the device powers on.

But that doesn't mean you should immediately present ten fields to fill out.

The user can simply write:

« My Samsung fell and the screen no longer turns on. »

The system must then transform this description into useful information.

The user expresses their problem. The system gradually structures the information.

03 — Design the journey before the screens

Another mistake is to start directly with the interface.

We design a welcome screen, a form, a results page, a profile…

But several coherent screens do not guarantee a coherent journey.

I prefer to start with another question:

What should happen between the moment the user expresses their need and the moment their problem is actually solved?

We can then represent the journey simply:

Need → understanding → qualification → matchmaking → choice → intervention → confirmation

Each step must have a reason to exist.

Each requested piece of information must also have a purpose.

04 — The MVP is not an incomplete application

An MVP is not simply a large application from which features are removed.

It's rather:

the smallest version capable of validating an important hypothesis.

This sometimes means accepting not to build everything.

Integrated payment? Later.

Advanced automation? Later.

Complex dashboard? Later.

The initial goal is to build what allows us to verify that the product truly delivers value.

05 — Technology comes next

Once the problem, journey, and scope are defined, technical choices become much simpler.

We can then think about:

the architecture;
the data;
the business rules;
the automations;
artificial intelligence;
scalability.

Technology then becomes what it should be:

a means to build the product correctly, not the product itself.

It is easy to fall in love with a technology.

It is much more important to stay focused on the user's problem.

06 — AI does not replace design

Artificial intelligence today allows rapid generation of code, interfaces, or even architectures.

But producing something quickly does not mean producing the right thing.

An AI can perfectly solve a poorly defined problem.

That is why I consider AI a powerful tool for design and execution, but not a replacement for product thinking.

First, you must know what to build.

Only then can AI help determine how to build it more efficiently.

07 — Designing also means managing uncertainty

In the real world, not all information is always available.

The user may not know the answer.

A situation can evolve.

A professional may need to confirm certain information.

A good system must be able to function despite this uncertainty.

It should not necessarily block the user simply because information is missing.

A well-designed product knows how to move forward even when all information is not yet known.

08 — Code remains essential

All of this obviously does not mean that development is secondary.

Good design without good execution remains a good idea.

Development turns journeys, rules, and product decisions into a real, reliable, and scalable system.

But code must serve a clear intention.

A few hours of design can sometimes prevent several days of unnecessary development.

09 — Building an application is building a system

An application is not just an interface.

Behind every screen there are:

users;
data;
rules;
decisions;
states;

A simple application for the user can be complex behind

ArmelDev — Wed, 14 Oct 2026 08:06:30 +0000

Introduction — Visible simplicity often hides great complexity

When an application is well designed, its use often seems obvious.

The user clicks, provides some information and gets a result. They don’t need to understand what happens behind the scenes.

Yet, this apparent simplicity can hide a large amount of logic, rules, and technical decisions.

User-side simplicity is often the result of well‑managed system-side complexity.

1. What the user sees

The user generally sees only a small part of the application.

They see an interface, some buttons, forms, and results. They simply expect to be able to accomplish their goal without having to think about the system’s internal workings.

For example, to find a professional, they can simply describe their problem and submit a request.

For them, the action is simple.

And that is precisely what the user experience should aim to produce: a natural interaction, without unnecessary complexity.

2. What the system must handle

Behind this simple interaction, the system may have a lot of work to do.

It must understand the provided information, determine what is relevant, apply business rules, verify available data, take constraints into account, and produce a coherent response.

In some cases, it must also handle errors, missing information, various request states, or exceptional situations.

The user does not need to know any of this.

But the system, on the other hand, must be capable of handling it.

3. Why shifting complexity to the user is a bad approach

A solution sometimes consists of directly asking the user for all the information the system needs.

This may seem simpler to develop.

But it often results in endless forms, incomprehensible technical choices, and additional steps.

The problem is then shifted to the user.

A user should not have to understand a product’s internal logic to be able to use it.

If the system is complex, it is not the user who should pay the price.

4. Designing complexity to make it invisible

The real challenge is therefore to design this complexity so that it remains mainly behind the interface.

This requires thinking about journeys, business rules, different scenarios, and the information truly needed at each step.

Instead of asking for everything immediately, the system can gradually determine what it needs.

Instead of exposing all possibilities, it can present only those relevant in the context.

Thus, the developer’s job is not only to make a feature work.

It also involves organizing complexity so that the user does not have to endure it.

5. A good product does not eliminate complexity: it handles it

Complexity is part of many digital products. It is rarely possible to eliminate it completely.

The goal is rather to know where it should be placed.

It can be in business rules, architecture, processing, validations, or internal mechanisms.

But it shouldn't unnecessarily appear in every interaction with the user.

A truly simple application is therefore not necessarily a technically simple application.

It is often an application in which the complexity has been thought through enough to become invisible.

And ultimately, it may be one of the developer's essential roles:

transform the system's complexity into simplicity for the user.

When Should You Stop Adding Features?

ArmelDev — Wed, 14 Oct 2026 08:05:49 +0000

Introduction — The temptation to keep adding more

When designing an application, ideas never seem to run out. A new option, an additional dashboard, an automation, an integration… Every idea seems capable of improving the product.

So we add one feature. Then another. And another, until the application becomes harder to understand, use, and maintain.

Yet one question deserves to be asked before every new addition: does this feature genuinely bring value to the user?

1. The trap of a product that tries to do everything

An application can gradually drift away from its original purpose. By trying to meet every possible need, it accumulates options, screens, and rules.

User journeys become longer. Choices multiply. Some features are rarely used, yet they continue to weigh down both the interface and the codebase.

The problem is not having lots of features. It is losing sight of which ones truly matter.

2. A feature does not automatically add value

An interesting idea is not automatically a priority. Before developing it, we need to understand what problem it solves, for whom, and in what situation.

A feature can be technically impressive without being essential to everyday use. Conversely, a small improvement that removes an unnecessary step can transform the user experience.

A product’s value is therefore not measured by the number of options it offers, but by its ability to help users achieve their goals.

3. Prioritizing means making choices

Prioritizing is not simply about ranking a long list of requests. It means deciding what deserves to be built now, what can wait, and what perhaps should never be developed.

For each idea, a few questions can help:

What real need does this feature address?
How often does this need arise?
How does it contribute to the product’s main goal?
What costs will it add in design, development, testing, and maintenance?
Is there a simpler way to achieve the same result?

These questions do not always lead to an immediate answer. However, they force us to justify our choices instead of turning every suggestion into a development task.

4. The MVP brings us back to what matters

A minimum viable product (MVP) is neither a rushed version nor an application designed to frustrate users. It is a focused version that helps determine whether a solution addresses an important need.

Its scope should be small enough to make progress and learn, yet coherent enough to deliver real value.

Adding too many secondary features too early can delay the reality check: do users actually have this problem? Does the solution help them?

Sometimes, it is better to launch a simple user journey, observe how people use it, and improve it based on concrete feedback than to spend months building every possibility we can imagine.

5. Saying no without closing the door to future improvements

Rejecting a feature today does not mean it will never be useful. It simply means it may not be the right decision at this stage of the product.

An idea can be saved for later, tested in the future, or replaced with a simpler approach. Needs evolve, and the product should evolve with them without losing sight of its purpose.

The role of product design is not to anticipate every possibility from the outset. It is also to create a clear enough foundation for future decisions to be made at the right time.

Conclusion — Do less, but do it better

Adding a feature is often visible. Deciding not to add one can require even more thought.

A good product is not one that responds to every request. It is one that understands its priorities and helps users accomplish what matters effectively.

Before asking “What can we add?”, let’s get into the habit of asking: “What problem are we still trying to solve, and is this really the best way to solve it?”

Product quality is built as much through the choices we make as through the features we decide to leave out.

In the Age of AI, Being a Developer Means Knowing What to Build

ArmelDev — Wed, 14 Oct 2026 08:03:03 +0000

Introduction — Code is no longer the only challenge

With artificial intelligence, it is becoming easier to generate code, explore a language we know little about, or get help using a new framework. In just a few exchanges, we can get an initial implementation in a wide range of technologies.

So, if AI can help us code in almost any language, what still makes a developer valuable?

In my view, one question is becoming more important than the choice of technology: have we truly understood the need we are meant to address?

1. Knowing how to code is not enough to build the right product

We can generate working code, create a compelling interface, and connect a database without actually solving the client’s real problem.

A request may be framed as a list of features, while the real need lies elsewhere: saving time, reducing errors, simplifying a process, or gaining a better understanding of the business.

If we move straight from the request to implementation, we risk building exactly what was asked for, but not necessarily what is useful.

2. AI makes code more accessible, not decisions simpler

Programming assistants can explain a language, suggest an architecture, generate tests, or help fix an error. They speed up certain tasks and open up possibilities to more developers.

But producing an answer quickly does not guarantee that it fits the context. The suggested code may overlook a business rule, mishandle an edge case, introduce a vulnerability, or become difficult to maintain.

We therefore need to know how to read, question, test, and validate what we produce. AI can take part in the work; it does not remove the need to understand the result or take responsibility for its quality.

3. The real question comes before the technical choice

When facing a new project, we often instinctively start discussing the language, framework, database, or architecture. These decisions matter, but they should come after a first step: understanding the problem.

Who faces this difficulty? In what situation? How is it handled today? What really needs to change? What constraints must we respect? And how will we know the solution works?

The answers to these questions shape the product’s scope, its priority features, the user experience, and then the technical choices.

The question is no longer just “Which technology will we use?” but “Do we understand the need well enough to choose the right solution?”

4. Skill also means making the right trade-offs

As code production accelerates, our role does not disappear: it shifts further toward understanding, design, and decision-making. We need to distinguish what matters from what is unnecessary, choose an approach suited to the constraints, and anticipate the consequences of our decisions.

The best solution is not always the most complex one, nor the one using the latest technology. It is the one that meets the need in a way that is reliable, understandable, and adaptable enough.

A developer should not only ask whether they can build a feature. They should also ask whether it is necessary, whether it solves the right problem, and whether its cost is justified.

Conclusion — Understand before producing

Artificial intelligence is changing our tools and the way we work. It can help us write code in a variety of languages and explore solutions more quickly. But it does not make understanding the need any less important. On the contrary, it makes that understanding even more decisive.

Because it is possible to produce code faster than ever and be just as quick to get wrong what needed to be built.

So before choosing a technology or asking AI to generate a feature, let’s take the time to ask the essential question: have we properly understood the problem we are trying to solve?

A developer’s value is not limited to the code they write. It is also measured by the relevance of the questions they ask, the decisions they make, and the quality of the solution they help build.