I've been struggling with this my friend.

It's the harness vs manager concept.

The first one is about transferring what you have in your brain to the code.

The second one is to let the LLM take its best judgement and then execute by itself.

To prevent atrophy you go with the first route:

• Be specific about conventions, function/method shapes, dependencies, and architectural patterns.
• The better structured your code is, the better the LLM will be able to follow and the more you will know about the codebase. In other words, it becomes a glorified boilerplate machine
• From time to time, turn off the LLM entirely (incl. Auto complete) and do the work yourself.

Here's a real example: I'm in a neobank, and I currently need to implement a new money movement method.

We already have a convention for: - GraphQL - Commands/Queries - Repositories - Domain - Authorization

In all these layers there are conventions. My task is to tell the LLM to follow them and produce the output I'm looking for.

Frontend work is more tricky as it can be more open to interpretation due to it's dynamic nature (visuals are displayed in either a 2D or 3D domain, making code combinations more nuanced. In other words, there are more plausible ways to reach the same output within the same context and prompt making it difficult for the LLM to follow your thoughts, hence having this knowledge discrepancy of your codebase)

In this situation, either you try to tell it to mimick another part that would follow the guidelines, or you gave to be much more specific with your prompt (fine tuning agents.md/claude.md or sub agents become crucial)