11–20 of 52 posts
The promise is nice, yet I find the readme very hard to understand. So I’m not sure how it solves these problems exactly. First off I would expect a (team) methodology to be referenced. There are tons to choose from. From that point on other terms may make more sense. For example: “ Pillar 2: Product Strategy & Architectural Governance (PDRs & ADRs) Factor III — Mission Definition. Factor IV — Structured Planning. Fa…
I see what this is going for but can’t help but feel like it’s overwrought. It feels a bit like the most likely outcomes are increased token burn, review surface, and time per task vs not using this. Who knows, maybe that’s a good thing.
Things like ArchUnit, static analyzers, and other deterministic tools can help with lower level things like architecture. For higher up stuff, I am increasingly feeling like agents don't guarantee anything and in many cases its just the opposite. This is where a thoughtful engineer and reviewer can keep things in check.
It's possible I'm off base here, but I can't make heads or tails of the LLM written readme.
IMO, these agentic guard rails aren't the answer. It seems like we're seeing that the more you stuff context, the more the agents forget and don't follow the guidelines.[1] Things like ArchUnit, static analyzers, and other deterministic tools can help with lower level things like architecture. For higher up stuff, I am increasingly feeling like agents don't guarantee anything and in many cases its just the opposite.…
I feel like this is going to add 100K tokens and 10K rules to everything that the agent is trying to do. Sort of like dumping the Clean Code book into context and saying, hey now you know how to code cleanly, write great code now
Got rid of superpowers and other useless skills
Your LLM is more than capable of learning from the sea of knowledge
I dont want to be biased but i can get myself to read this after an opening like that .