Very humble programmers

LLMs have made a leap in the last one to two years.

From not being able to count the occurrences of the letter “r” in the word “strawberry” without making mistakes, and being fooled by short text lines, they evolved via achieving a gold medal in the mathematics olympiads to autonomously writing a C compiler.

The 2026 AI Index Report by the Stanford Human-Centered AI Lab puts it this way:

On a key coding benchmark—SWE-bench Verified—performance rose from 60% to near 100% in a single year.

And of course there was the Hugging Face incident, where a fleet of 1,200 AI agents went “rogue”.

Some people — especially AI lab CEOs — are discussing a development stop for large language models.

Parodies hint at an engineer’s standpoint on that discussion: a recent sketch.

Looking at the Hugging Face incident more closely grounds that point of view.

First, OpenAI removed all guardrails from the models that “hacked” Hugging Face.

This was done as those models were evaluated on their “hacking skills” based on a test called ExploitGym.

So the models more or less did what they were actually told to, with permission to use all means available.

When looking at some other facts around those companies, it looks a bit more like a PR & marketing move.

The CTO of Hugging Face — Greg Brockman — is an angel investor in Hugging Face. He is directly interested in increasing both OpenAI’s valuation, as well as getting Hugging Face visibility, and has a wide network in both companies.

Nvidia, the most valuable company in the world, bought Hugging Face and decided to invest up to 100 billion US-$ in OpenAI.

The dependencies that Nvidia and OpenAI build are quite interesting in general, whether between each other, with Oracle or with Hugging Face.

It is not easy to tell hype and noise from capability and value in the current landscape.

But there is data on the actual usefulness of LLMs coming from the software engineering industry.

Adoption in the everyday work of software engineers has happened: more than 90% of developers use AI as part of their work, and more than 80% believe it has increased their productivity (Google DORA study).

Industry surveys do find a productivity increase of between 10–40% in terms of committed code.

For greenfield projects, i.e. projects that are started from scratch, boosts of between 35–40% are reported. On legacy or brownfield codebases, however, the productivity gains are smaller, or around 10% (Google DORA study).

Still, 96% of engineers would not trust the outputs of LLMs blindly, and 30% do not trust them at all (Sonar source developer survey).

AI produces code that looks correct but is not reliable, according to 61% of developers — however, only 48% always check the code that AI generated (Sonar).

This fact shifts the bottleneck of software engineering from writing code to verifying code.

One survey found an increase of review workload by 440%.

The super intelligence point of view often leaves all parts of the work to the models.

We have seen the numbers on how successful such an adoption is.

IBM published a survey where they interviewed NATO and Five Eyes leaders on AI. The results show that most AI projects are stuck at the prototype phase because the processes and systems around them are not prepared.

MIT finds a failure rate of 95% of generative AI pilots at companies, due to misallocation to marketing and sales as target applications, instead of the more promising back office automation tasks, where AI eliminates business process outsourcing and streamlines operations.

At the same time the regulatory burden grows in the opposite direction: the EU AI Act effective from June 2026, the EU Cyber Resilience Act enforced from December 11th 2027, the EU machinery directive affecting, for example, robotics from January 20th 2027, and the Monetary Authority of Singapore’s supervisory expectations on responsible AI adoption by financial institutions.

All these regulations put the responsibility on the directors, both for responsible AI use and for cyber security incidents.

From that perspective, what is sold as super intelligence now looks a lot more like a tool.

This is also the stance of Linus Torvalds, the father of the Linux kernel — the operating system that powers the internet, clouds, super-computing and many development environments. Your servers most likely run in some way on Linux as well.

Here is what Linus has to say about AI:

“I see that as a tool that can help us be better at what we do”, Linus Torvalds

Looking at AI as a tool simplifies the handling of it significantly, in my opinion.

First: before you give someone a hammer, you make sure that they know how to use it properly.

For the hammer, the head of the hammer is supposed to hit the head of the nail. Start carefully, such that the nail sticks inside the wood properly, before applying more force.

Second: you make sure to enforce some safety standards, i.e. put rules in place.

You use a hammer to put nails into wood. You do not use a hammer to put in screws, and you also do not use a hammer to put a nail into concrete.

If you apply that to AI, you want to have processes in place that integrate AI, not have AI re-invent the process on every run.

Specifically, for example in software engineering there is the ISO/IEEE 15288 standard for the Software Development Lifecycle, which sets the process steps and deliverables like the Software Requirements Specification (IEEE 830) and the Software Design Documentation (IEEE 1016).

However, with the AI hype the first principles got re-invented with less engineering discipline, called “spec-driven development”.

Did we not do things in software engineering like that since Dijkstra named the incomprehensibility of large scale software systems the software crisis?

The answer back then was software engineering and humbleness: process standards, modelling languages, design patterns, to create clarity and visibility in the whole process.

Now we have plenty more and more diverse applications of AI than just programming.

I believe the answer for all applications is going to be the same principles:

1. High quality standards & regulation adherence, enforced for example through formal verification.
2. Full visibility of the steps in the process, owned by humble humans who strive for excellence and clarity.
3. Use tools to enable the human mind to achieve more.

Success in AI deployments comes with the first two.

I’d like to close with the words Edsger Dijkstra chose in 1972 to close his Turing Award lecture:

This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.