Tom Kirkpatrick

@mrfelton

Aug 20

Tom Kirkpatrick

@mrfelton

Jul 27

We are shifting from using AI to write code, to building software factories that build features for us.

Here is a look at how we have been adapting our workflows to make agents a first-class part of the Strike engineering team. strike.me/blog/strike-so…

Tom Kirkpatrick

@mrfelton

Aug 4

Rob Hamilton

@Rob1Ham

Aug 4

Bitcoin Red Team Update:

We have been working around the clock, with ~$20,000 of spend up to this point across different services. Funding is secured, I appreciate all the gestures for donations but it is not necessary. The bill is taken care of.

We have done over a dozen disclosures up to this point, with 150 repos scanned. The hardest part is coordinating to get things to the right people (thank you @danielabrozzoni for the help)

I have a first pass on a bitcoin red team agent harness which only requires an @opencode zen api key, makes it easy for us to use K3 for the actual heavy lifting and then GPT Sol + Fable/Opus + GLM5.2 for supporting documentation.

While it is powerful, having found critical issues, I would view this as only version one. There is a lot of iteration I'm looking forward to improving on.

Our goal is to open source the harness so it can be pointed at internal repositories for insights so the hardening of defenses can go deeper than the code which is made public.

We also have been connected with OpenAi for some help so I could manage getting the @OpenAI Cyber Harness running as well (thank you @lylepratt ). Its a much more expensive scan, but well worth it for load bearing portions of the bitcoin ecosystem and has already yielded good results.

Goals for tomorrow are scale in processes and systems so we can do a better job and automating full end to end functionality to get humans out of the loop for the heavy lifting. The first mile (requests/staging) and last mile (handoff of reports) are the choke points right now.

Thank you @stutxo @callebtc @benthecarman @thesimplekid and so may more.

Tom Kirkpatrick

@mrfelton

Jul 16

Boris Cherny

@bcherny

Jul 15

Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things.

I think many of these automations have become even more important now. This is true for a number of reasons.

First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time.

Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time!

Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation.

Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.

Tom Kirkpatrick

@mrfelton

Mar 5

Justin Poehnelt

@JPoehnelt

Mar 4

You need to rewrite your CLI for #ai #agents!

justin.poehnelt.com/posts/rewrite-…

Tom Kirkpatrick

@mrfelton

Feb 12

Cloudflare

@Cloudflare

Feb 12

Time to consider not just human visitors, but to treat agents as first-class citizens. Cloudflare’s network now supports real-time content conversion to Markdown at the source using content negotiation headers.
cfl.re/4ksZQ1S

Tom Kirkpatrick

@mrfelton

Feb 11

simeonGriggs

@simeonGriggs

Feb 11

Can anyone explain why we're not installing skills from npm so we actually get versioning and updates?

Downloading plain text files to your project exactly once feels insane.