261–270 of 278 posts
Earlier quoted context omitted.
Superpowers is literally a bunch of skills packaged in a Claude plugin
Right on, I was going off the OP's GSD link, which looks like the def of a cli wrapper to me. Hadn't seen superpowers before, seems way too deterministic and convoluted, but you're right, not a cli wrapper.
Earlier quoted context omitted.
Sort of agreed. Natural language specs don't scale. They can't be used to accurately model and verify the behavior of complex systems. But they can be used as a guide to create formal language specs that can be used for that purpose. As long as the formal spec is considered to be the ground truth, I think it can scale. But yeah, that means some kind of code will be required.. :)
Things like Github's speckit seems to have a fair amount of usage. The idea that specs are code now, is one can effectively rebuild in the future with newer models. Test requirements could be defined upfront in the specs too, no?
A formal language helps in this regard because it makes visible the inconsistencies that are hidden in the specifications.
Coding is difficult sometimes because it turns out the problem you are trying to solve is more difficult than expected (not because it's difficult to code).
Earlier quoted context omitted.
It's not a context issue so much as a focus issue. The agent will complete part of a task and then ask if I want it to continue. Even if I told it I want it to keep going until all tasks are complete. Using a wrapper deals with that behavior. Most projects I do take 20 minutes or less for an agent to complete and those don't need a wrapper. But for longer tasks, like hours or days, it gets distracted.
Damn, what kind of tasks are you making your agents work on that takes days???
Earlier quoted context omitted.
Things like Github's speckit seems to have a fair amount of usage. The idea that specs are code now, is one can effectively rebuild in the future with newer models. Test requirements could be defined upfront in the specs too, no?
I think natural language leaves too much room for ambiguities. If you treat it as code I expect you will run into frequent bugs and unintended side effects of LLM-authored changes as your software evolves. So I'm skeptical about this approach. A formal language helps in this regard because it makes visible the inconsistencies that are hidden in the specifications. Coding is difficult sometimes because it turns out th…
Been building for a long time, and more specifically overseeing building in detail, which transfers interestingly to overseeing LLMs.
Just like with coworkers, providing the right amount of context (not too much, or too little) for the request to succeed is critical.
I shared similar views, but I have seen first hand (using in production myself) that specs, well done in a way for LLMs, can do development with AI that works. If something doesn't work out, you don't fix the code, you adjust the spec. Highly recommend watching doers on Youtube who are sharing screens.
Discovering a problem is more difficult than expected allows you to take more shots at it, quicker by adjusting the spec, for example and running again. We are used to just plowing ahead to make the code right, instead of improving/clarifying the ask/spec.
Earlier quoted context omitted.
I think natural language leaves too much room for ambiguities. If you treat it as code I expect you will run into frequent bugs and unintended side effects of LLM-authored changes as your software evolves. So I'm skeptical about this approach. A formal language helps in this regard because it makes visible the inconsistencies that are hidden in the specifications. Coding is difficult sometimes because it turns out th…
Sounds like this perspective is theoretical. Been building for a long time, and more specifically overseeing building in detail, which transfers interestingly to overseeing LLMs. Just like with coworkers, providing the right amount of context (not too much, or too little) for the request to succeed is critical. I shared similar views, but I have seen first hand (using in production myself) that specs, well done in a…
When you implement a new feature with these tools, how do you convince yourself that existing system behavior remains unchanged?
When you have the code in front of you, atleast you can reason about the full system behavior before and after because code is unambiguous like that.
With spec driven development, the LLM can rewrite anything as long as it meets the spec. That's a problem if your customer relies on behavior that's written down ambiguously (or omitted entirely).
So, I think this is only going to work if you write specs with mathematical precision.. at which point you probably want to write them using a mathematical language.
Earlier quoted context omitted.
Curious what you mean by "played both agents" and "faster and faster"? API calls are API Calls or are you running an open-source model locally?
Rephrasing of the post in case it's clearer: "I would love to do something more sophisticated, but it's ironic that when I performed both of the duties done nowadays by agents, the development loop got faster and faster as computers got faster and faster."
Earlier quoted context omitted.
Sounds like this perspective is theoretical. Been building for a long time, and more specifically overseeing building in detail, which transfers interestingly to overseeing LLMs. Just like with coworkers, providing the right amount of context (not too much, or too little) for the request to succeed is critical. I shared similar views, but I have seen first hand (using in production myself) that specs, well done in a…
In my experience, when you sell expensive complex systems, customers are very worried about any differences in system behavior as a result of software updates. When you implement a new feature with these tools, how do you convince yourself that existing system behavior remains unchanged? When you have the code in front of you, atleast you can reason about the full system behavior before and after because code is unam…
I've built, integrated and sold expensive complex systems. They want it working, connected, and reliable. Lots of paths there.
Have you built with LLMs? I'm asking because I would refer to things from having something working on a complex code base.
Specifications, or inputs in a way are a new code. The added focus on documentation, before and after is a bonus too, and also helps with alignment.
Code styles/formats/philosophies can be documented and followed.
The human process of what to look into, in what way, for what areas of the code base, can also be trained and remembered. There are ways to achieve and maintain precision without 100% mathematical precision, because there are only so many ways to solve a problem, or step and the mechanisms for deciding can also be defined in general, or specific.
Earlier quoted context omitted.
I find that even with opus 4.6, copilot feels like it’s handicapped. I’m not sure if it’s related to memory or what but if I give two tasks to opus4.6 one in CC and one in Copilot, CC is substantially better. I’ve been really enjoying Codex CLI recently though. It seems to do just as well as Opus 4.6, but using the standard GPT 5.4
I think this shows that the model alone isn't the complete story and that these "harnesses" (as people seem to be calling them) shape a lot of the experienced behavior of these tools.
You can have the biggest monster of an engine ever, but if you put it in a tricycle and a grandma is driving, you won't get good results.