More workflow details: 1: submit your defensive cyber application for @AnthropicAI / @OpenAI to get access to Mythos or Daybreak ASAP. I think these models are still likely ahead of abliterated open models being used by attackers in terms of ability to proactively identify exploits in your systems. 2: Setup your analysis environment (ideally dedicated local hardware or cloud based coding server, you want this to be able to run very long sessions) with read only access to everything (code, infrastructure, 3rd party integrations). Recommend a harness or meta-harness that lets you use different foundation models for cross model review (we use @opencode and T3 code by @theo) Ideally also give this environment the ability to run and deploy to code/updates to a working version of your full app/stack in staging or sandbox so it can simulate & verify the effectiveness of patches. Deploy coding server on separate accounts & machines (not shared with the products we are using it to build), and put it all behind @Tailscale so that you’re not fighting intrusions into the systems you are using for analysis/testing. 3: Start with the @Cloudflare security audit skill and run it in the environment you provisioned with Mythos/Daybreak - it will probably find a bunch of stuff you should fix. Also give it an explicit list of all the infra/repos/3rd party services you’ve given it access to. 4. Also point an agent at your public DNS records to identify legacy infra you may have forgotten about / aren’t monitoring. Add anything it finds within the scope of your security audit. The attackers are 100% doing this too so you want to get ahead of it. 5. Have your coding agent stack rank what Mythos/Daybreak finds in order of criticality/security risk, and cluster them into groups of things that are likely to touch the same files. Put them into your issue tracker of choice with a specific tag you can use to identify in next step. 6. Setup a loop in your coding server that plucks the top cluster off your list of tagged security issues, does cross-model root cause analysis for diversity of perspectives, builds a solution (or multiple solutions), does cross-model Code review, and verifies the solution in the local or staging environment you gave it access to, opens a PR for you to review, and then automatically moves onto the next issue. See compound engineering skill by @every / @kieranklaassen for a good starting point on this workflow (fork and tune the LFG command for your SDLC) 7. Parallelize the loop above if you can for faster throughput through the process. The goal here is to feed in a stack of security issues as input and receive a stack of verified PRs as output as quickly as possible. 8. Start building up a library of user scenarios that you use to ensure that your security patches don’t break things for legit users. We use a collection of markdown files and macros (for fixture setup/teardown), executed by OpenCode + agent-browser as an automated QA agent. The scenario runner does end-to-end testing in the browser as a normal user would. 9. Merge PRs into a release candidate, re-validate the combined set of them together with your user scenarios in staging to prove it to yourself that the release is good to ship. 10) Release to prod then re-validate there with scenarios again to ensure nothing broke after deploy. All production deploys are still gated behind human review in our workflow. But think a subset of lower risk issues could be safely auto-deployed after passing verification in staging.

We might be wrong. But if we're right, you'll have built the infrastructure that runs a new kind of company. This is the highest-leverage engineering work that exists right now. That's the trade. Interested? Apply here: ycombinator.com/companies/ro…

Interested in following along with @RocketableInc? Subscribe for updates: rocketable.substack.com