I feel like just use claude code. That is it. Use it you get the feel for it. Everyone is over complicating.
It is like learning to code itself. You need flight hours.
It is like learning to code itself. You need flight hours.
How much more depends on what you're trying to do and in what language (e.g. "favourite" pet peeve: Claude occasionally likes to use instance_variable_get() in Ruby instead of adding accessors; it's a massive code smell), but there are some generic things, such as giving it instructions on keeping notes and giving them subagents to farm out repetitive tasks to prevent the individual task completion from filling up the context for tasks that are truly independent (in which case, for Claude Code at least, you can also tell it to do multiple in parallel)
But, indeed, just starting Claude Code (or Codex; I prefer Claude but it's a "personality thing" - try tools until you click with one) and telling it to do something is the most important step up from a chat window.
That's exactly the point. Agents have their own context.
Thus, you try to leverage them by combining ad-hoc instructions for repetitive tasks (such as reviewing code or running a test checklist) and not polluting your conversation/context.
I'd rather use more of them that are brief and specialized, than try to over-correct on having a single agent try to "remember" too many rules. Not really because the description itself will eat too much context, but because having the sub-agent work for too long will accumulate too much context and dilute your initial instructions anyway.
You could still overload with too many skills but it helps at least.
Consider as an example, that "Clean Code" used to be gospel, now it's mostly considered a book of antipatterns, and many developers prefer to follow Ousterhout instead of Uncle Bob. LLMs "read" both Clean Code and A Philosophy of Software Design, but without prompting they won't know which way you prefer things, so they'll synthesize something more-less in between these two near-complete opposites, mostly depending on the language they're writing code in.
The way I think about it is: "You are a staff software engineer with 15 years of experience in <tech stack used in the project>" is doing 80% of the job, by pulling in specific regions in the latent space associated with good software engineering. But the more particular you are about style, or the more your project deviates from what's the most popular practice across any dimension (whether code style or folder naming scheme or whatnot), the more you need to describe those deviations in your prompt - otherwise you'll be fighting the model. And then, it's helpful to describe any project-specific knowledge such as which tools you're using (VCS, testing framework, etc.), where the files are located, etc. so the model doesn't have to waste tokens discovering it on its own.
Prompts are about latent space management. You need to strengthen associations you want, and suppress the ones you don't. It can get wordy at times, for the same reason explaining some complex thought to another person often takes a lot of words. First sentence may do 90% of the job, but the remaining 20 sentences are needed to narrow down on a specific idea.
But it's good to hear that it's not me being completely dumb, it's Copilot Agent Mode tooling that is?
And then there's Ralph with cross LLM consensus in a loop. It's great.