How Software Development Changes From Here

Bitkom published a study in June 2026 called Softwarewelt 2036, a set
of future scenarios for the software industry built from interviews
with people running software companies. You can read it here:
https://www.bitkom.org/sites/main/files/2026-06/22062026-bitkom-studienbericht-software-2036_1.pdf

It is a qualitative study, twelve interviews, not a statistical
survey, and it says so plainly. But the picture it draws matches what
a lot of us have been feeling in the actual work, and that is worth
taking seriously. Here is what it gets right, read through the eyes of
someone who writes code and ships systems, plus the parts I would push
on.

The Core Claim: Code Becomes a Commodity

The central thesis is blunt. Writing code by hand stops being the core
skill. AI agents already generate code, tests, standard logic, and
boilerplate on request, and the study calls code itself a commodity.
CRUD endpoints, forms, database migrations, trivial unit tests, the
stuff that filled a lot of working hours, moves to the machine.

I think this is correct, and I do not find it threatening, because the
part that was ever interesting was never the typing. Anyone who has
done this work knows the ratio: the hard part was deciding what to
build, understanding the domain, getting the architecture right, and
being responsible for the result. The code was the easy downhill bit
at the end. If a machine takes the downhill bit, the uphill part,
which was always the real work, is what remains.

The study frames the human contribution moving toward goal definition,
architecture, context, quality, and responsibility. That is not a
consolation prize. That is the job with the tedious part removed.

What Actually Grows in Value

The study lists the skills that rise, and the list is worth sitting
with because it is not the list a junior developer expects.

Judgment and review. When a machine produces the code, the scarce
skill is knowing whether the code is any good, whether it fits the
system, whether it solves the right problem. I have written before
about closing the loop so an AI reviews its own output against CI
before a human sees it. That pattern only works because a human set up
the gates and a human makes the final call. The review moved up a
level; it did not disappear.

Architecture and orchestration. The study repeatedly says designing,
training, and orchestrating agent systems becomes the core competency,
above raw programming. Complex systems of platforms, services, and
agents have to be stable, interoperable, and secure, and that is a
design problem no agent owns for you.

Domain knowledge. This is the one the study leans on hardest, and I
agree with it most. Pure coding differentiates less; understanding a
specific industry, its processes, its real problems, differentiates
more. The German phrase the study keeps returning to is that the
bottleneck is not developers, it is people who combine domain
knowledge with AI orchestration. That rings true. A model that can
write any code is not the same as a person who knows which code is
worth writing for this business.

Trust, security, compliance. As agents take over parts of the
lifecycle, the study argues that explainability, auditability, and
governance stop being afterthoughts and become core engineering
competence. Every agent action, every commit, every data query has to
be auditable and traceable. This is the same argument I keep making
from the security side: it has to be built in, not bolted on.

The Part I Live In: Compliance and Sovereignty by Design

One section of the study reads like it was written for the work I do.
It argues that compliance and sovereignty become engineering and
architecture competencies, designed into the product from the start
rather than checked at the end, and that "whoever delivers compliance
and data sovereignty natively beats the generic provider."

I think this is exactly right and under-appreciated. The regulatory
reality in Europe, the AI Act, data-protection law, sector rules, is
often treated as a tax on building. The study's framing, and mine, is
that it is a differentiator. If every agent action in your system is
logged, approvable, and auditable by design, you can operate in
regulated industries that a faster, sloppier competitor cannot touch.
Local inference, local data, local governance become real technical
options for European companies rather than compliance burdens. The
constraint becomes the moat.

This is also where the European angle matters. The study is honest
that Europe's problem is not talent or ideas but capital, market
scale, and the tendency to regulate tools instead of outcomes. Its
recommendation to regulators, regulate the result, auditability,
traceability, non-discrimination, not the specific tool, because
technology moves faster than tool-specific law, is the most sensible
thing in the policy section. Whether it gets heard is another matter.

Where I Would Push Back

Two things in the study deserve more skepticism than it gives them.

The first is the timeline confidence. This is a set of scenarios from
twelve interviews with leaders who have strong incentives to sound
visionary. "Code is a commodity" is directionally true today for
boilerplate and increasingly true for more, but the study slides
between "agents can generate code" and "agents own the lifecycle" as
if the gap were small. It is not. The last mile, the part where the
generated code is actually correct, actually secure, actually fits the
messy real system, is exactly where the current tools are weakest, and
it is most of the work. I run agents daily and the honest state is that
they are a strong accelerator with a supervisor permanently required,
not an autonomous replacement. The study mostly agrees, but its
framing invites over-reading.

The second is the fate of domain knowledge itself. The study notes,
almost in passing, the uncomfortable possibility: domain expertise is
being harvested for AI training right now, through RLHF and expert data
generation, and as AI is embedded into ever more specialized processes,
that specialized knowledge flows into the models. So the "domain
knowledge is the human moat" thesis has a timer on it. The study calls
the window to convert proprietary domain knowledge into a lasting
advantage "narrow." I would go further: the same automation that
commoditized code will come for structured, capturable domain
knowledge next, and the durable human edge is in the parts that resist
capture, judgment under ambiguity, responsibility, and the trust
relationships the study rightly emphasizes but cannot quite operationalize.

What This Means If You Are Doing the Work

Strip the study to advice for an individual engineer and it comes to
this. Stop investing your identity in the typing. The syntax of your
favorite language, the tool you have mastered, the routine task you are
fast at, those are the commoditized layer. Invest instead in the things
the machine does not do: understanding a domain deeply enough to know
what is worth building, designing systems that stay coherent under
pressure, judging whether output is actually correct, and taking real
responsibility for what ships.

And build the verification habit the study implies but does not state
plainly. When code is cheap to generate and expensive to trust, the
scarce, valuable skill is trust: tests that mean something, review that
catches what matters, auditability that proves what happened, security
that is designed in. That is not defensive work. In the world the study
describes, it is the work.

The Point

The Bitkom study's real message, under the consultancy language, is a
shift from execution to judgment. Machines take the execution: the
code, the tests, the boilerplate, the routine. Humans keep the
judgment: the architecture, the domain understanding, the
responsibility, the trust. The study says the software world of 2036 is
"not less human, but human differently," and for once that kind of
phrase is doing real work.

The engineers who do well from here are the ones who saw that the
typing was never the point, and who spent their time on the part that
was: knowing what to build, knowing whether it is right, and being
willing to stand behind it. The tools got better at the easy part. The
hard part is still yours, and it is still where the value is.