Fujitsu's pitch for fiscal 2026 is end-to-end autonomous software delivery — a "100x productivity" target driven by AI agents that handle requirements, design, code, tests, and integration with no human in the loop. It's a credible bet, and it's also the opposite of how a platform-kernel-first crew should be built. Autonomy works to the extent the surrounding controls are real. The right sequencing is the kernel first — observability, failure boundaries, secrets, operator surface — and autonomy on top.
TL;DR: Fujitsu is selling autonomy-first software delivery for fiscal 2026. We're betting on kernel-first: observability, failure boundaries, and least-privilege secrets before automation gets the keys. Same destination, opposite sequencing.
On February 17, Fujitsu announced an AI-Driven Software Development Platform built on its Takane LLM and an agentic stack from Fujitsu Research. The pitch is unambiguous: multiple AI agents collaboratively execute requirements, design, implementation, and integration testing, achieving "full automation of the entire process without human intervention." Fujitsu cites a proof-of-concept where a three-person-month modification was compressed to roughly four hours — the source of the headline 100x productivity number — and intends to apply the platform across medical, government, finance, manufacturing, retail, and public-sector software by the end of fiscal year 2026.
The pitch lands at the same destination as a platform-kernel-first build, but takes the opposite route. The difference is sequencing.
Fujitsu's framing emphasizes end-to-end autonomy: requirements in, tested software out. Our approach starts with the control plane — state management, auditability, failure handling, security boundaries, operator visibility. We are not avoiding autonomy. We are treating it as a capability that should sit on top of a trustworthy kernel, not as the kernel itself.
That choice affects how agents are configured, how failures surface, how secrets are scoped, and how quickly we let automation make irreversible decisions.
Fujitsu's platform spans the full lifecycle. The idea is familiar: connect specialized AI capabilities so customers move from intent to working software with less manual coordination. That is a credible enterprise bet. Many buyers want outcomes rather than tooling, and a managed service model hides operational complexity and reduces setup friction.
But the tradeoff is visibility. If a multi-agent pipeline misinterprets requirements, generates code from that misunderstanding, and then generates tests that validate the same flawed interpretation, the system can look successful while still being wrong. The recent Fortune scoop on the Anthropic "Mythos" data leak — where details of an unreleased model surfaced through a misconfigured content store — is a useful reminder that the failure mode of autonomy-adjacent systems is rarely "the model said something dumb." It is "the system did something irreversible, or exposed something it shouldn't have, before anyone noticed."
The right question is not whether the platform is autonomous. It is whether uncertainty and failure are surfaced early enough for a human to intervene. Those are the categories of failure that pushed us toward a kernel-first rebuild.
When we restarted our agent platform, we chose to build the boring parts first: the infrastructure that makes the rest of the system understandable under stress.
File-based configuration as a source of truth. Every agent has its capabilities and operating boundaries defined in version-controlled files, reviewed and diffed through normal engineering workflows. That introduces friction, and we want that friction. If an agent's behavior changes, the change appears in a pull request. If something breaks, operators can trace what changed and when.
Explicit failure boundaries. Each agent has a defined degraded mode. If our content agent cannot reach an external dependency, it does not loop indefinitely or quietly substitute lower-confidence output. It logs the failure, emits a structured error artifact, and waits for operator input. Silent degradation is harder to debug than loud failure.
The operator control surface. Our control plane shows operators what each agent is doing, what state it is in, and where decisions require scrutiny. Monitoring and alerting are not add-ons; they are part of the first layer of the platform. If we add more autonomy later, it sits on top of that surface rather than replacing it.
| Dimension | Autonomy-First (Fujitsu pattern) | Platform-Kernel-First |
|---|---|---|
| Primary optimization | Throughput and abstraction | Operator trust and reliability |
| Failure handling | Managed by the platform | Explicit boundaries, structured error artifacts |
| Configuration | Service-managed | File-based, version-controlled, auditable |
| Human oversight | Concentrated at review points | Decision points surfaced to the control plane |
| Path to autonomy | Broad autonomy early | Kernel, then supervised autonomy, then deeper automation |
| Security posture | Shared-responsibility model | Full-stack ownership with least-privilege controls |
| Degraded mode | Not fully defined publicly | Defined per agent with operator escalation |
Neither path is inherently wrong. Fujitsu is building for enterprises that want to buy outcomes as a service. We are building for crews, including our own, that need to understand and govern the process producing those outcomes.
If one system can interpret requirements, generate code, create tests, and trigger deployment actions, a single bad assumption can travel a long way before anyone notices. The current Anthropic v. Department of Defense litigation, filed March 9, is going to test a related question at the policy layer: how much autonomy is acceptable from a vendor before it has to be governable by the customer?
Our approach uses 1Password Business as the source of truth for secrets, scoped through least-privilege patterns so agents receive only the credentials they need.[^1] An agent should not inherit another agent's permissions or expand its own access scope.
The reliability side is just as important. GitClear's research on 211 million lines of code from 2020 through 2024 found that the share of new code revised within two weeks of commit grew from 3.1% to 5.7%, copy/pasted lines rose from 8.3% to 12.3%, and refactored ("moved") code fell from 24.1% to 9.5%. That does not prove AI makes software worse, but it does suggest raw generation speed creates downstream cleanup costs when quality gates are weak.
Some autonomy-first results are genuinely impressive when they are scoped narrowly. Wipro PARI's PLC ladder code generator, built on Amazon Bedrock with Anthropic Claude models and a custom validation framework, hit an average 85% validation accuracy and cut PLC code generation from three to four days down to roughly ten minutes per query. That works because the domain is narrow, the validation target is a real industrial standard (IEC 61131-3), and the gates are codified. The lesson is not "autonomy is dangerous." It is "autonomy works to the extent the surrounding controls are real."
A managed service model is often the right commercial choice. It lowers adoption friction and lets customers experiment without standing up infrastructure. But it also shields them from the mechanics of failure.
We prefer to learn those mechanics ourselves first. Running our own agents on our own infrastructure gives us direct evidence about retries, degraded modes, dependency failures, and operator burden. When the content agent produces a weak draft, we see it immediately. When the routing agent misroutes work, we debug the routing logic ourselves. That density of feedback is hard to replicate when a vendor owns the runtime and abstracts away the failure details.
Internal-first is not a permanent ideology. It is a sequencing decision. We would rather earn confidence through operational experience than assume it from a polished interface.
It is realistic on narrow, repetitive, well-specified tasks — Fujitsu's three-person-month-to-four-hours case and Wipro PARI's three-days-to-ten-minutes PLC pipeline are real data points. It is much less reliable as a blanket claim across all software work. Productivity depends on the type of problem, the quality of requirements, the cost of review and rework, and how much risk a team can tolerate.
Fujitsu's fiscal 2026 target gives the market a concrete reference point for autonomy-first software delivery. The opposite bet — kernel-first — is that the crews who win long term will not just automate more work; they will understand the conditions under which that automation is safe, observable, and governable.
If autonomy is the promise, control is the prerequisite.
[^1]: An earlier iteration of this platform used HashiCorp Vault for secrets. We have since migrated to 1Password Business as the source of truth; the architectural principle (least-privilege, per-agent scoping) is unchanged.
Discover more content:
