> One agent does client, one does server, and one does CSS
This doesn't seem like a scalable practice. From my experience, the worst thing about these IDEs is maintaining the conversation / file context that it needs to finish the request.
If you're running multiple agents, they all have totally silo'd context (at least in cursor). Which means there's not a great way for them to align on implementation / api spec. Why not just have one "full stack" agent that handles an atomic task end to end?
This doesn't seem like a scalable practice. From my experience, the worst thing about these IDEs is maintaining the conversation / file context that it needs to finish the request.
If you're running multiple agents, they all have totally silo'd context (at least in cursor). Which means there's not a great way for them to align on implementation / api spec. Why not just have one "full stack" agent that handles an atomic task end to end?