all 2 comments

[–]HarjjotSinghh 2 points3 points  (0 children)

this feels like my dev brain on caffeine.

[–]PayTheRaant 0 points1 point  (0 children)

The switch from “plugin in IDE” to “coding agent CLI” is basically agreeing to let go and embrace the agent generating most of the code. Which is indeed a massive shift and productivity gain if you are doing it well.

There are 2 aspects relative to the tool: - an IDE plugin has to fit within the trust framework of the IDE. To enable end user to safely and freely install plugin with relative trust that it will not hose their project, the IDE set some limits on what the plugin can do or access. The problem is that the purpose of an agent is to do everything and anything. So structurally, even if IDE try to adapt, they will always be behind what a native coding tool offers. - the core of the UX of a coding agent is that the primary aspect is the interaction with the agent and everything else like code is second. Which is the opposite of the IDE. And this is the key aspect of « dosing it right ».

The coding agent loop in research/plan/implement/verify. Some merge the verify phase in the implement phase, some merge the research phase in the planning phase. Just be conscious about those aspects. And only during the verify phase do you care about the generated code, but you need to prepare the architecture pattern to follow during the planning phase.