HMZ.swiss
← Journal
·Bedo Hamza

How we will build software from here on

Key learnings from the AWS AI Summit in Zurich — the AI-Driven Development Lifecycle, the Raiffeisen Bank International showcase, and why Bionic-OS still attacks a completely different part of the problem.

How we will build software from here on

The AWS AI Summit in Zurich came down to a single question: how do we build software from here on? Two things stayed with me — a framework that organises the answer (the AI-Driven Development Lifecycle) and a customer showcase proving it works inside a regulated bank (Raiffeisen Bank International).

Here are the takeaways — and at the end, the honest part: the gap that even the best engineering framework leaves open. That gap is exactly where we work with Bionic-OS.

From project phases to «bolts»

AI-DLC replaces rigid project logic with short, repeated cycles. A bolt runs through three steps — inception → construction → operation — and takes hours or days, not quarters. Then the next one. And the next.

That sounds like Agile with a new label, but it isn’t: the difference is that elaboration and construction happen together with agents, in a mob. The team states the intent, the agents produce, the team reviews — in a loop that doesn’t wait for sprint boundaries.

AI fluency is a role, not a tool rollout

The most important point of the talk for me: AI maturity doesn’t come from licences, it comes from people with a mandate. Shepherds recruit and equip champions, champions run workshops and mob programming, and teams build fluency on real work — not in training rooms.

Four starting principles were worth writing down:

  • Invest in agent context — create persistent context: steering files, agent files, coding standards, a handful of skills. Deliberately don’t overdo it.
  • Make intent explicit — structured specs and a clear definition of done before code gets generated. Prefer small tasks that always succeed.
  • Feed agents, don’t babysit — maintain well-cut backlogs, run several agents in parallel, review output asynchronously.
  • Slow down to speed up — fluency needs time for review, tuning and context building. The compounding comes afterwards.

Autonomy gets tiered by risk

The second maturity step goes from fluency to autonomy — and here it turned pleasantly unromantic:

  • Continuous delivery is the baseline. Without a full pipeline, the human stays the bottleneck. The number: top teams deploy 13.4 times a day, the median is 1.7.
  • Risk-tier your autonomy. Tier 1: agents run free. Tier 2: AI drafts, a human gates. Tier 3: human authorship, staged rollout. Not all or nothing.
  • FinOps for AI. Cost-to-serve instead of cost-per-token — without measurement you simply cannot judge the benefit.
  • Compound across the org. What one team learns becomes a shared skill in an agent registry. That is where the biggest ROI sits — not in the individual pilot.

Governance is the precondition, not the afterthought

The AI-DLC stack has four layers: the platform (cloud, git, containers, observability), the agent harness (where engineers work with agents), context & capabilities (specs, steering files, MCP tools, skills, enterprise knowledge) — and on top guardrails & governance: agent registries, shared skills, security, cost controls, quality gates, compliance.

That top layer is the difference between an impressive pilot and an organisation that scales.

The proof: Raiffeisen Bank International

RBI demonstrated exactly that order in its showcase. The numbers that stuck:

  • 20,000 employees use the bank’s own compliant AI chatbot across the group.
  • 4,000+ engineers work with Claude and other approved coding agents.
  • It is kept under control through an LLM gateway (one approved route to models, easy switching) and an MCP gateway (governed access to the bank’s systems).

On that foundation, RBI built its own AI-native PDLC framework between May and August 2026 — skills, hooks and agents across seven phases from discovery to operate, including a feedback loop back into plan and specs.

The most convincing part, though, was the small case study. A cloud enablement team, 643 tickets per quarter, two competing flows (service requests and sprint backlog) drawing on the same capacity, and up to three days for a single escalated case. The fix wasn’t bigger models, it was packaged workflows: commands, skills, specialised agents, MCP servers and hooks bundled as a reusable plugin. The result: 90 % of cases are resolved by the agentic first response, and triage takes under an hour.

The three lessons, in this order: optimise the workflow (context gathering, handovers, slow feedback loops), anchor the foundation (identity, access, policy, observability, cost — served by the platform), then scale (package proven workflows with permissions, expected outputs and human decision points).

Start here: one single, bounded workflow. Define the outcome, the controls, the human accountability and the metric. Then standardise what works.


And now the honest part

All of this is excellent — and it describes one phase. A product is made in five: discover, specify, build, run, support. In exactly one of them the effort dropped to a fraction. In the other four it stayed exactly the same.

UNCHANGED UNCHANGED ÷ 10 Discover customer talks, market, ideas Specify decide what, write it down Build write the code, test it Run release, operate, measure Support support, feedback, next round This is where Bionic-OS comes in one chain, from the conversation to the support ticket
Bar heights are schematic. The only measured claim is the factor on build.

Work it through on a project the way it actually gets quoted: 120 days, CHF 120,000 — 40 days planning, 20 days coding, 30 days component tests, 30 days system test. The client looks at the coding block and says, correctly, that this is two days and a Pro account today. They are right. 120 days become 102, CHF 120,000 becomes CHF 102,000. And the project is still a project.

More importantly: those 120 days are only the middle block. Before it sits finding out what should be built at all. After it: UX, go-to-market, support, operations, the next release. For both outer blocks no number exists. They are not estimated, not budgeted, not optimised. They just happen. And what isn’t measured doesn’t get better.

It shows most clearly in the 40 days of «planning». The actual thinking — a few people who know the problem arguing it out, listening to each other and deciding — takes one afternoon. The 40 days after that are someone typing that conversation up: into requirements, epics, tickets, spreadsheets. That is not work on the product. That is bookkeeping about the product.

The problem we are solving with Bionic-OS

The genius lives in the exchange. Everything after that is legwork. We never touch the first part. We take all of the second.

We automated building software. Bionic-OS automates the rest — the four phases nobody treats as an efficiency topic, because they never had a number.

Concretely: one continuous chain instead of five separate tool worlds — from the customer conversation in discover, through the specification, the build with the coding agent of your choice, operations, all the way to the support ticket that feeds back into the next round. One context that doesn’t get lost between phases, and agents that support every role — while the decisions stay with the humans.

What I took from the AI Summit fits that exactly: governance first, one bounded workflow to start, standardise instead of one-offs, and the compounding happens where the learning is shared. The only difference — we apply the same logic not to engineering, but to the four phases around it.

So you stop keeping books about the product. And take care of the customer instead.


Sources: talk on the AI-Driven Development Lifecycle and the Raiffeisen Bank International customer showcase, AWS AI Summit Zurich, September 2026. The assessment in the second half is my own.