Early weeks with Kernaro Assist: what is changing in how we practice

Kernaro Assist shipped in May 2026, and we put it to work on live repositories almost immediately. This is not a retrospective on a year in production — the tool has only been out a matter of weeks. It is an early field report: what is already paying off, what caught us off guard, what cost more setup than the docs let on, and the open questions we are still working through. We will revisit it as the evidence base grows.

One number framed everything else for us in those first weeks. Across the repositories we run Assist on, three figures stood out far more than any per-task time saving:

Modeling: description drafting was the real win

We went in expecting big time savings on capture. The premise was reasonable: Kernaro Assist would draft element descriptions and spare architects the tedium of writing them by hand.

The reality turned out to be more specific. Description drafting is fast — genuinely fast. An architect supplies context (the system’s purpose, its stakeholders, the constraints that matter) and Assist proposes a description in seconds. The architect edits or signs off. That time saving is real and it adds up.

The surprise was where the larger benefit landed: consistency and naming validation. Hand-authored repositories drift. The same concept ends up labeled “payment processing” in one place, “payment gateway” in another, “payment engine” in a third. Some descriptions run four sentences, others four words. Application naming follows no pattern anyone agreed to.

Assist made that drift visible in a way manual review rarely does. When the AI proposes names and descriptions against your MDG conventions, the inconsistencies jump out immediately. The repositories we run it on are noticeably more uniform than they were. That sounds minor until you query for “all payment systems” and get a different answer depending on which label you happened to search for.

MDG is not optional once you bring AI into modeling. It becomes the guardrail that makes AI safe to use at speed.

The governance cost ran higher than we had budgeted for. The picture we imagined was simple: architect approves a description, it goes live. What we hit instead was that approving AI-generated relationships demands more rigor than approving descriptions. Assist can propose that “System A integrates with System B,” but the relationship properties — cardinality, stereotype, synchronous versus asynchronous — are often off. Early on, teams were rubber-stamping incorrect relationship metadata without grasping the downstream cost.

So our standing recommendation became: tighten the MDG profile hard before you let Assist generate relationships. When your MDG spells out which relationship types are valid, what cardinality rules apply, and which stereotypes are mandatory, Assist’s proposals get markedly more accurate. Teams that did that work up front watched governance overhead drop. Teams that skipped it spent their first weeks in review-and-reject cycles, then went back and tightened the MDG anyway.

The lesson is blunt: a tight metamodel is what keeps AI-assisted modeling safe at speed.

Analysis: the cost of asking dropped, so people started asking

We expected faster impact analysis, and the premise held: Kernaro Assist runs impact-analysis queries faster than an analyst working the repository by hand. We had pencilled in time savings of 30–40%.

The bigger effect was something else. Yes, impact analysis sped up. But cheap analysis changed which questions people bothered to ask.

Traditional practice runs on a finite analysis budget. If one impact analysis a day is all you can manage, you ration. You analyze the big decisions and let the small ones slide. You certainly do not revisit a call that looked fine months ago but reads differently now.

When the cost of asking falls to “a few seconds,” people start asking the questions they would previously have skipped. The product team asked “what’s the dependency chain if we decommission this API?” — not because retirement was on the table, but out of curiosity. Operations asked “do we even use this middleware anymore?” because the query was free. Security asked “what customer data flows through this system?” not on a hunch, but simply because they could.

We logged roughly a 40% rise in analysis queries over the first few weeks. Most were low-stakes curiosity. A handful uncovered real problems: systems used in ways nobody had written down, dependencies that should have been pulled out years ago, data sensitivities no one was tracking.

The gain is not just the minutes saved on any single analysis. It is the patterns you catch when analysis is cheap enough that people actually ask what they should be asking. You learn the things you did not know you did not know.

Governance: completeness checking works, configuration takes patience

We expected to automate completeness checking. The Broadcast Event capability in Kernaro Assist can be configured to flag missing elements, confirm that required metadata is present, and spot gaps in relationship coverage — in principle, the tedious audit work, automated.

In practice, Broadcast Event configuration was harder than the documentation lets on. The docs make it sound linear: define a rule, the check runs, exceptions appear. On the ground, teams needed several passes to write rules that caught the gaps they cared about without drowning them in false positives.

One team spent the better part of two weeks getting an “application must have a documented owner” rule to behave. It had to account for applications owned by external vendors, applications in legacy status, and applications still in planning. The first version fired on all of them, and they refined it repeatedly. Another team wrote a well-meaning “business capability must map to at least one strategic initiative” rule and eventually switched it off — their planning cadence left it out of step with the capability map for a stretch of every year.

Once the rules were right, they were dependable and worth the effort. Teams that put in the configuration time now lean on continuous completeness validation in place of an annual audit. Exceptions surface the moment they appear, not three quarters later in a review.

The lesson: Broadcast Events are powerful, but they ask for upfront investment in understanding your own rules well enough to encode them. You cannot decide the rule in the moment — you have to think through the edge cases and the validation logic before you implement.

Stakeholder engagement: fewer simple questions, sharper conversations

We expected the email volume to fall. The theory: stakeholders would answer their own questions through Kernaro AI Hub instead of pinging an architect.

That happened — with a twist. The simple requests did dry up. “Who owns system X?” now comes back from Kernaro AI Hub. “What applications support process Y?” is a query. The volume of “ask an architect” work fell by roughly 35–40%.

But the requests that still reached architects shifted in character. The easy ones were gone. What remained was harder: architectural decisions with real ambiguity, cross-system trade-offs, and the cases where the model gives an answer the stakeholder does not trust or does not know how to read.

The conversations got better. Instead of a 30-second “here’s who owns this system,” architects found themselves in 30-minute discussions about whether retiring a system would break something downstream, how a business transformation would force systems to be reorganized, and whether a new capability should be built or bought.

This is not fewer conversations. It is better conversations. The architects we work with named this as the change that mattered most: cutting out the rote context-gathering let them do architecture thinking instead of architecture service work.

What we are still figuring out

Three things we have not solved — and we would rather say so plainly.

Governing AI-generated content at scale

When Kernaro Assist is producing hundreds of descriptions and dozens of relationships a week, what does governance actually look like? We have moved from “every entry gets human review” toward “exceptions get reviewed” and “spot checks happen on a cadence.” But we do not yet have a settled model for trading governance rigor against the ability to move at AI speed. It is still taking shape.

Training new architects to review, not just author

Onboarding an architect to a repository means teaching them what is in it. Onboarding them to a repository that runs on Kernaro Assist means teaching them both what is in it and how to review AI-generated content. Those are different skills. We are learning that “approval” calls for different judgment than “creation,” and we are still refining how we train for it.

Holding model accuracy as generation speeds up

If the repository grows at several times the old pace because Assist is drafting content, the model can drift into inconsistency faster too. Our governance mechanisms catch most of it, but we have seen cases where the model was technically consistent yet practically confusing — relationships that were correct but emphasized the wrong aspects of the architecture. Detection and correction for that class of problem is still a work in progress.

What this means for your practice

If you are weighing AI augmentation for your EA practice, here is what the early weeks of real use point to.

A few weeks in, the early signal is encouraging. The repositories we run Assist on are more consistent, more complete, and faster to query. The architects using it are doing more analysis, having better conversations, and spending less time on rote work. The governance overhead is real but manageable, and we are learning something new about practicing at AI speed almost every week. For the wider picture of how this reshapes the role, see AI Augmented Architecture; to see the tooling in context, see AI Power Tools for Sparx EA.

Configure the Solution walks your team through this whole journey — not as theory, but with practitioners who are living it now.