bparanj

Transitive reasoning is a logic pattern.

Example:

A depends on B.
B depends on C.
Therefore, A indirectly depends on C.

bparanj

Stave fits very well.

The article’s core point is:

AI is only valuable if it reduces long-term maintenance cost, not just short-term output speed.

James Shore argues that every new line of code creates future maintenance work, and AI coding agents can make this worse if they increase output without reducing the cost of understanding, fixing, and changing that output. He says the math only works when AI reduces maintenance cost in proportion to the productivity gain. ([James Shore][1])

Stave’s fit

bparanj

Position Stave as the tool for security people who want to lead AI, not be replaced by it.

The message should be:

AI can generate findings. Stave helps humans define what must never be allowed.

That puts Stave above “AI scanner” positioning.

Core positioning

bparanj

The article

channels/devto/agents-via-code-execution-not-shared-state.md — "Thoughtworks Just Moved LangGraph Out of Adopt. Our Security Tool Was Already Built for What Comes Next."

It makes the positioning argument you spotted: the 4-agent workflow proves Stave already embodies the pattern the Radar now favors — simple agents communicating through code execution, each scoped to the state it needs — without being an agent framework.

The spine of the argument:

1. The Radar's two real claims — communicate through code execution (not a shared blackboard); each agent gets only the state it needs (not a global object).

bparanj

./stave apply   --controls controls   --observations mytests   --now 2026-01-15T00:00:00Z   --allow-unknown-input
Done:    apply controls against observations (1.931s)
level=WARN msg="command failed" error="execute evaluation: failed to load observations: load snapshot mytests/observations.json: schema validation failed: security assessment failed: 3 errors, 0 warnings | First Finding: at '': additional properties 'snapshots' not allowed (mytests/observations.json: /)" exit_code=2
[ERR] Input validation failed (INVALID_INPUT)
  Message: execute evaluation: failed to load observations: load snapshot mytests/observations.json: schema validation failed: security assessment failed: 3 errors, 0 warnings | First Finding: at '': additional properties 'snapshots' not allowed (mytests/observations.json: /)
Next: stave validate --controls ./controls --observations ./observations
More info: https://github.com/sufield/stave/blob/main/docs/start-here.md#validate+schema+validation+failed
  Fix:     Try `stave validate --co

bparanj

https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access

bparanj

Here's a hot take: a lot of the vulnerability disclosure around AI models is inflated.

When you dig into the papers and the hearsay, a huge portion of the findings are source-assisted. And when you look at the bugs themselves, a lot of them are not exploitable. Or they're in low-tier targets. Or they're in projects that, as I said on stream, "if I sneezed at that project it would have fallen over."

I'm not picking on Anthropic specifically. This is a pattern across the agentic pen testing space broadly.

Before you make investment decisions based on these announcements, dig into the studies. Look at what type of vulnerabilities they're finding. Look at the targets. Look at whether the bugs have been validated as genuinely exploitable.

Critical mindset here is table stakes.

bparanj

Organize the 30 HackerOne reports by **attack stage**.
That gives you two useful outputs:

1. **End-to-end fixtures** for Stave
2. **Article series** that explains real risk patterns clearly

Use this pipeline:

```text
report → incident pattern → attack stage → invariant → fixture → article

bparanj

```go
obs, err := stave.LoadObservation(path)
facts, err := stave.ExtractFacts(obs)
```

Your intent is:

```text
Use Stave as a library.
Bring your own solver.

bparanj

Use this prompt for Claude Code:

You are working on a Go-based security product prototype that will be used to measure real demand before the main product is fully ready.

Goal

Build a small, usable product in several iterations. The product must be easy for early adopters to run in their own environment, especially in CI/CD and AWS environments. The purpose is to learn from real usage and feedback in the same market as Stave.

Core strategy