← All insights

AI-engineered architecture: standards in weeks, adoption still human

Jacques Domenie · October 7, 2026 · 7 min read

AI can write an architecture standard in a day. Whether that helps depends on the rules around it, and on the part AI cannot do: getting people to use the standard.

Software developers have already had this argument. In February 2025 the AI researcher Andrej Karpathy named a new way of programming: vibe coding. You describe what you want, accept whatever the AI produces, and stop reading the code. Eight months later the developer Simon Willison named the opposite: vibe engineering. Experienced engineers use the same tools at the same speed, with tests, specifications, version control and review, and they stay accountable for the software they produce. His point was that AI rewards the discipline experienced engineers already have.

Architecture has the same split, and it matters more there. Others have started using the terms vibe architecture and vibe architecting for architectural choices made on the fly by AI or by prompts, without deliberate design. Bad code fails a test. Bad architecture reads well and gets approved.

What changes when the writing takes a day

In the architecture practices I led before working this way, a set of enterprise principles took, by my estimate, six to eight months from first draft to approval. A single standard took four to six months. Most of that time went into writing, processing feedback and keeping the document consistent with everything else. Meanwhile the ground moved: technology changed, the business changed, people left, and new views started pulling the document in other directions.

In my experience, working with AI under a strict set of rules, writing the first version of a set of principles or a standard now takes less than a day. Each round of feedback comes back as an updated version within hours. The whole cycle, including approval, takes weeks to a month. Again by my estimate, a practice can produce three to five times as many standards in the same period. That compares different organisations and roles, so it is a rough estimate.

The bigger gain is that a document written in weeks is still current when it is approved. And the old complaint from leadership, that architecture takes ages while the business needs to move, no longer holds. In my experience, architecture stops being the bottleneck for getting a standard approved, or the perceived one.

The rules that make the speed usable

AI is often wrong. So is the human. Working together does not mean depending on each other's output. Without agreed checkpoints, the result keeps missing what was expected, and a prompt alone rarely carries enough context.

A small example. In architecture decks, the AI kept writing headings that sounded like sales copy and meant nothing to the audience. We wrote a rule: descriptive, neutral titles. The rule helps, and we still correct the headings time and again. The first deck in the right template took days and many rounds; a deck now takes about an hour. The difference came from the rules and from both sides learning. The errors that matter more are in the content, and they are the reason for the review rule.

The rules I would not give up:

  • Checkpoints and validations, agreed before the work starts.
  • Nothing leaves without review.
  • Client material stays local. The security rules come first, and the speed comes second.
  • Iterate until it is good, and keep what both sides learned, so the next round is faster.

Those rules are what I mean by AI-engineered architecture. The engineering is the set of conditions you can check before you start: principles and standards written down and versioned, a decision register, a named review step, a secure setup, and above all a practice with a mandate and a decision body that can approve what it writes. Where those conditions are missing, AI only makes vibe architecture faster.

What AI-engineered architecture lets a CTO do

Once the standards exist, testing against them becomes cheap. A team asks for a solution validation; a future-state option needs challenging; leadership wants to know what a hypothesis would break. Those checks used to compete for weeks of an architect's time. With the standards written down and AI doing the reading, I expect them to take days rather than weeks, early enough to inform a decision before money is committed. I have not measured that yet.

One case shows why it matters to test before money is committed. Data had to move between two internal platforms. Architecture showed upfront how the standards, and the cloud provider's own prescribed approach, would do it. The pressure to deliver the data exactly as specified was strong, and a tailor-made solution was built instead. It worked, it passed its tests, and it went live. Then the running costs became visible, and leadership stopped it. By architecture's own calculation, the standard approach would have cost about a tenth, and been more reliable and easier to maintain. The alternative was on the table and lost anyway; a better cost model upfront might have changed that, and I cannot show it would have. No AI was used in this case. With AI, the same scenarios and their cost calculations can be played through much faster, early enough to put the cost argument on the table before the decision.

What AI does not do

Writing the standards was never the hardest part. Getting people to use them is. When a set of enterprise principles I worked on was approved, the architects did not start applying them on their own. They needed sessions, practice, coaching, correction, encouragement and a firm hand, and above all they needed to understand why. None of that can be done by AI; it is how people learn a new way of working.

Documents are the condition for maturity; their use is the measure. Researchers have studied the use of enterprise architecture before, and TOGAF, The Open Group's architecture framework, has compliance reviews. I would sharpen it. Count the significant decisions and solution validations in which a named principle or standard demonstrably changed the outcome. Count only those where someone other than its author raised it. Counting citations alone would invite box-ticking, which is why the measure asks for a changed outcome.

Two more things stay human. One is judgement: the politics, the relationships with stakeholders, and the sudden changes caused by people's actions. The other is ownership. Everything built this way has to belong to the practice that uses it, so it stays when the architect who built it leaves. My rule is that the head of the practice and the team own all of it within six months.

What this does not prove

This rests on my own practice and one current engagement, against my own earlier way of working. There are fair rival explanations. The speed may come from discipline that was already there, with AI as a fast reader of well-kept material. And an experienced architect would have been faster in any case; some of my speed-up comes from many years of practice. I cannot separate these from one practice. My working view is that the method has to be in place first, and AI then multiplies what it produces.

Architecture repository tools, where a team keeps its models and inventories, hold that content and help analyse it, but they are not built to write a practice's own principles and standards. In software architecture, two practices already cover parts of this: fitness functions, checks (usually automated) that a system still keeps an architecture rule, and architecture decision records, short numbered records of a single decision. In the broader architecture practice they are much less established, and that is where I see the gap. The published work on AI in architecture that I found is about generating models, views and decision records, or analysing existing documents; none of it is about a practice writing its own principles and standards.

Where to start

Pick one standard your teams keep asking about that has never been written down, in a practice with a body able to approve it. Write the rules of engagement first: what gets checked, who reviews, what stays inside. Then draft it with AI in a day, and spend the weeks you saved on the sessions that get it used.

Jacques Domenie led the IT function of a bank under central-bank supervision and answered to its board, its supervisors and its auditor. He works for organisations part of the week through Delfen (delfen.com).

Contact: domenie@delfen.com or delfen.com/en/contact.

Sources & further reading

Recognize this question in your own organization? That is worth a conversation.

Get in touch