gbrindisi
- reimplemented claude code auto mode for pi
- prompt injection detections refactored from llm judges to classifier judge
- as above various first pass detections for generated and untrusted files, such as moderation and malware detection
- ranking search results in web_search tools to reduce context overload
I found that a lot of what i was using a one shot haiku llm call for can now be done with jev or another decision model.
In all seriousness a big chunk of my work is reviewing docs and 100% of the design docs I read these days are generated and there is a lot of slop. I have to parse them with AI to make sense of them, contributing to the problem. I wish people would follow a sensible set of rules like this one.
Did anyone have any solution to this dread? Or cracked the code on how to write docs that have other agents as their primary audience?
Up and coming AI pentest companies need to have an exceptional product to get a chance to stand on their own and penetrate the enterprise market, otherwise their best scenario is an acquisition to get bundled into an established platform.
At $work we built a thorough workflow to do security reviews, which is a pure skill to simplify adoption https://www.synthesia.io/post/automating-code-security-revie...
But the user experience is tricky because if we aim for very low false positives the run time for this kind of workflows is too long, it's then hard to justify blocking PRs.
The feed reader shall be my main window to the world, and I am sorry that it's not obvious to content creators that I read them so I often send an email on the note of "I enjoyed this article you wrote, thanks".
I write a small blog myself and I see the other side of it, but I just gave up on SEO, metrics, etc. I want to be the change I'd like see in the world: I publish full content RSS, I remove all analytics, make the website as lean as I can, put out my contact data and my only success metric is # of interactions I get with occasional readers.
I do similar, but my favorite step is the first: /rubberduck to discuss the problem with the agent, who is instructed by the command to help me frame and validate it. Hands down the most impactful piece of my workflow, because it helps me achieve the right clarity and I can use it also for non coding tasks.
After which is the usual: write PRDs, specs, tasks and then build and then verify the output.
I started with one the spec frameworks and eventually simplify everything to the bone.
I do feel it’s working great but someday I fear a lot of this might still be too much productivity theater.
(also beautifully presented!)
2. The difference I see in agent behavior when they don't reach consensus is usually either
- when one of them didn't explore enough and lack context
- and/or when their risk assessment is off
The latest happen often, in other workflows based on agents we are now giving clear instruction on how to assess risk and where to draw a line to consider something a true positive.
3. validation is on Sonnet, we don't use persona based prompts but all the 3 validators get's the same task and context. The agent orchestrating them will take their output and make the final decision. We use an internal fork of the claude code github action for now.
Scaling Vulnerability Management with AI: What Worked
I started with all the standard spec flow and as I got more confident and opinionated I simplified it to my liking.
I think the point of any spec driven framework is that you want to eventually own the workflow yourself, so that you can constraint code generation on your own terms.
Facing bankruptcy after unauthorized Gemini API usage of about $128k
Agentic Risks
Sandboxing Agents
100% security theater, and here we are.
Code here: https://github.com/gbrindisi/agentbox