Building in public, day 3:
Piperoom just landed its first enterprise customer.
On X:
Day 1: 0 → 23 followers
Day 2: 23 → 68
Day 3: 68 → 85
Lesson of the day: I sent ~35 replies in 2 hours to grow faster. X throttled me. My posts went from 140 views to 3.
What worked instead: real conversations, and one dumb joke that got 402 views.
What's the advice you ignored and regretted?
Build in public update: Piperoom, the AI incident room I'm building for data pipelines, just landed its first enterprise customer. Still pre-launch.
Founders who've been here: what do you wish you'd set up before customer #1 went live?
Claude Code tool of the day #1: claude-code-hooks by @karanb192
22 ready-made hooks you install as plugins. The six guards worth adding tonight:
protect-tests: blocks deleting or skipping tests to get a fake green
config-guard: stops the agent editing its own hooks and rules
protect-secrets: denies reads of .env and SSH keys
git-safety: no pushes to main, no branch deletes
block-dangerous-commands: rm -rf, fork bombs, curl | sh
subagent-spawn-cap: a budget on how many subagents a session can spawn
/plugin marketplace add karanb192/claude-code-hooks
Which guard would you never run without?
https://t.co/dQ6tMkSZSY
@davidofug And to answer your question properly: yes, I use it for handoffs between agent sessions. The new session acts only on what's DECIDED and checks with me before touching anything PROPOSED.
@davidofug Start small so you can tell: one shared file, two headings, and every stage acts only on DECIDED. Run the same job a few times and check whether the publisher's output still matches what the researcher was asked for.
@mikeschreibs Dating each rule is smart. The "why it exists" note matters even more: it's what lets you delete a rule later without being scared of what breaks.
A new paper tested what happens when your CLAUDE.md disagrees with your code.
The file said "use print() for progress messages." The codebase used logging.
40 projects, 320 runs, Claude Code and Codex CLI.
90% of the time the agents followed the stale file.
Claude Code noticed the conflict in 79 of 80 runs. Noticed it, then followed the file anyway.
Codex went further: in 20 runs it rewrote the existing code to match the file. Tests failed in 17 of them.
The fix is one sentence in ~/.claude/CLAUDE.md:
"If the repo's docs and its existing code disagree, follow the conventions used in the existing code, and list each inconsistency you find in your final reply."
With it: agents followed the code 91% of the time, rewrites stopped, test pass rate went from 89% to 100%.
Your instruction file is a snapshot. Your code is the truth. Tell the agent which one wins.
https://t.co/ClWeTO6i1O
@andreykuzmin342 Both, because they catch different things. A schema registry diff tells you something changed before data moves. Row counts and null rates on the sink tell you whether it actually hurt. One is the smoke alarm, the other tells you what burned.
@JackEllis Two hours is a UX test, not an agent test. Cursor is built for the first two hours, when you're watching every diff. Claude Code is built for the next eight, the runs you check on later. Give both the same full-day task and the gap looks very different.
@ByteEcosystem This framing is backwards. Anthropic gave the agents that job on purpose: a red-team test to find what a training-data monitor misses, so those examples can train a better monitor. That's not agents going rogue, it's the safety process working as designed.
@TekonBurns Unpopular take: resets and account switching are the more useful update. Most devs don't hit the model's ceiling, they hit the usage limit by Wednesday. A smarter model you can only run until lunch isn't much of an upgrade.
Worth saying out loud before anyone plugs this into Claude Code: a third-party key means a third party sees every prompt. In a coding agent, that's your repo, your diffs, and whatever .env got pulled into context.
Fine for side projects. Think twice before pointing it at your day job.
Neat project, but "verifiable reasoning" is doing a lot of work here. A proof shows the answer follows from the graph, not that the graph is right. Feed it a stale ontology and you get a perfectly verified wrong answer, in 0.04s.
Checking fast was never the hard part. Keeping the graph true is.
@sachinkoli One approval screen for every subagent is a nice touch. Five popups is how people end up clicking yes to everything. And "models usually stay in scope" is exactly the part I'd still back with a hard wall, for the one day it doesn't.
The lesson travels well beyond AI safety: a check that judges one item at a time can't see harm that only exists in the total. Every example here looked like beekeeping or wrestling advice.
Same blind spot in code review, fraud checks and data quality. @marcobuilds7 made the code review version of this point this morning.
New Anthropic research: Automating subtle emergent misalignment research.
Red-teaming is a vital part of model safety testing, but it’s also limited by researchers’ time. To see if we could automate it, we set thousands of Claude agents the task of evading a training data monitor.
These agents developed training data that looked harmless to monitors (like a veteran wrestler mentoring a newcomer, or a Q&A about professional beekeeping), but that in fact taught misaligned behavior.
Examples like these can be used to directly improve future training data monitors. This research is only a first step, but it suggests that future red-teaming efforts could improve much further, using better models and more compute.
Read the full post on the Alignment Science Blog: https://t.co/24Gs1oSw7Q
For small startup teams using AI coding agents:
Writing code is no longer the bottleneck. Reviewing it is.
More agents doesn't mean more shipped. It means a longer queue of diffs nobody has read.
Size your agent count to what one person can actually review in a day, and check what's still unreviewed before you log off.