Why I’m Building SWCraft:Keeping the Architect in Control of AI‑Assisted AUTOSAR Design

A powerful language model makes a simple instruction sound increasingly plausible:

Design the software architecture for this system.

That is not the future I want SWCraft to build.

SWCraft is an Architecture as Code environment for AUTOSAR Classic that I am developing. Its source model lives in version-controlled YAML. Deterministic tools check the model and generate ARXML, LikeC4 diagrams and Sphinx-Needs documentation. An AI assistant can investigate and propose changes to the same model through MCP.

I am building it around a principle: an AI assistant should be able to participate deeply in architecture development without taking control of the engineering decision.

The problem is not only that an LLM is nondeterministic or may hallucinate. Better models may reduce those failures. The deeper problem remains even if every fact in the answer is correct: architecture is not merely an artifact to generate. It is a decision process in which someone must decide which goals matter, which constraints are binding, which risks are acceptable and what evidence is sufficient.

If an agent receives an incomplete problem and returns a finished architecture, it has done more than draw components and connect interfaces. It has also filled gaps, selected trade-offs and discarded alternatives. A polished result can hide those decisions precisely because it looks complete.

Architecture Is Not an Answer to Generate

Consider a fictional design question as an architect might ask it:

What if we moved this component to another core?

The sentence is short. The work behind it is not.

In the SWCraft model, a component is not assigned directly to a core. Tasks run on cores, and those tasks execute component runnables. Answering the question therefore means identifying which tasks and runnables are involved, whether they share execution context with other components and which communication paths would cross a core boundary. It also means asking whether the resource information is complete, which requirements constrain the placement, what would improve and what would become worse.

There may be several reasonable answers. Move the affected tasks together. Split a task that mixes runnables from several components. Keep the placement and change the communication pattern. Or conclude that the available model does not contain enough information to choose.

An assistant can help investigate all of those possibilities. It can locate relevant elements, trace relationships, construct candidates, run available analyses and explain the results. It can even recommend one alternative over another.

But a recommendation is not the same thing as an accepted architecture decision.

Suppose an agent proposes a placement that reduces cross-core communication. The model is valid, the generated artifacts match it and every implemented consistency check passes. The proposal may still be wrong for the system because a product variant, an ownership boundary or an unstated future requirement was not represented in the model.

No hallucination is necessary. The agent may have solved the problem it was given perfectly. The problem it was given was incomplete.

The Boundary I Want SWCraft to Preserve

The principle is not that AI should be restricted to mechanical work. That would leave much of its value unused.

The assistant may explore, propose, analyze and recommend. It may help an architect understand a larger context than could be held in working memory at once. It may identify contradictions, expose missing information and prepare changes that would be tedious to make by hand.

What it does not receive automatically is the authority to turn its proposal into the accepted architecture.

A proposal does not become an engineering decision merely because it is plausible or passes the available checks.

This is more than adding an approval button after generation. A person cannot meaningfully approve a change they cannot understand. Review needs a visible scope and a clear account of what changed, which assumptions were used, which properties were checked and which questions remain open.

The purpose of that boundary is not to claim that a human architect is infallible. People also make decisions with incomplete information and wrong assumptions. The difference is that an engineering decision needs an explicit owner who accepts its known trade-offs and consequences. Accuracy can be improved with a stronger model; responsibility cannot be assigned by model capability.

A Model That Survives the Conversation

One choice at the center of SWCraft is that the accepted architecture exists outside the assistant’s conversation.

Components, interfaces and their relationships are explicit model elements. Their definitions can be inspected and versioned. Generated artifacts derive from them. After an interaction with the assistant, I should be able to close the chat and still determine what changed. Another engineer should be able to inspect the model and run its checks without reconstructing my prompts.

YAML makes the source accessible to ordinary text tools, but the format alone does not create control. The model still needs explicit semantics: which concepts exist, what a reference means, which combinations are supported and how incomplete information is represented. Otherwise the ambiguity simply moves from the conversation into the files.

That is why the model is more than storage. It is the shared boundary between the architect, the assistant and the deterministic tools.

Checks Establish Less Than a Decision

SWCraft’s checks have a deliberately limited role. They can establish that supported relationships are consistent and that a candidate obeys implemented rules. They can reject a broken reference or an invalid combination in a repeatable way.

They cannot establish that a design is the best response to its requirements. They cannot account for an engineering fact that the model does not contain. They cannot decide whether the remaining uncertainty is acceptable.

This distinction matters because a green validation result is easy to overinterpret. It means that the candidate satisfies the properties the tooling knows how to check. It does not mean that the architecture is correct in every sense that matters.

The assistant therefore works through a controlled engineering surface. It can discover the model’s supported concepts, read existing elements and propose changes through an editing protocol. Those changes are applied to an isolated copy and checked against the complete staged model before the exact semantic delta is presented for review. Full artifact generation and ARXML validation remain separate gates.

The goal is not to put a human click at the end of an autonomous process. It is to keep the path from question to candidate to evidence to acceptance inspectable.

One Design Has Already Changed

The MCP interface gave me an early example of why that path matters.

As SWCraft gained model operations, I exposed them as individual tools. The catalog grew to 39. Each addition made sense from the perspective of the software library beneath the server, but the whole catalog gave the assistant an increasingly awkward set of choices.

I had designed the interface around implementation functions rather than the decisions its caller needed to make.

Separating the deterministic software API from the agent interface reduced the surface to 13 tools. Model discovery, reading and changes became a shared protocol, while genuinely specialized capabilities retained their own tools.

I have written up that redesign separately. What matters here is the pattern. Building the system exposed an assumption that looked reasonable from one side of the boundary and wrong from the other. The project made that assumption concrete enough to test and revise.

I expect more of those revisions. Some will reveal limits in the model. Others will come from the assistant’s behavior, from generated artifacts or from changes that pass every available check but remain difficult for a person to assess.

What Exists, and What Remains an Experiment

SWCraft already has the foundation for this work: a versioned model, controlled editing, consistency checks and generated engineering artifacts. There is enough working software to follow real design choices and learn from their consequences.

The broader ambition is to support architectural experiments: state a question, identify relevant constraints and assumptions, construct candidate changes and compare their consequences before selecting one.

The component-allocation question at the beginning belongs to that ambition. It is not a claim that SWCraft can already perform a complete allocation study. A useful experiment would need explicit resource information, placement constraints and an analysis whose limitations are visible. A structured model is a foundation for that work; it does not complete it.

This is also why I do not want to present SWCraft as an autonomous architect. Autonomy would be an easy headline, but it would point the project toward the wrong objective. The interesting question is not how quickly an agent can produce a finished architecture. It is how much useful work the agent can do while the architecture decision remains explicit, reviewable and owned by an engineer.

Building SWCraft

I will use this series to follow that question through the development of the project.

Each article will take one design assumption far enough to see what happens when it meets an implementation or an experiment. Some assumptions will survive. Some will need a different boundary. Others will expose information that the model or the tooling does not yet represent.

The aim is not to turn every revision into a success story or make the project’s direction look inevitable after the fact. I want to preserve the alternatives, limitations and unresolved decisions that make the engineering work meaningful.

The question behind SWCraft is therefore not whether an AI can generate a software architecture.

It is whether an AI can help us understand an architecture change more deeply without taking control of the decision we are trying to make.