Two Tribes: Why Systems Engineers and Developers Can't Hear Each Other

Here is a scene that plays out at every systems-heavy organization we’ve talked to. A systems engineering team spends three months building a detailed architecture model in SysML. Block definition diagrams, internal block diagrams, requirement hierarchies, interface specifications - the full treatment. They export a PDF, attach it to a Confluence page, and send it to the software development team.

The developers open it, skim it, close it, and start writing code based on the meeting they had two weeks ago.

Three months later, the implementation has drifted so far from the architecture that the model is functionally fiction. The SEs are frustrated because nobody followed the design. The developers are frustrated because the design didn’t account for the realities they discovered during implementation. Both sides are right. Both sides are talking past each other.

This is not a communication failure. It’s a structural one. Systems engineering and software engineering evolved as separate disciplines with separate toolchains, separate cultures, and separate definitions of what “done” looks like. The gap between them isn’t a tooling problem you can bridge with an integration plugin. It’s ontological.

Two worldviews, two vocabularies

Systems engineers think in architectures, interfaces, requirements, and traceability. Their mental model is the system - the whole thing, from stakeholder need to operational environment. Their artifacts are diagrams, specifications, and allocation matrices. Their tools are desktop modeling environments and requirements management platforms. Their workflow is deliberate: define, allocate, verify, validate.

Software engineers think in APIs, tests, deployments, and iteration cycles. Their mental model is the codebase - a living artifact that compiles, runs, and ships. Their artifacts are pull requests, test suites, and CI pipelines. Their tools are code editors, Git, issue trackers, CI runners. Their workflow is iterative: build, test, ship, learn.

These aren’t just different tools. They’re different epistemologies. When a systems engineer says “model,” they mean a representation of system structure and behavior that may never execute. When a developer says “model,” they mean a data structure or an ML artifact that runs in production. When an SE says “interface,” they mean a formal specification of ports, flows, and protocols. When a developer says “interface,” they mean a TypeScript type or a REST endpoint.

The same words mean fundamentally different things. And every handoff between the two disciplines is a translation exercise with no shared dictionary.

SE models don’t compile

Here’s the core asymmetry: developer artifacts are executable. You can run them, test them, deploy them, roll them back. They have a direct, verifiable relationship with the system they describe. If the code is wrong, the system fails. The feedback loop is tight.

SE artifacts - in their current form - are documents in a different format. A SysML model doesn’t compile. It doesn’t generate test cases. It doesn’t connect to CI/CD. It can’t tell you whether the implementation conforms to the architecture. It’s a representation that has to be manually interpreted, manually translated into implementation tasks, and manually checked against the result.

This asymmetry creates a power dynamic that nobody talks about openly. Developers hold the artifact that actually runs. SEs hold an artifact that describes what should run. When those two diverge - and they always diverge - the implementation wins by default. Not because the architecture was wrong, but because the architecture had no enforcement mechanism.

The handoff between the two is manual and lossy. The SE produces an architecture. The developer reinterprets it through the lens of framework constraints, performance requirements, and whatever they learned during the last sprint. The implementation drifts. The SE updates the model after the fact - or more commonly, doesn’t. The model becomes a historical document, a snapshot of intention that no longer reflects reality.

The velocity mismatch

There’s a temporal dimension to this gap that makes it especially corrosive. Modern software development moves fast. A competent development team with good tooling can implement, test, and deploy a feature in days. AI-assisted development is compressing this further - implementation is approaching the speed of thought.

Systems engineering, by design, moves deliberately. Architecture decisions need to account for multi-year lifecycles, cross-domain interfaces, safety constraints, and regulatory requirements. You don’t iterate your way to the right avionics architecture. You analyze, model, verify, and commit.

The result is a coordination problem disguised as a culture clash. Developers aren’t ignoring the architecture because they’re reckless. They’re ignoring it because by the time the architecture model is “ready,” they’ve already shipped three iterations. The SE process runs at quarterly cadence. The dev process runs at weekly cadence. These timescales are structurally incompatible.

This is the “implementation is as fast as we can think” problem. When development velocity outpaces systems engineering coordination, the SE function gets pushed to the margins. It becomes a documentation exercise rather than a design authority. And organizations that tolerate this drift end up with systems that work at the component level but fail at the integration level - exactly the failure mode that systems engineering was created to prevent.

The false binary

The conventional framing of this divide is “waterfall SE” versus “agile dev.” This framing is wrong, and it’s making things worse.

Systems engineering isn’t inherently waterfall. The Vee model, spiral development, and iterative architecture refinement have been part of SE practice for decades. And agile development isn’t inherently undisciplined - done well, it produces rigorously tested, well-documented software through tight feedback loops.

The real divide isn’t about process philosophy. It’s about what each discipline considers a first-class artifact. For SEs, the model is the artifact. For developers, the code is the artifact. Both groups are rigorous within their own paradigm. The breakdown happens at the boundary where one paradigm’s output becomes the other paradigm’s input.

Labeling one side “waterfall” and the other “agile” gives both groups permission to dismiss each other. SEs dismiss developers as cowboy coders who don’t think about the system. Developers dismiss SEs as overhead producers who don’t ship anything. Neither characterization is fair, and the mutual dismissal prevents the structural integration that both sides need.

SysML v2 as a potential bridge

SysML v2 introduces something that might actually matter here: a textual syntax called KerML/SysML that makes system models look more like code. Instead of XML serialization locked inside a proprietary tool, SysML v2 models can be expressed as text files. Text files that can be version-controlled. Diffed. Reviewed in pull requests. Integrated into CI pipelines.

This is a bigger deal than the modeling community realizes. The reason developers adopted Git, code review, and CI/CD isn’t because those tools are inherently superior. It’s because those tools create a shared feedback loop around a shared artifact. Everyone can see the change, comment on it, test it, and verify it. The artifact is the communication medium.

If SysML v2 models are text, they can participate in the same feedback loops. An architecture change can be a pull request. A model update can trigger automated consistency checks. A requirement modification can be diffed against the previous version. The SE artifact starts to behave like a developer artifact - not because it compiles, but because it participates in the same collaborative infrastructure.

This won’t happen automatically. Text-based models are necessary but not sufficient. The tooling needs to make it natural. The workflows need to be designed. The cultural expectations need to evolve. But for the first time, the technical substrate exists for SEs and developers to work on artifacts that live in the same ecosystem.

What convergence actually looks like

The end state isn’t SEs learning to code or developers learning SysML. It’s shared artifacts that both disciplines can work with natively.

Here’s what that looks like in practice:

Models that generate code scaffolds. An architecture model doesn’t just describe interfaces - it generates the API contracts, the data types, the test harnesses. The developer starts with a scaffold that already embodies the architecture decisions. Drift becomes detectable because the scaffold has a traceable origin.

Requirements that become acceptance tests. A well-formed requirement isn’t just a sentence in a document - it’s a specification that maps to a verifiable test. When the SE writes “the system shall respond to health queries within 200ms,” that requirement generates a performance test that runs in CI. The requirement isn’t verified by inspection. It’s verified by execution.

Architecture decisions that are diffable. When an SE changes an interface, the change is visible in the same version control system the developers use. The developer sees the diff, understands the impact, and updates their implementation - or pushes back with evidence. The conversation happens around the artifact, not in a meeting about the artifact.

Traceability that’s automatic. Instead of manually maintaining allocation matrices, the relationships between requirements, architecture elements, and implementation artifacts are maintained by the tooling. When a requirement changes, the downstream impact is calculated. When implementation diverges from architecture, the deviation is flagged.

The common language problem

Both disciplines need shared artifacts, not translated ones. The current model - where SEs produce architecture documents that developers reinterpret - is a translation exercise. And translation is inherently lossy. Every time intent passes through a human translator, context is stripped away, assumptions are introduced, and fidelity degrades.

The solution isn’t better translation. It’s eliminating the need for translation. Both groups need to work on artifacts that are natively meaningful in both paradigms. A system architecture that is also a code scaffold. A requirement that is also a test specification. An interface definition that is also an API contract.

This is technically possible today. SysML v2’s textual syntax, modern code generation, and CI/CD integration create the substrate for it. What’s missing is the tooling that makes it natural and the organizational will to change the workflows.

The two tribes don’t need to merge. They need a shared territory - a set of artifacts and practices that both can claim as their own. Without that, every system of sufficient complexity will continue to suffer the same failure mode: a beautiful architecture that nobody follows, and a working implementation that nobody designed.

This is Part 5 of “The MBSE Reckoning,” a 10-part series from Luvian on the state and future of Model-Based Systems Engineering.

Previous: Part 4 - The Maturity Myth
Next: Part 6 - The Priesthood Problem

Subscribe to our newsletter to get each article as it publishes.