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.
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?
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.
GPT-6 Astra sieht die Matrix: Für das Sprachmodell sind KI-Gewichte lesbarer Code – The Decoder (DE): the-decoder.de/gpt-6-astra-sieht-die-matrix-fuer-das-sprac… (opens in a new tab)
DeepSeek startet autonomen Super-Agent für Coding-Aufgaben – AI Agents Directory / Digital Trends / NDTV Profit: aiagentsdirectory.com/news/ai-agents-news-brief-3 (opens in a new tab)
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.
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
8 Architecture Principles
Eight binding guardrails for every AI architecture — from API First to Interop over Lock-in, each with a concrete violation indicator.
Building AI Governance
Solid AI governance runs on three levels: strategic, tactical, operational. A minimal model with 5 roles and 6 core decisions is enough to get started.