Good lord! In my actual writing - zero. I don't use it to produce words for anything. I'm working on a book though and it was useful for building a copy-editor skill and asking it things like:

Am I using british english consistently? Are there any grammatical errors? Etc.

I still feel it's important to fix whatever it finds by hand though.

This. Its also great for finding out all the ways you are wrong or discovering the views, data, perspectives you are missing. I use it for this as well.

I wish I could understand the appeal of using Claude Code inside VScode rather than Copilot. I feel like I'm missing something obvious.

I'm with you there. I can't stand the CLI that wants to take you away from the mostly bad code it writes. Give me the structure, let me finesse it - to do that I need to actually see it no matter how much Anthropic pretends that it's perfect.

I run Claude code inside an emacs vterm for moderately long lived work streams, and an ever shifting set of tmuxes for quick small features or bug fixes. The way I ensure I read the code at least a bit is the same as for wholly hand written code: I never do git add . only for one file at a time, and I got diff each file just prior to adding it (except sometimes for code genned files). I also arrange mostly to do incremental dev, sort of agile where I am the client and claude is the dev team and I check the utility of each feature one by one, so what I end up with delights me. It does tend to do more than is needed, so I will mostly delete code it has written rather than fix things. Like really not every module tunable constant needs to be over rideable from env vars. I am happy with the resulting systems, they have not collapsed into unmaintainable messes yet; the Claude in vterm in emacs is nice where I can think and run shell commands and look at code or git history while having a longer running discussion is nice UX.

I just have git diff open in another terminal. Everything I do is in the terminal.

Slightly related (me not understanding) is why the Copilot in VS code is essentially just CLI interface. Why can't it use the IDE tools (search, LSP, ...). All it ever does is trying to execute grep.

Someone mentioned here the other day that when you try and give Claude those tools throughan MCP or skill it tends to go a bit loopy.

At the moment it seems like the way it's been trained has been tightly coupled with grep.

It does feel bizarre though that it doesn't use the symbol servers.

Because it’s far far easier to make a text-generation machine generate text that has decades of how-to explanations on the Internet than to correctly work an internal editor API that changes often and isn’t as well-documented.

Especially if you want effective results.

I replaced common grep with a semantic search wrapper for some projects. It was amusing. It has a response header that lets Claude know it is not using standard grep. Works fine. Have to out smart them ;)

Claude Copilot does seem a bit more lost on the interface side than other models, but then again all of them are. Only the baseline tier seems to have been fine tuned to the platform.

I'm not sure how you can believe that GitHub Copilot in VS Code is just a CLI interface when the former existed long before the CLI. It's not. For a certain amount of time, the two teams weren't even working together. The CLI was adding things customers were wondering when would it reach VS Code. So, it's not just a CLI harness. They added the ability to call the CLI from VS Code but GitHub Copilot in VS Code existed before the CLI and is remains a separate thing that's just interfacing with the CLI now.

All I can say is I know because I know. There's been some "synergizing" among the corporation about the CLI team running off to do their own thing and adding features to the CLI that amount to trying to force a Terminal to act like a GUI.

Claude’s prompt heavily pushes it towards grep. We have an internal cross repo semantic search mcp and to get Claude to consistently use it a skill and prompting was not enough. A pre tool use hook is the answer. Claude will even write one for you if you describe the problem to it :)

There is an option to turn on semantic indexing and search on copilot in vscode. Although I have no perceptual differences when I turn it on. The docs mention something about it.

https://code.visualstudio.com/docs/copilot/reference/workspa...

> I wish I could understand the appeal of using Claude Code inside VScode rather than Copilot

MS thinks CoPilot is the Clark Griswold of LLMs when it's really Cousin Eddie...

Same, with regard to TUIs in general. The VS code copilot chat extension has really nice integration for 'human in the loop' style agentic development. I build some tooling - https://www.agentkanban.io to integrate a taskboard and git worktrees with copilot chat

Claude Code will write the whole thing for you. Whereas doesn’t Copilot require input along the way of coding? ie- it doesn’t do all the programming for you

It can code the whole thing for you, copilot in vscode is simply better, people just never tried it.

If you give Copilot a file with a list of tasks to complete, it will try to churn through them (just like most other harness would do these days).

Ah okay, can it work on a whole repo in an agentic way?

Yes, of course, it can also span subagents, work for an hour without interactivity if that's what you want etc. just like any other harness.

Actually due to stupid billing system of github which charges per "premium request" instead of tokens, you could and still can abuse it so it costs nothing. They're changing it from next month to usage based billing though.

Ah thank you for updating me there.

I'm a little the opposite, what's the point of using an IDE with AI? I genuinely don't get it?

These days I just use Claude Code Desktop or Claude Code in powershell. Standalone, not inside and IDE. Honestly, I'm using Desktop more and more as it gets more features.

The IDE is for me. No AI in it at all. If I want to get Claude to do something specific to a file I just @ the file.

Productivity. You generate the skeleton of the code with Codex/Claude Code/et. al. and refactor it manually. It's kind of unlikely that an AI agent will be able to one-shot every bit of code in the exact way you want, even with a fat AGENTS.md file. With a smart AI-native IDE like Zed, it will quickly be able to pick up what manual change you intent to do without you fully typing out anything, especially if they're repetitive. This helps enormously when you're debugging or profiling your code.

My setup I can do exactly the same? I get CC to do some work in a terminal window, I inspect and refactor in an IDE, and we bounce back and forth like that.

I have 2 monitors, Claude on one, IDE on the other.

> Productivity. You generate the skeleton of the code with Codex/Claude Code/et. al. and refactor it manually.

This doesn’t mean much if you are using a terminal editor.

the obvious answer is because it's easier , faster, and more efficient to flip a true to false right in front of you than it is to prompt an llm.

if your response is "my prompts don't produce code that needs values flipped, ever." then I would wager you're only touching very simple things with an LLM.

for me I don't care about the token cost and prompt writing so much as the fact that it's just faster to change 0 to 1 and leaves me twiddling my thumbs for an llm output less.

The thing that drove me away from manual edits was that I found myself confusing the LLM all the time. It would read or write, some code, I'd twiddle with things, and then the LLM's future references to the same code would be a mess.

On balance, and via dictation, it feels likely to be faster overall to just enact the changes I want 'inline' of the conversation thread.

Is this stuff any better now? I think current harnesses probably do have things like file change listeners that automatically inform agents before they act on a file they've previously engaged with if it has changed in the meantime.

If you do manual edits, I find it best to start a new conversation. But if your instructions and documentation is good enough, the new conversations won't have any problems picking up where it needs to be.

Having said that, I fear what June 1st brings for copilot It might suddenly be very useless for me.

I try to remember to tell it that the file changed, and should be reloaded. That usually avoids confusion.

Not really. Whenever I manually edit the code, the next turn will overwrite the changes back. You kinda have to let them know not to do that.

But you have IDE for you and cli for agent. Agent works on the same code, you can see the changes right there.

But why did you flip that true to false? It sounds like a missing unit test. So at a minimum it’s do the flip, find the right place to unit test, and write a test. Or I just tell my LLM “this should be false because of X, fix and write a test”

I just use Codex/Claude Code in one window and Neovim in another and navigate around using Niri’s keyboard shortcuts. I much prefer it to VS Code on a traditional desktop in almost every respect.

That said, I never tried copilot.

Was I not clear? I still have the IDE. I can still flip true to false.

Claude is in a terminal, I'm inspecting, reviewing, refactoring in my IDE.

That’s like asking why anyone would use IDE autoformatting, linting, or build tools rather than constantly swapping to a terminal to run their command line versions. As in, why use tool integration in an integrated development environment? Because that’s the entire point. Classic IDE refactoring and code generation tools are limited to explicitly programmed operations, but a well-integrated LLM can do much more and smarter manipulations without you having to context switch and explain the context of what you want done.

You've got the wrong end of the stick. I mean CC in a terminal, me in an IDE.

Both of us working on the same code side-by-side. Window-by-window in my case.

And my IDE isn't infested with AI popups and extra menu items and lost real estate or anything trying to guess what I'm typing.

> what's the point

Tab completion.

Smart model can cut down time to write complex firewall yaml dramatically, relying both on the existing file and the ugly draft (eg comma delimited details of the rules I need) I put out. It makes it 5 minutes lead time and 20 presses of tab instead of writing a shell/python full of edge cases or just copying existing rules as a template and laborously editing them -- smart model knows what the specific firewall needs.

But I'm not a developer, so I use both - haiku via github for tab completion and CC for cli.

For Windsurf at least, it makes it easier to control context. I can simply drag and drop a file from the IDE into the chat.

I can also click on a file referenced by the AI and have it open immediately in the IDE so that I can inspect it.

Finally, it is a pain to write long, multi-line prompts in a CLI where you can't easily click around to edit different parts.

The primary weakness I've found in IDE based UI is that it struggles to get through the corporate security in order to run commands.

For me I need to compare the code generated before committing. Also I need to read markdown plans generated for review before commit to execution. VSCode CC extension also generate clickable links to the file directly if the query has something to do with it.

All of them are valid usecase of VSCode CC extension for me.

I think they were comparing CLIs, not VS extensions.

I only use Anthropic models. Haven't touched GPT for a long time after I found myself swearing at them.

Opus 4.7, or 4.6 where it's still available at work: For spec'ing up projects or changes. The 15x multiplyer on Copilot means I rarely do this.

Sonnet 4.6 everywhere else. It rarely fails me.

Personally, I don't broadcast it, but if anyone asks I'm completely honest. I've got one project written in Swift that's up to nearly 50k lines of code and it's taken months to do from spec'ing it to debugging it to hand cranking all the CI/CD release process. A graphical MacOS native app isn't easy for me to craft prompts for and LLMs can't SEE what I'm trying to describe to it. I'm also learning Swift as I go. So quite proud of it AI or not.

I had a wild idea this morning before work started so knocked this up along with a PR to implement it.

What do you think? I feel it's like marmite. You'll either love it or hate it!

Either way, I'm probably right that I'm pushing my luck with the Microsoft and the VSCode team so I'll be ready to implement it locally via JS overrides if it gets rejected. I think there's an extenstion that lets you do that.

So, I've integrated this into my player natively and I've got to say, it's fun and quite impressive. I think the project has a lot of potential. That said, I'm forced to use it's quite limited v1 API as the v2 API (and its documentation) needs a substantial bit of work to make authentication user-friendly. I look forward to evolving with it as it moves forward.

So, the app I'm working on now supports scrobbling to both last.fm and ListenBrains.

With the former, I build the app with my own API_KEY and SHARED_SECRET, then the actual user has to add their username/password, which gets stored in the Apple keychain.

With the latter, I don't need a API KEY built into the app, and they just login with a username and a token.

Would I be right that I could just duplicate the listenbrainz code with that new endpoint and it would work the same way?

Mostly yes, but with one important detail. Rocksky has a minimal ListenBrainz-compatible API, so duplicating the ListenBrainz integration and pointing it to the Rocksky endpoint should work for basic auth + submit/scrobble. The current limitation is that Rocksky doesn't implement the full ListenBrainz API yet, so anything beyond auth + submitting listens may not work the same way. I'm trying to keep this path as simple as possible because compatibility with existing scrobblers is important for adoption.

Various things this month:

- I've got a native, open source MacOS music player/library _finally_ past version 1. (https://bocan.app) That's been an ugly learning curve as I'm both not the greatest Swift developer and still I want to keep adding features that I didn't quite understand at the start like ReplayGain.

- Ongoing maintenance of my badly-named open-sourced tool called Codex (https://github.com/bocan/codex). It's like a file/git based 1 person doc store that I use at work to drop markdown into, display it, with a built-in MCP server that I can use to ask it questions. THAT one is typescript so much easier. But then you have to worry about the constantly shifting sands of outdated and vulnerably dependencies to look after.

Off Net:

- Went to open my greenhouse for the season and found a nest of robins in my trash/rubbish bin. FFS. Now I can't empty it all for a long time, have to time my visits to tend to the tomatoes and peppers, and absolutely not close the doors. Anyone know how long it takes robins to fledge?

So sexy! I could probably build the electronics easily enough, but such projects need workworking tools I just don't have room for in my tiny flat.

(nor would the missus be pleased for me to buy them - but that's another matter)

If there's a makerspace or hackerspace near you, they might have a CNC router. Apart from (I believe) the front panel being a two-sided job, this is pretty straightforward and could be done entirely on a Shopbot or equivalent. Worst case you might need to learn FreeCAD and buy some collets ($10-$50) and bits (~$50-$75 if you're getting two). Best case, they have software and tooling you can use.

Source: am a furniture maker professionally. Have worked out of a makerspace, and have done equivalently complex projects on their Shopbot.

Edited to add: if you skip the rabbets around the gauges on the front panel, you can make that a single-sided CNC job, which makes it much easier. With some care, you could do those with a handheld router and a rabbetting bit.

You should check your local libraries too. Some have all kinds of crazy tools you can borrow or use on-site.