Konstantin Tarandevich

Software Architect

Hi, I'm Konstantin — Software Architect & Systems Engineer

Konstantin Tarandevich

I'm a software architect at ZF Group in Koblenz, Germany. My route here has taken me through avionics, real-time systems, research on IMA platforms, and a control-computer patent I helped invent.

Lately, I've been putting AI to work on the engineering tasks I know firsthand: navigating requirements, changing architectures, and checking what those changes actually mean. The further I get, the more time I spend on one question: how do we know when the result deserves our trust?

I'm exploring that through two projects. SWCraft lets me work on AUTOSAR architecture as version-controlled code, with an AI agent helping make changes. With XAVET, I'm developing a way to put AI engineering tools' claims to the test.

This blog is where I share what happens along the way: agents that overstep, convincing answers that miss a requirement, and experiments that make me rethink the design. If you're working through similar questions, I'd enjoy comparing notes.

Writing

X as Code Is Not a File Conversion: What Must Survive When Engineering Leaves Its Tool?

September 19, 2026

Architecture may be stored in Rhapsody, requirements in DOORS or Codebeamer, decisions in Word, and interfaces in ARXML. Moving that system to Git is not a serialization problem. It is a decision about which engineering meaning must survive.

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

September 12, 2026

SWCraft explores how deeply AI can participate in AUTOSAR architecture development without taking control of the engineering decision.

My MCP Server Had 39 Tools. I Had Designed It for the Wrong Caller.

August 27, 2026

SWCraft grew to 39 MCP tools by exposing model operations one tool at a time. Separating the software API from the agent interface reduced the surface to 13 without removing capability.

An LLM Wrote the Code. ISO 26262 Doesn't Care — and That's the Point.

August 16, 2026

ISO 26262 tool qualification never asks who wrote the code, because it never trusted the tool in the first place. If the confidence argument does not depend on the AI being right, AI-assisted development and qualification stop being in conflict.

Nothing Changed in the API. Everything Changed for the Agent.

An MCP tool schema explains how to call a function, but not when that function should become a candidate. A task-scoped semantic contract can keep a growing tool catalog behaviorally compatible.

An Agent Can Pass Validation and Still Make an Unsafe Change

The agent was authorized to modify one component. It helpfully modified two. The model still validated. Why MCP capability is not task authority, and how a task-scoped mutation boundary closes the gap.

The Requirements RAG Router Failed. Then the Benchmark Failed Too.

A requirements RAG reliability experiment: heuristic routing failed on independent paraphrases, query grounding exposed a broken benchmark taxonomy, and typed evidence plans produced a narrow but useful result.

Everyone Is Building an AI AUTOSAR Toolchain. But How Should We Evaluate One?

Generating plausible AUTOSAR artifacts is an interesting capability. It is not yet evidence of a production-ready engineering system. We need a way to measure the difference.

Hybrid Databases Were the Wrong Fix for Requirements RAG

A negative infrastructure result from a requirements RAG lab: Postgres, ParadeDB, and OpenSearch could host useful pieces, but none replaced the current retrieval stack without losing ranking quality or evidence bundles.

The RAG Verifier Learned to Say No. It Still Missed a Hard Requirement Failure.

A held-out requirements RAG experiment: claim-level verification reduced harmful published answers from 35.7% selective risk to 4.0%, but strict human audit still found semantic completeness failures.

Citations Were Not Enough for Safety-Critical Requirements RAG

A negative result from a requirements RAG lab: even with structured records, cited JSON answers, and deterministic guards, the answerer failed the abstention gate when evidence was insufficient.

I Flattened 13,244 Requirements Into Chunks. 97% Lost Their Meaning.

A practical retrieval study over structured automotive requirements: why flatten-and-chunk failed, where ordinary top-k search stopped being the right tool, and how query routing improved both quality and latency.

I Tested a Simple RAG Idea: One Summary per Document. It Was Useful, But Not Enough.

A practical retrieval experiment: can an LLM-generated document summary replace chunk-level search? On a 5,000-document corpus, the answer was measurable — useful signal, clear ceiling, and a better baseline.

My Two AI Agents Talk MCP to Each Other. There Is No Standalone Tool Server.

The default MCP story is one fat tool server, many clients. When I needed two of my domain agents to talk to each other, that shape was the wrong one — and the alternative shows what MCP is actually good for.

I Built an AI Agent for Myself. My Colleagues Wanted to Use It. That Is Where the Problems Started.

When a domain expert builds a working AI agent and people start depending on it, the bus factor problem arrives long before the platform — and a different kind of work begins.

The Boring Part of Requirements Review Is Now Automated

How a lightweight AI agent eliminates the context-gathering overhead in safety-critical requirements review — so the architect can focus on judgment, not tool-switching.

Measuring What Matters: Architecture Quality Metrics for Safety-Critical Software

Architectural quality is difficult to observe — you cannot run a test suite on a dependency graph. This post describes a metrics system built to track it: three levels of measurement, from binary compliance checks to long-term trends.

Building an AI Agent for Embedded Systems Architects

A conversational AI agent that sits in front of complex embedded systems tooling and speaks human — so architects spend less time remembering plugin syntax and more time on actual architecture.