gbrindisi
Joined 16 years ago
Joined 16 years ago
- 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.
https://cloudberry.engineering