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

bparanj

This is a perfect candidate for a Go "Golden File" test runner. The current shell script is a "Swiss Army Knife" of dependencies (jq, rg, sed, grep, sha256sum, find) that makes your CI environment fragile.

In Go, you can use the os/exec package combined with testify/assert or simple comparison logic to create a much more robust runner.

The "Go E2E Runner" Refactor

Create a file at internal/app/e2e_test.go. This approach uses Go's subtests to run every directory in testdata/e2e as an independent test case.

package app_test

bparanj

Yes, converting this to a Go test or a Go-based runner is highly recommended. Using shell scripts to "move folders around" to filter tests is brittle and can leave your testdata in a corrupted state if the script crashes.

In Go, the idiomatic way to solve this is using Subtests and Filtering via go test -run.

The "Go Way" Refactor

Instead of a shell script that moves files, create a Go test file (e.g., internal/core/enginetest/e2e_test.go) that dynamically discovers and filters the test cases.

package enginetest

bparanj

To have Claude Code apply the "Designing Errors out of Existence" philosophy to your Go codebase, you need a prompt that distinguishes between Critical Failures (which should remain errors) and State-based No-ops (which should be designed away).

The Audit & Refactor Prompt

"Audit the Go source code to identify functions that return an error but could be refactored to 'design the error out of existence' based on John Ousterhout’s philosophy. Please generate a report and suggest refactors for the following patterns:

1. Idempotent No-ops: Find functions where an error is returned for a state that already matches the desired outcome (e.g., Delete failing because a file is already gone, or Close failing on an already closed resource). If the post-condition is met, the function should succeed silently.
2. Empty-Set Safety: Find functions that return an error when a slice or map is empty. Refactor these to treat an empty input as a valid 'no-work-to-do' state rather than a

bparanj

This is a high-quality audit. A 2.1 average complexity score is healthy for a security tool, but your "Score 5" items are classic "Technical Debt" in CLI design.

Here is a 3-stage plan to refactor these commands to reveal their intent and simplify the API.

---

Phase 1: High-Impact Splits (The "Swiss Army Knives")

Goal: Decompose the "Score 5" commands into focused sub-commands.

1. Refactor stave snapshot hygiene

bparanj

Evaluate your CLI surface area against the "Simple and Focused" principle, you can use the following prompt. This instructs Claude to look for Flag Bloat, Command Overloading, and Inter-dependency Confusion.

The Evaluation Prompt

"Analyze all Cobra/CLI commands in this project to evaluate their 'Functional Focus' and 'Flag Complexity.' Please provide a report in a Markdown table with the following columns:

Command Name: The full subcommand path (e.g., stave evaluate).

Primary Intent: A one-sentence description of the single job this command performs.

bparanj

Creating a Mock Server for OpenAPI in Go

Prerequisites

• Go installed on your system
• Your OpenAPI specification file (openapi.yaml)

What We'll Use

• github.com/getkin/kin-openapi for parsing OpenAPI specs
• github.com/labstack/echo/v4 as a lightweight web framework
• Standard Go libraries for file handling and HTTP operations