← All posts
Models & Autonomy

AI Writing AI: What It Changes

Published on 07 November 2026 · 6 min read · Daniel Ostner

Two reports this week kept me thinking longer than planned. Together, they raise a question that never comes up in architecture reviews: who controls the model that changes other models?

Two Reports, One Uncomfortable Question

Last week I was in an architecture review. Someone asked whether we could 'slightly optimize' an existing model without retraining. The answer was still: not really.

Then came the report from The Decoder. OpenAI's GPT-6 Astra can read the weights of other AI models like source code and rewrite them deliberately. The process requires neither classical training nor GPU clusters running for weeks. That sounds like a technical footnote. It isn't.

What GPT-6 Astra Shifts Architecturally

Until now, the line between model and training process was clear. A model is built through training, deployed, and stays what it is — until you retrain it. That separation also underpins most governance assumptions: which data went in, when, under whose oversight?

If one model can read and rewrite another model's weights like source code, that line disappears. According to The Decoder, GPT-6 Astra enables targeted performance improvements without classical training. Efficient. But it also means a model change may no longer produce the artifacts governance teams rely on: no training log, no versioned dataset, no checkpoint timestamp tied to a known process.

For companies classified as operators of high-risk systems under the EU AI Act, this is not academic. Articles 9 and 12 require risk management systems and logging obligations. If model changes happen outside classical training processes, governance frameworks need to cover that explicitly. Otherwise they simply don't.

Governance

Organizations running models that can be modified by other models need their own logging logic. The classical training log is no longer enough.

DeepSeek's Coding Agent: Autonomy Without Oversight

At the same time, DeepSeek published an open-source super-agent for coding tasks, according to AI Agents Directory. The agent identifies problems on its own and generates solutions — fully autonomous workflows, direct competition to Anthropic Claude.

Open source means any organization can run this agent internally, adapt it, plug it into existing pipelines. That's the upside. The downside is the same argument, flipped. Whoever operates an autonomous coding agent internally is an operator under the AI Act, with all the obligations that come with it.

Autonomous agents writing code are not assistance tools anymore. They make decisions about system architecture, security logic, database queries. When such an agent introduces a bug, the question is not only technical. Who approved this output? Who was responsible? And — the familiar silence in every review I know — who even noticed?

In practice

Autonomous coding agents need an explicit approval logic — not because the code is bad, but because without it, accountability lands nowhere.

What This Means for Your Architecture

Both developments follow the same pattern. AI systems are becoming more autonomous, faster to modify, and harder to observe. That is not an argument against using them. It is an argument for making the architecture decisions now, not after the first incident.

Three points that belong in every architecture discussion once these systems are in scope:

  • Document model identity: which version runs where, and how is a change — whether through training or through an upstream model — logged and versioned?

  • Define autonomy boundaries: what can an agent decide on its own, and what requires a human approval step? This belongs in the system specification, not the user manual.

  • Clarify the operator role: who in the organization owns accountability for the output of an autonomous agent? 'The team' is not an answer.

Governance Frameworks Under Pressure

Most governance frameworks I see in DACH enterprises were built for a world where models are stable and humans make decisions. That world still exists. But it is developing cracks.

GPT-6 Astra rewriting model weights and DeepSeek's autonomous coding agent are two data points. Both point the same direction: the layer between human and decision is getting thicker. That is not inherently bad. But it means governance documents written two years ago may promise control in exactly the wrong places.

The guide to the 8 architecture principles in AI Navigator offers a structured starting point for checking which principles still hold in your architecture and where gaps are forming. The guide to building AI governance helps define organizational responsibilities that work for autonomous systems — not just classical assistance tools. And the governance check in AI Navigator is a solid first step for an honest assessment of where things stand.

What I Take Away

I am not pessimistic about AI development. Models that make other models more efficient, agents that free developers from routine work — that is real progress. Genuinely, I welcome it.

What stays with me is the governance gap that opens when systems move faster than the frameworks meant to oversee them. In the reviews I run, questions about model versioning and approval logic for autonomous agents still come up rarely. That will have to change. Better now than after the first incident that needs explaining.

What remains open for me is how audit requirements will evolve when model changes happen outside classical training processes. The regulatory framework is not yet where the technology already is. That is not a new problem. It is just unusually visible right now.

Sources

This draft was written with AI assistance from the reports below and requires editorial review before publication.

Put this into practice

Whether an AI use case may go live is decided by data protection, transparency and risk — not by the model. Without a structured check you risk stop signs only shortly before go-live.

Start the AI Governance Check →

Daniel Ostner

Author of the Enterprise AI Guide

AI-assisted draft, editorially reviewed on 07 November 2026.

View book →

Daniel Ostner brings 20+ years of experience in SAP landscapes and enterprise IT — including as Chief Architect for an S/4 greenfield transformation in global chemical distribution and roughly 7 years as Head of IT at a SAP consulting firm. Certified through IESE's Executive Program in Data & AI, among others.

Go deeper in the guide