These folks have found a bunch: https://www.promptarmor.com/resources

But I guess you mean one that has been exploited in the wild?

No other model from a major lab has matched it since afaik.

Edit: err, I see in the comment below mine that Grok has 2M as well. Had no idea!

The point of a system design interview is to have a discussion that examines possibilities and tradeoffs.

Better imo is to produce a README or dev-facing doc at the end that distills all the planning and implementation into a final authoritative overview. This is easier for both humans and agents to digest than bunch of meandering planning files.

- Create urgency

- Keep scope creep under control

- Prioritize whatever is most valuable and/or can stand on its own

If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.

If there are CI failures or obvious issues that another AI can identify, why not have the agent keep going until those are resolved? This tool just makes that process more token efficient. Seems pretty useful to me.

Currently, if you ask an LLM to do something small and self-contained like solve leetcode problems or implement specific algorithms, they will have a much lower rate of mistakes, in terms of implementing the actual code, than an experienced human engineer. The things it does badly are more about architecture, organization, style, and taste.

You can be socialist if you cooperate. You can be a dictator if you cooperate. It’s not about political philosophy or forms of government, just playing ball with the hegemon.

Social life is a bit like SEO. To get the full benefits, you needed to start on it years ago. Trying to do it just-in-time is generally a very frustrating experience. I think there's wisdom in doing casual cultivation when you don't feel you need it. It's like keeping your skills/résumé up-to-date just in case.

In reality, even an ASI won’t know your intent unless you communicate it clearly and unambiguously.

- On precision vs. noise: yeah, this is a core challenge. Quick answer is the scanner tries to be conservative and lean towards not flagging borderline issues. There's a custom guidance field in the config that lets users adjust sensitivity and severity based on domain/preferences.

- CI times: on a medium-sized PR (say 10k lines) in a fairly large codebase (say a few hundred K lines), it will generally run in 5-15 minutes, and run in parallel with other CI actions. In our case, we have other actions that already take this long, so it doesn't increase total CI time at all.

- Vulnerability types: the post goes into this a bit, but I would look at scanning and red teaming as working together for defense in depth. RAG and tool misuse vulnerabilities are definitely things the scanner can catch. Red teaming is better for vulnerabilities that might not be visible in the code and/or require complex setup state or back and forth to successfully attack.