quintu5

Except it’s not a new issue. This is just the feature that made it a conversation topic.

It’s a long-standing issue that disabling telemetry disabled feature-flagged features (e.g., remote control).

If it’s like other CC features that depend on telemetry being enabled, disabling telemetry will turn off the feature.

And I’m sure there’s no conceivable way an organization as well resourced as Anthropic can separate out feature flags from telemetry. It’s just too complicated! Maybe when we get AGI?

Early stage hands-on involvement in shaping the code base’s architecture is still important if you want to build a product that can scale cleanly as you add more features.

The UX around asking and answering so many questions is awkward.

To work around this, I had claude code build me a questionnaire skill that takes a json file with a flexible schema as input and it then serves up a simple questionnaire web page on a node server where I can read the questions and give my responses either by selecting from preset tags supplied as part of the input or by including a text-based response.

The agent can include references to external images, html files, or mermaid diagrams and the page can render them all inline with the relevant question.

Once I'm done answering, I just save my responses and click a button to kill the server. The agent watching the process sees that it stopped and takes that as a signal to go read the responses from disk.

Works like a charm.

This is why I never use max effort! I’ll stick with my suspenders, thank you.

"We need the source code." No, you want the source code. You want software someone else put their time, effort, and judgement into to be available for you to do whatever you'd like with it without any recompense. The sense of entitlement here is exhausting.

There are plenty of good reasons to choose an an open source tools and sure, the ability to personalize a tool at the source layer can be valuable enough in some instances to justify maintaining a fork manually or with an agent.

Asserting that dev tools must be open source to prioritize a paradigm where users roll the dice on adding features by one-shotting them with an agent and then burning tokens until the end of time to try to keep their forks compatible with upstream changes because plugin APIs are too restrictive doesn't pass muster.

I've been deep in the IntelliJ plugin rabbit hole.

My primary project is Mermaid Studio, an IDE grade Mermaid diagram authoring experience for both humans and agents built for JetBrains IDEs. Semantic highlighting, refactoring, 120+ inspections covering everything from common rendering issues and foot-guns to obscure syntax quirks, contextual completions, interactive (drag-and-drop) diagram editing and styling. A suite of included MCP tools surfaces the plugin's intelligence and rendering capabilities, so your preferred agent (even using relatively small local models) can generate correct diagrams, even the newest or more obscure ones with ease.

https://mermaidstudio.dev/ | https://plugins.jetbrains.com/plugin/29870-mermaid-studio

Tinkering with several other IntelliJ plugin ideas that may or may not end up being released.

Still occasionally pushing up new features Tachi Code, my browser extension that brings a feature rich, highly customizable, Monaco Editor based code editor to the browser surfaces you always wished would be less of a pain to read. These days, I mostly use it for reading and printing Markdown files.

https://tachicode.com/

Too many to count. Most recently, an Alfred workflow for opening my IntelliJ projects either in an an IDE or terminal that also comes with an integrated build task runner, so I can quickly discover and run build tasks even when I don’t have a project opened anywhere.

https://github.com/DavidSeptimus/alfred-jetbrains-launcher

Mostly, I use it to quickly open projects in cmux, but I use it for switching between git worktrees in IntelliJ too.

You're the first person I've seen call out 10 as going downhill. What were your complaints about 10?

I migrated to macOS for development years ago and going back to Windows for development always felt gross, but I never had any issues with windows for entertainment/general productivity workflows. It's only once I tried 11 that I noped out for everything other than use as a Steam launcher.

This is one of the issues I’ve attempted to tackle with the Mermaid Studio plugin for IntelliJ.

It provides both syntax guides and syntax/semantic analysis as MCP Tools, so you can have an agent iteratively refine diagrams with good context for patterns like multi-line text and comments (LLMs love end-of-line comments, but Mermaid.js often doesn’t).

This has been my exact experience with agents using gradle and it’s beyond frustrating to watch. I’ve been meaning to set up my own low-noise wrapper script.

This post just inspired me to tackle this once and for all today.

Yeah, AI generated diagrams can be pretty hit or miss. The lack of good quality examples in training data and minimal documentation for these tools can make it difficult for models to even get basic syntax correct for more complex diagrams.

I’ve had a lot of success dogfooding my own product, the Mermaid Studio plugin for JetBrains IDEs (https://mermaidstudio.dev).

It combines the deep semantic code intelligence of an IDE with a suite of integrated MCP tools that your preferred agent can plug into for static analysis, up to date syntax, etc.

I basically tell Claude Code to run the generated diagram through the analysis tool, fix issues it detects and repeat until fixed. Then generate a png or svg for a visual inspection before finalizing the diagram.

Now all of my planning and architecture docs are filled with illustrative flowcharts, sequence diagrams, and occasionally block diagrams for workshopping proposed UI layouts

It’s all available in their GitHub repo.

One major downside of native rendering is the lack of layout consistency if you’re editing natively and then sharing anywhere else where the diagram will be rendered by mermaid.js.

You'll get no argument from me on that interpretation.

Markdown viewing is one of the core use-cases I had in mind when building the Tachi Code browser extension (https://tachicode.com/).

Open a raw .md file in your browser and it'll automatically open in a side-by-side editor/preview. If viewing is all you want, you can set the default preview mode for markdown files to be fullscreen.

Well you see he ran it through in through an LLM, but LLMs are lossy, so who can say if the output was a direct result of the copyrighted code or if the model focused on his unique prompting words and conjured the output from its own latent space without referencing copyrighted input at all? /s

Alternatively, we could take the model makers’ view and say that if they didn’t want their code reused, they wouldn’t have made it publicly accessible on the internet.

Maybe it's time to start dusting off the ol' Jenkins-fu?

Charging per minute for self-hosted runners seems absolutely bananas!

I’ve used this library on a couple of projects with great results. One, a drag-and-drop IaC builder and the other a GitHub Actions-like task execution graph viewer.

There’s a pattern to emoji use in docs, especially when combined with one or more other common LLM-generated documentation patterns, that makes it plainly obvious that you’re about to read slop.

Even when I create the first draft of a project’s README with an LLM, part of the final pass is removing those slop-associated patterns to clarify to the reader that they’re not reading unfiltered LLM output.

It sometimes does it on its own, but to get it to do so consistently, it needs to be told. Doubly so if you want it to split off more than one sub-agent.

This works great for refactors that touch a large number of files. You can knock out a refactor that might take 30 minutes, a persistent checklist, and possibly multiple conversations, and one-shot it in two minutes and a single prompt.

For larger tasks that I know are parallelizable, I just tell Claude to figure out which steps can be parallelized and then have it go nuts with sub-agents. I’ve had pretty good success with that.

More like they can better react to user input within their context window. With older models, the value of that additional user input would have been much more limited.

Having never owned a tablet, finding out now that iPad didn’t have a native calculator until 2024 is shocking!

When this was first posted a couple of weeks ago by the spec's author, I took it as an opportunity to see how quickly I could spin up an IntelliJ language plugin since the last time I worked on a language plugin was pre-GPT (Klotho Annotations - basically TOML inside of @annotations inside comments or string literals in a variety of host languages). Back then, it took a week for me to figure out the ins and outs of basic syntax highlighting with GrammarKit.

This time around, I worked with Claude Code and we basically filled in each other's knowledge gaps to finish implementing every feature I was looking for in about 3 days of work:

Day 1:

- Plugin initialization

- Syntax highlighting

- JSON Schema integration

- Error inspections

Day 2:

- Code formatter (the code style settings page probably took longer to get right than the formatter)

- Test suite for existing features

Day 3:

- Intentions, QuickFix actions, etc. to help quickly reformat or fix issues detected in the file

- More graceful parsing error recovery and reporting

- Contextual completions (e.g., relevant keys/values from a JSON schema, existing keys from elsewhere in the file, etc.)

- Color picker gutter icon from string values that represent colors (in various formats)

I'm sure there are a few other features that I'm forgetting, but at the end of the day, roughly 80-85% of the code was generated from the command line by conversing with Claude Code (Sonnet 4.5) to plan, implement, test, and revise individual features.

For IntelliJ plugins, the SDK docs tend to cover the bare minimum to get common functionality working, and beyond that, the way to learn is by reading the source of existing OSS plugins. Claude was shockingly good at finding extension points for features I'd never implemented before and figuring out how to wire them up (though not always 100% successfully). It turns out that Claude can be quite an accelerator for building plugins for the JetBrains ecosystem.

Bottom line, if you're sitting on an idea for a plugin because you thought it might to take too long to bootstrap and figure out all the IDE integration parts, there's never been a better time to just go for it.

EDIT: Repo link for anyone interested: https://github.com/DavidSeptimus/maml-intellij-plugin

I’m glad you got it working.

If you don’t mind, could you post the url(s) that got blocked? The only calls to non-extension urls should be GitHub.

Thanks for trying it out!

Loading that gist works for me on both Firefox and Chrome.

You can submit a bug report on GitHub with more environment details, screenshots, and console logs (if available) and I might be able to take a closer look.

https://github.com/tachi-code/tachi-code/issues/new?template...

My favorite is when you ask Claude to implement two requirements and it implements the first, gets confused by the the second, removes the implementation for the first to “focus” on the second, and then finishes by having implemented nothing.