DEV Community: Lonnie McRorey

Agency Theory Economics as engineering operating evidence

Lonnie McRorey — Tue, 11 Aug 2026 14:30:39 +0000

Agency theory matters because people and systems do what incentives make easy.

If the buyer wants quality but the delivery model rewards hours, bodies, or volume, the math is already broken.

TeamStation uses the page to explain why incentives have to be engineered into the operating model. For CTOs and CIOs, the practical question is whether the team is aligned to outcomes, evidence, and ownership, or just activity.

LATAM teams can be a strong operating layer when incentives are clean, because the model is built around delivery behavior, not vendor theater.

https://engineering.teamstation.dev/decisions/agency-theory-economics/

EngineeringEconomics #EngineeringLeadership #AIEngineering #EngineeringTelemetry #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/decisions/agency-theory-economics/

Mutation Testing for AI-Generated Code

Lonnie McRorey — Mon, 10 Aug 2026 15:31:20 +0000

A green build can still be blind.

Line coverage tells us which code ran. Mutation testing changes the code on purpose, then asks whether the tests catch the wrong behavior. Flip >= to >, remove a guard, or break a fallback. If the suite fails, the mutant is killed. If it stays green, the mutant survived and the evidence is weak.

The operating math is simple: MS = K / (T - E). K is killed mutants, T is total mutants, and E is the equivalent mutants removed from the useful count. The score is not magic, but it forces the test suite to fight a controlled defect instead of collecting another green badge.

That matters more now bc AI can generate the function and the test from the same assumption. Clean code plus clean tests can still share the same mistake. We need an adversary inside the harness, then a human who owns the release.

For distributed LATAM teams, the evidence also travels well. The report shows which behavior changed, whether the suite caught it, who reviewed the survivor, and what exception was accepted. That is stronger than saying the tests seem good across an async handoff.

I built the field guide to connect TeamStation's mutation-score doctrine with AI-generated code, QA work samples, CI telemetry, and human release control:

https://teamstation.dev/research/articles/mutation-testing-ai-generated-code

MutationTesting #AIEngineering #SoftwareQuality #EngineeringTelemetry #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://teamstation.dev/research/articles/mutation-testing-ai-generated-code

Cognitive Fidelity as engineering operating evidence

Lonnie McRorey — Sun, 09 Aug 2026 16:04:07 +0000

Production errors often start as map errors: the engineer holds one picture of the system while the real dependencies, limits, and failure paths live somewhere else.

Here is the simple test. Move one constraint, make the database read-only, cut the latency budget, or remove an integration, then ask what changes next and why.

If the reasoning survives under pressure, the engineer probably understands the mechanism; if the answer collapses, the first response may have been pattern recall dressed up as judgment.

Cognitive fidelity is the match between the mental map and the live system state, and TeamStation maps that operating evidence across architectural instinct, problem-solving agility, learning orientation, and collaborative mindset. Inside Axiom Cortex and our Distributed Engineering Operating System, those signals matter more than a polished answer bc production keeps changing the shape of the problem.

For distributed LATAM AI teams, async work gives a bad assumption more time to travel, so we test the map before that assumption becomes code, review debt, or an incident.

https://engineering.teamstation.dev/quality/cognitive-fidelity/

CognitiveFidelity #EngineerVetting #AIEngineering #AxiomCortex #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/quality/cognitive-fidelity/

Semantic Decision Kinetics as engineering operating evidence

Lonnie McRorey — Sat, 08 Aug 2026 15:19:14 +0000

Meaning has distance, and a clean answer can still sit far away from the truth of the system.

Picture two piles: one is what the engineer said, and the other is the correct explanation of the database lock, model pipeline, or production failure. Optimal transport asks how much work it takes to move the first pile into the second; different words with the same meaning need little movement, while a polished wrong answer needs a lot.

That creates a better vetting question: how far is the reasoning from the real mechanism, and how sure should the model be? Thin evidence must mean low confidence and a wider human review gate because clean output is not proof.

TeamStation's Semantic Decision Kinetics source connects that math inside the Axiom Cortex evaluation path: Wasserstein distance for semantic alignment, nonparametric latent measurement for uneven skill, and calibration checks for model confidence. The method sits inside the evidence layer of our Distributed Engineering Operating System, where a score has to carry a reason and a human owner.

For distributed LATAM AI teams, English style can change while technical meaning stays stable, so meaning, reasoning, and confidence need separate evidence before an engineer touches production.

https://engineering.teamstation.dev/decisions/semantic-decision-kinetics/

AIEvaluation #EngineerVetting #DecisionScience #AxiomCortex #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/decisions/semantic-decision-kinetics/

Vector Space Axioms as engineering operating evidence

Lonnie McRorey — Fri, 07 Aug 2026 15:19:14 +0000

Keyword matching can get two engineer decisions wrong in opposite directions.

A profile can say "no Java experience" and still trigger a Java match, while another engineer can show deep Spring Boot work, leave out the word Java, and get missed. Same filter, two bad reads.

Vector Space Axioms shows the math under TeamStation's engineer-vetting operating system. Skills and concepts become coordinates, related ideas sit close even when the words change, and every interview answer stays in its own evidence unit before the final synthesis.

That matters when US teams vet AI engineers across LATAM bc a model can scale a weak match as fast as a good one. Semantic distance catches context, per-answer evidence limits halo effects, and human review still owns the call.

The source maps the full path from keyword failure to calibrated evidence:

https://engineering.teamstation.dev/decisions/vector-space-axioms/

AIEngineering #EngineerVetting #EngineeringTelemetry #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/decisions/vector-space-axioms/

Decisions as engineering operating evidence

Lonnie McRorey — Thu, 06 Aug 2026 17:47:22 +0000

A polished resume used to cost real time. Now AI can make one in minutes, so two engineers can read as identical on paper while the thinking underneath is miles apart. Same wrapper, very different engine.

That changes the hiring problem. Keywords are labels, not proof, bc Java AND AWS can find words but it cannot show how a person breaks down a hard system, changes direction when an idea fails, or explains a decision under pressure.

Inside TeamStation's distributed engineering operating system, we treat that gap like signal processing. The Decisions doctrine lays out the public model: isolate small evaluation units, map meaning in vector space, measure the traits hidden under the words, then choose the next question by how much uncertainty it can remove. In basic English, stop rewarding the best wrapper and test the thinking inside it.

For distributed AI engineering teams in LATAM, geography comes after the signal. The full Decisions pillar shows the math and evaluation logic behind that order:

https://engineering.teamstation.dev/decisions/

AIEngineering #DecisionScience #EngineeringLeadership #TalentIntelligence #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/decisions/

WIP Regulation as engineering operating evidence

Lonnie McRorey — Wed, 05 Aug 2026 15:14:22 +0000

Three open tickets looks like flexibility, but in the math, it is inventory sitting inside the system.

Here's what I'm seeing: AI lets a team start work at breakneck speed, but arrival rate is not throughput. Little's Law is blunt, L = lambda W. Add more work to the system without increasing the finish rate and time in the system grows. Thats why TeamStation's WIP regulation uses a hard Rule of Two, not a polite guideline.

One engineer carries no more than two items across progress, review, or staging. If both are blocked, the engineer swarms the blockage by reviewing code, fixing the build, or clarifying the spec instead of pulling a third ticket and burying congestion under fresh output.

The other control is just as important: done means deployed, and a ticket closes only after telemetry shows the feature active in production. Now ownership has a signal trail instead of an opinion.

The doctrine page gives the exact operating constraints: Rule of Two, 24 hour integration, the deployment clause, and async channel policy.

https://engineering.teamstation.dev/work/wip-regulation/

FlowMetrics #EngineeringTelemetry #AIEngineering #SoftwareDelivery #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/work/wip-regulation/

Cost Of Delay Economics as engineering operating evidence

Lonnie McRorey — Tue, 04 Aug 2026 15:04:17 +0000

Cost of delay is where engineering stops being a task list and becomes business math.

A late decision, a blocked review, or a weak dependency is not just inconvenience. It is lost option value, lost learning, and sometimes lost revenue.

TeamStation uses the page to connect delivery behavior to economic consequence. For CTOs and CIOs, the page matters because AI speed means little if delay keeps hiding inside decisions and handoffs.

Distributed LATAM delivery benefits when delay is visible, because distance stops being an excuse and becomes a measurable operating variable.

https://engineering.teamstation.dev/work/cost-of-delay-economics/

EngineeringEconomics #EngineeringTelemetry #AIEngineering #SoftwareDelivery #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/work/cost-of-delay-economics/

Queueing Kinetics as engineering operating evidence

Lonnie McRorey — Mon, 03 Aug 2026 15:13:40 +0000

Three dependencies can turn a small delay into a coin flip, and the math gets ugly fast.

Say an engineer needs an API spec, a design review, and a green CI run. If each one has a 20% chance of being late, the probability of that engineer being blocked is 48.8%, not 20%. That is almost half the probability surface before anyone writes code.

Queue math exposes the part ppl miss: software work is rough too. A two hour fix sits beside a two week rewrite, so the average lies and high variance has to land somewhere, either as inventory in the queue or as delay in delivery. Then AI adds output faster than the bottleneck can clear it.

The Queueing Kinetics doctrine lays out the variance multiplier, dependency blocking, and the sync penalty behind that behavior. I use those mechanics inside TeamStation's engineering operating system to slice work into smaller chunks, reduce live dependencies, replace meetings with written contracts, and expose the queue before adding more agents.

For distributed LATAM teams, overlap still matters, but clean contracts matter more. Miss one answer window and a tiny delay can round up to a full day, so we design the workflow around that physics and keep ownership visible in the telemetry.

https://engineering.teamstation.dev/work/queueing-kinetics/

QueueingTheory #EngineeringTelemetry #AIEngineering #SoftwareDelivery #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/work/queueing-kinetics/

Work as engineering operating evidence

Lonnie McRorey — Sun, 02 Aug 2026 15:16:25 +0000

A busy engineering team can still be a traffic jam. More tickets enter, AI creates more code, review stays finite, and wait time starts eating the delivery plan.

Queue math explains the mess. When arrival rate gets close to available capacity, small surprises create long delays. Old branches become inventory, context decays, and ppl start new work because finishing work is harder.

Our Work doctrine puts queueing kinetics, Little's Law, code inventory, cost of delay, and WIP control on one map. I picked the pillar today bc it shows how those parts connect before we go deeper into each one.

https://engineering.teamstation.dev/work/

Distributed LATAM delivery is where the model gets tested. Clean limits, visible queues, daily integration, and deployed proof keep async work from turning into silent backlog.

SoftwareDelivery #EngineeringTelemetry #AIEngineering #EngineeringLeadership #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/work/

Mathematical Axioms as engineering operating evidence

Lonnie McRorey — Sat, 01 Aug 2026 15:07:36 +0000

One AI node can appear cheaper on its own and still make the whole engineering chain more expensive.

Here is the math. When downstream automation makes success more likely even if an upstream person stops pushing, that person's effort becomes harder to see. The model calls that safety net zeta. As zeta moves closer to full success probability, the cost of keeping effort aligned rises fast.

The local saving is only one term. TeamStation's Mathematical Axioms page also counts direct incentive cost and the indirect cost pushed onto every upstream owner. That is why AI placement is a team design decision, not a license count. The definitions, equations, and proof structure are here:

https://engineering.teamstation.dev/teams/mathematical-axioms/

In distributed LATAM delivery, the same rule follows work across architecture, build, QA, and deployment. Automation has to increase useful output without making ownership blurry.

AIEngineering #EngineeringGovernance #EngineeringTelemetry #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/teams/mathematical-axioms/

Agentic Development Workflows as engineering operating evidence

Lonnie McRorey — Fri, 31 Jul 2026 15:13:47 +0000

So Hey, an agent with repo access is not a workflow; its a fast pair of hands inside a machine, and somebody still has to own the machine.

I keep coming back to five checks: the intent entering the node, the tools the agent can touch, the human reviewing the change, the memory allowed to survive, and the telemetry returning after release. Thats where the data lives, and IMO, thats where the math of control either holds or falls apart.

A clean demo can hide a dirty loop bc more prompts do not repair missing ownership; we need human nodes, bounded agent loops, explicit review, and evidence that travels back into architecture as proof, not vibes.

TeamStation mapped the operating system here through Product, Architecture, Engineering, Quality, Deployment, and Observability, all connected as one topology where AI assists inside the workflow without pretending to own it.

In LATAM delivery, we put the workflow on digital rails before speed enters the room, bc distributed teams expose weak context fast and the signal trail has to survive real handoffs, real review, and production pressure.

https://engineering.teamstation.dev/teams/agentic-development-workflows/

AgenticAI #AIEngineering #EngineeringTelemetry #SoftwareDelivery #TeamStationAI

Related TeamStation sources:

GitHub topic map:

Source asset:
https://engineering.teamstation.dev/teams/agentic-development-workflows/