Designing Software With Tension In Mind

How to use good tension and bad tension as first class signals in your stack

Most engineering teams already monitor latency, error rates, CPU, cache hit ratios, P95 response time, deployment frequency.

Almost nobody monitors tension.

That sounds abstract, so let me define it in practical terms.

Tension is what happens when multiple constraints pull your system in different directions and it still has to produce a single outcome.

In this article I will treat tension as a real thing you can design around.

We will look at three layers you already work with every day

1. Code and architecture
2. AI assisted features and RAG pipelines
3. Teams and product roadmaps

For each layer I will show

• what good tension looks like
• what bad tension looks like
• how to start instrumenting tension without any new framework

Under the hood this is part of a bigger project I call the Tension Universe.
For dev.to the goal is simpler. I just want to give you a rigorous lens with more examples than you usually see in a single post.

---

1. Code and architecture: where good tension lives

Forget AI for a moment.
Think about a reasonably sized codebase with real users.

You are always balancing

• readability vs performance
• abstraction vs duplication
• stability vs speed of change

That balance is tension.

1.1 Good tension in code

Here are a few concrete examples of good tension at the code level.

Example 1: a consciously thin abstraction

You extract a small interface between your application and a third party payment provider.

• It is not generic enough to handle every future provider
• It is not fully hard coded to the current one
• It exposes just enough surface for later evolution

You can feel the tension

• part of your brain wants to over engineer
• part of your brain wants to ship now

You decide to stop in the middle.
That is good tension. The code is stretched, but in a controlled way.

Example 2: a migration with honest boundary

You are moving from one database to another.

Instead of doing a full big bang cutover, you create a clear seam

• legacy write path into the old system
• new write path gradually switched module by module
• a reconciliation job that compares both for a subset of traffic

For a while you have two realities.
Good tension means you keep this visible

• you track divergence
• you have metrics for dual writes
• you know exactly where the migration is incomplete

This is different from the bad version

“We technically have both databases in production, but nobody really knows which service uses which”.

In the good case, tension drives learning.
In the bad case, tension drives incidents.

1.2 Bad tension in architecture

Bad architectural tension often shows up in places that feel “too small to worry about” until they are not.

Example 3: the silent god service

A service is created for some internal tooling three years ago.

Over time, people add more and more “just one more endpoint” use cases.

• It now touches auth, billing, notifications, and analytics
• It has multiple consumers that no longer have active owners
• It sits in the middle of critical paths but has no clear SLOs

From a tension perspective, this service is overloaded.
It carries cross cutting concerns that should be separated.

The bad part is not that it does many things.
The bad part is that the team no longer knows where the tension sits inside the service.

Example 4: feature flags that never die

You build a feature behind a flag.

• The flag controls a complex code path
• You roll it out to 100 percent of users
• You move on to the next thing

The flag remains, half wired, half forgotten.
Soon you have a landscape of feature flags that nobody fully understands.

This creates a hidden tension field inside the code

• risk of accidentally re enabling old paths
• cognitive load when debugging
• surprise interactions between flags in staging and production

There is no single line of code you can blame.
The system as a whole is under bad tension.

How to begin measuring code tension

You can start with simple indicators

• count of modules with unclear ownership
• number of feature flags that are always on but never cleaned up
• graph of services that touch more than N critical domains

These are not perfect, but they turn tension from a vague feeling into something you can at least talk about explicitly.

---

2. AI and RAG systems: tension as a missing metric

Now bring this lens into AI assisted features.

Most teams monitor

• token usage
• request latency
• raw accuracy on some eval set

Very few ask

In which situations is the system under good tension
and in which situations is it under bad tension

2.1 Good tension in AI systems

Good tension in AI looks like this.

Example 5: RAG with graceful uncertainty

A user asks

“What are the risks of using this new experimental API in a regulated environment”

Your retrieval system surfaces partial documentation and some internal policy memos.
The model does not find a complete answer.

Good tension means the system

• explicitly says which parts of the question are covered by the docs
• highlights gaps where policy is unclear
• suggests talking to legal for those parts
• logs this query as a high tension case for later review

The system is stretched but does not pretend otherwise.

Example 6: multi step reasoning with exposed conflict

You run a chain of thought or tree of thought style process.

The model proposes three different reasoning paths.
They conflict on an important detail.

Good tension means the system

• shows the conflicting paths
• marks the disagreement region
• uses that as a cue to request more input or do more retrieval

In other words, it treats internal disagreement as signal, not as an embarrassment to hide.

2.2 Bad tension, or why hallucinations feel so slippery

Bad tension in AI is more familiar.

Example 7: hallucinated glue

The model receives context fragments that almost answer the question.

Instead of saying “I do not have enough”, it uses

• prior training on web patterns
• your prompt’s “be helpful” pressure
• the desire to produce something that looks complete

and it hallucinates a bridge between the fragments.

To the user this looks like competence.
Inside the system this is bad tension spanning a conceptual gap.

Example 8: alignment by tone only

You add a safety layer around the model.

It learns to say

• “I understand your concern”
• “I cannot provide that request because of policy”

but under the surface nothing about its reasoning geometry has changed.

It is basically a rhetorical patch on top of the same tension field.

Users notice this because they feel the mismatch between tone and substance.

The bad tension here is between

• the system’s apparent calm
• the unresolved conflict between user intent, policy, and capabilities

How to log AI tension signals without fancy tools

You can start with steps that look almost trivial

• for a sample of production queries, generate multiple answers and log how often they disagree on key facts
• tag queries where retrieval returns low coverage docs, independent of embedding similarity
• prompt the model to list “missing pieces” before answering, and log that list size

These are crude tension indicators.
They are still better than pretending that a single accuracy number tells you everything.

---

3. Teams and roadmaps: organizational tension as a risk surface

So far we stayed close to technical artifacts.
Now zoom out to the people building them.

Every team operates inside overlapping tension fields

• business constraints
• personal lives
• technical debt
• reputation and career goals

Ignoring that does not make it go away.

3.1 Good team tension

Here are examples where organizational tension is doing useful work.

Example 9: roadmap tension made explicit

A team has to choose between

• a high risk new feature that could unlock a lot of value
• a series of small improvements that users keep asking for

Leadership writes a simple document

• listing the tradeoffs
• stating the current bet openly
• committing to revisit the decision at a precise date with specific metrics

People may still disagree, but the tension is at least mapped.
Team members can say “I think this is the wrong choice, but I understand the logic and the timebox”.

Example 10: capacity limits documented

Instead of pretending that the team can do everything, you document capacity limits.

• maximum number of major projects in progress
• maximum number of on call rotations per engineer per quarter
• explicit rules for saying no

These constraints create good tension

• they force you to rank priorities
• they prevent quiet overcommitment that later explodes as burnout

The stretch exists, but the boundaries are visible.

3.2 Bad team tension

Bad organizational tension is usually quiet and long running.

Example 11: unowned critical responsibility

A cross cutting responsibility exists

• security reviews
• data privacy compliance
• incident communication

Everyone assumes someone else is covering it.
Nobody has it in their explicit job description or performance review.

This creates a chronic tension field that only becomes visible during a crisis.

Example 12: mismatch between public story and internal data

Publicly the company says

• “we are default alive”
• “our metrics are strong”
• “we are on a clear path to profitability”

Internally the dashboards show something different

• growth is flattening
• the main product is supported by a handful of people
• key metrics rely on one or two big customers that could churn

The bad tension here is not that reality is hard.
It is that the gap between story and data is denied.

People feel it in their nervous systems long before it appears in official slides.

Simple organizational tension checks

You can add a few tension questions into your regular rhythm

• In the last quarter, where did we experience good tension
  places where stretch led to visible learning or capability gain

• Where did we experience bad tension
  places where people were quietly overloaded, or where narratives drifted away from metrics

Write these down.
Treat them as seriously as error budgets.

---

4. Why I talk about a “Tension Universe”

So far I have treated each set of examples separately.
Code, AI, teams.

In practice they interact.

• Architectural decisions shape AI tension
• AI tension shapes user incidents
• User incidents shape team and business tension

What I call the Tension Universe is basically an attempt to write all of this in one coherent language.

Concretely

• I collected 131 hard problems across domains
• For each one, I tried to encode where good tension and bad tension live in the structure of the problem
• I wrapped this in an open source text pack (WFGY 3.0 · Singularity Demo) that modern LLMs can read and reason about

The idea is not that this is final or complete.
It is closer to a candidate operating system for thinking about tension instead of just reading CPU graphs.

For dev.to readers, the important part is the mindset

You can treat tension as a design object, not just a side effect.

---

5. How to start tomorrow with zero new infrastructure

If you want to experiment with this lens, here is a minimal checklist.

5.1 For your codebase

• Make a list of 3 modules or services that everyone is slightly afraid to touch

• For each, answer

  • what kinds of responsibility are lumped together here
  • which part of that tension is productive
  • which part is pure risk

• Turn at least one bad tension into good tension
  
  for example by adding tests and clear ownership, or by splitting a responsibility out

5.2 For your AI features

• Pick a real production flow that uses LLMs or RAG

• Sample 50 queries

  • mark which ones show good tension behaviour
  • mark which ones show bad tension behaviour

• Add a simple log field

  • “tension_state” with values like “calm”, “edge”, “overstretched”
  • even if you label it manually at first

5.3 For your team

• In your next retro, ask explicitly

  • “Where did we feel stretched in a good way this sprint”
  • “Where did we feel stretched in a way that just made us worse”

• Capture one concrete example in each category

• Commit one small change that reduces bad tension without killing good tension

None of this requires new frameworks or libraries.
It only requires you to admit that tension is as real as latency.

---

Closing

We already build and operate systems under tension

• complex microservice meshes
• brittle RAG stacks
• distributed teams shipping into unstable markets

Most of our tools look at side effects
errors, throughput, individual satisfaction scores.

This article argued that we need to treat tension itself as a first class signal

• distinguish good tension from bad tension
• locate tension in code, AI and organizations
• gradually build a shared language for talking about it

If you start doing that, even in a very homemade way, you will notice something.

A lot of “random” incidents and “sudden” burnouts are not random or sudden at all.
They are the visible surface of long running bad tension fields.

The sooner we admit that and begin to map them,
the more room we have to keep the good tension that builds systems,
and to drain the bad tension that quietly destroys them.