Copilot just sucks . I’ve tried them both and I stick with cc and codex mcp

I tried copilot for a bit in vscode as well with opus and felt something was off. Somehow as if copilots harness around it just wasn’t as good. But I can’t give solid prove.

> Is there a significant difference between Claude Code in VSCode and Copilot in VSCode? I’ve been using Copilot with the Claude models (including Sonnet/Opus 4.6) and it seems to work spectacularly.

Most models are limited to 200k context in GitHub Copilot. The Claude models are now 1M context elsewhere.

The $10/month plan offers a quite limited number of tokens for advanced models. And if you are not careful and set the model to Auto it will quickly deplete them.

I'll check it out, thanks

Sensitive but uninformed. Expert is a common AI concept, going back for decades. It wasn’t invented with LLM.

https://en.wikipedia.org/wiki/Expert_system

What do you mean, my prompts specifically ask for a phd level expert in every field?

\s

Same way a developer and designer can work on the same feature during the same week? Or two developers working on the same feature during the same week. They can have a common api contract and then one builds the frontend and the other works on the backend.

Subagents are isolated context windows, which means they cannot get polluted as easily with garbage from the main thread. You can have multiple of them running in parallel doing their own separate things in service of whatever your own “brain thread”… it’s handy because one might be exploring some aspect of what you are working on while another is looking at it from a different perspective.

I think the people doing multiple brain threads at once are doing that because the damn tools are so fucking slow. Give it little while and I’m sure these things will take significantly less time to generate tokens. So much so that brand new bottlenecks will open up…

They are confused in the word they use: the article on what Cursor is pushing does not, according to ^F, mention "swarm" at all. Since we have a word for multiple agents working on one task, it is probably best not to use that word if you are referring to multiple agents working on multiple tasks, right?

I bring it up not to be pedantic, but because if you think it implies multi-tasking and dismiss it, you are missing out on it's ability to help in single-tasking.

Because the AI apologists cannot deal with the much studied and proven placebo effect of perceived increased productivity, so they have to try and make themselves feel better by claiming that others are lagging behind in a race no one else is really interesting in running.

A snake oil scheme if ever saw one.

This is a struggle I've also been having.

It's easier when I have 10 simple problems as a part of one larger initiative/project. Think like "we had these 10 minor bugs/tweaks we wanted to make after a demo review". I can keep that straight. A bunch of agents working in parallel makes me notably faster there though actually reviewing all the output is still the bottleneck.

It's basically impossible when I'm working on multiple separate tasks that each require a lot of mental context. Two separate projects/products my team owns, two really hard technical problems, etc. This has been true before and after AI - big mental context switches are really expensive and people can't multitask despite how good we are at convincing ourselves we can.

I expect a lot of folks experience here depends heavily on how much of their work is the former vs the later. I also expect that there's a lot of feeling busy while not actually moving much faster.

Yes, also doesn't work for me. If the changes are simple, it is fine but if the changes are complex and there isn't a clear guideline then there is no AI that is good enough or even close to it. Gives you a few days of feeling productive and then weeks of trying to tidy up the mess.

Also, I have noticed, strangely, that Claude is noticeably less compliant than GPT. If you ask a question, it will answer and then try to immediately make changes (which may not be related). If you say something isn't working, it will challenge you and it was tested (it wasn't). For a company that is seems to focus so much on ethics, they have produced an LLM that displays a clear disregard for users (perhaps that isn't a surprise). Either way, it is a very bad model for "agent swarm" style coding. I have been through this extensively but it will write bad code that doesn't work in a subtle way, it will tell that it works and that the issues relate to the way you are using the program, and then it will do the same thing five minutes later.

The tooling in this area is very good. The problem is that the AI cannot be trusted to write complex code. Imo, the future is something like Cerbaras Code that offers a speed up for single-threaded work. In most cases, I am just being lazy...I know what I want to write, I don't need the AI to do it, and I am seeing that I am faster if I just single-thread it.

Only counterpoint to this is that swarms are good for long-running admin, housekeeping, etc. Nowhere near what has been promised but not terrible.

How does one work with a team of developers to solve larger problems? You break down the problems into digestible chunks and have each teammate tackle a stack of those tasks.

Its far closer to being a project manager than it is being a solo developer.

I tried swarms as well, but I came back to you as well. It’s not worth it even th e small worse description double-checking, fine-tuning is not worth the effort the worse code will cost me in the future. Also when I don’t know about it.

It's not that difficult. You get it to work on one deep problem, then another does more trivial bug fixes/optimizations, etc. Maybe in another you're architecting the next complex feature, another fixes tests, etc etc

> Are your agents working on tangential problems?

Unrelated problems simultaneously in the same git tree. Worktrees are unnecessary overhead if the area they're working in are disjoint. My Agents.md has instructions to commit early and often instead of one giant commit at the end, otherwise it wouldn't work.

> how do you ensure you're still thinking at a sufficient level of depth and capacity about each problem each agent is working on?

The context switching is hell and I have to force myself to dig deep into the MD file and understand things and not just rubber stamp the LLM output. It would be dishonest of me to say that I'm always 100% successful at that though.

Thank you so much. These comments let me believe in my sanity in an over-hyped world.

I see how people think its more productive, but honestly I iterate on my code like 10-15 times before it goes into production, to make sure it logs the right things, it communicates intent clearly, the types are shared and defined where they should be. It’s stored in the right folder and so on.

Whilst the laziness to just pass it to CC is there I feel more productive writing it on my own, because I go in small iterations. Especially when I need to test stuff.

Let’s say I have to build an automated workflow and for step 1 alone I need to test error handling, max concurrency, set up idempotency, proper logging. Proper intent communication to my future self. Once I’m done I never have to worry about this specific code again (ok some error can be tricky to be fair), but often this function is just practically my thought and whenever i need it. This only works with good variable naming and also good spacing of a function. Nobody really talks about it, but if a very unimportant part takes a lot of space in a service it should be probably refactored into a smaller service.

The goal is to have a function that I probably never have to look again and if I have to do it answers me as fast as possible all the questions my future self would ask when he’s forgotten what decisions needed to be made or how the external parts are working. When it breaks I know what went wrong and when I run it in an orchestration I have the right amount of feedback.

As others I could go very long about that and I’m aware of the other side of the coin overengineering, but I just feel that having solid composable units is just actually enabling to later build features and functionality that might be moat.

Slow, flaky units aren’t less likely to become an asset..

And even if I let AI draft the initial flow, honestly the review will never be as good as the step by step stuff I built.

I have to say AI is great to improve you as a developer to double check you, to answer (broad questions), before it gets to detailed and you need to experiment or read docs. Helps to cover all the basics

I switched to use LLMs exclusively since around March last year and I haven’t wrote a line of code directly since then.

I have followed the usual autocomplete > VS Code sidebar copilot > Cursor > Claude Code > some orchestrator of multiple Codex/Claude Codes.

I haven’t experienced the flow state once in this new world of LLMs. To be honest it’s been so long that I can’t even remember what it felt like.

"My flow state is better than yours"? Point is, I get engaged with the thing and lose track of time.

LLMs deal with implementation details that get in the way of "flow"

In my workflow, it's totally interactive: Give the LLM some instructions, wait very briefly, look at code diff #1, correct/fix it before approving it, look at code diff #2, correct/fix it before approving it, sometimes hitting ESC and stopping the show because the agent needs to be course corrected... It's an active fight. No way I'm going to just "pre-approve all" and walk away to get coffee. The LLMs are not ready for that yet.

I don't know how you'd manage a "swarm" of agents without pre-approving them all. When one has a diff, do you review it, and then another one comes in with an unrelated diff, and you context switch and approve that, then a third one comes in with a tool use it wants to do... That sounds absolutely exhausting.

Click on the timestamp link to go to the comment's own page where it will be rendered black instead of gray.