Regular claude code is already a remote access door to your setup, once you've granted a few command execution permissions. (e.g. if it can edit your code and run the test suite)
I've had a similar experience with a very long standing bug on a github project that really annoyed me but I didn't have time nor experience with the project's context to work on it. So Claude investigated and after many iterations (>100, very complex project), it managed to make it work.
The team/person responsible for Woot sold it to Amazon, and then launched Meh the day their non-compete ended, along with a manifesto explaining how badly they thought Amazon had handled Woot.
Depends, I love it and am happy to pay for it out of privacy concerns and supporting a non-monopolist. It's got some neat features that I use all the time that google doesn't have. Is it's search results better than google? Maybe. Maybe not. I do know when I can't find something on kagi, google doesn't either.
I have no clue where I read it, that was back when meh.com launched eleven-ish years ago. I didn't find it in a hot minute of searching either. I did find these, some of which talk about the circumstances obliquely:
I'd love to see some stats on this: people leaving to start something new (be it Apple or any other acquiring company) might be over-represent because there is not much news about people staying in their job
I see it more like the tractor in farming: it improved the work of 1 person, but removed the work from many other people who were in the fields doing things manually
They do x.y.z versionning where x is often a marketing version so they have to say something at the WWDC. Here on 26 it's more than marketing, but that's not always the case. y versions often contain bug fixes but also new features.
That's usually true with Apple for .0 releases: never install those if you need to work with macOs, iOS, ... but this Tahoe version has revealed itself as being in a sad state even after the .1 .2 and now .3 It's not unfair for it to have earned the title of Windows Vista of macOs, something has become really wrong with the management of that release.
Fair point. The root directory can be seen noisy right now. There are two main reasons for that:
1. Cross-platform distribution: Shipping an Electron app across macOS (ARM/Intel), Linux (AppImage/deb/rpm), Windows, and maintaining a standalone Docker/Node server just requires a lot of platform-specific build configs and overrides (especially for electron-builder).
2. Agentic coding guardrails: As I built most of this project using Claude Code itself, I wanted strict boundaries when it writes code
The ESLint, Prettier, strict TS, Knip (dead code detection), and Vitest configs act as quality gates. They are what keep the AI's output from drifting into unmaintainable spaghetti code. Without those strict constraints, agentic coding falls apart fast.
I'd rather have 20 config files enforcing quality than a clean root directory with an AI running wild. That said, I totally take your point—I should probably consolidate some of these into package.json to clean things up.
> They are what keep the AI's output from drifting into unmaintainable spaghetti code. Without those strict constraints, agentic coding falls apart fast.
Which ones, ESLint and Prettier and so on? Those are just for "nice syntax", and doesn't actually help your agent with what they actually fall over themselves with, which is about the design of your software, not what specific syntax they use.
To be clear, I'm not saying they solve high-level software design.
The goal is to prevent the agent from getting derailed by basic noise. Forcing it to deal with strict TS errors, dead code (Knip), or broken formatting in the feedback loop keeps the context clean.
It’s less about architecting the app and more about giving the agent immediate stderr signals so it stays on the rails.
That's not what I was getting at either, but the design is pervasive in your program, not just something that sits as a document on top, but codified in the actual program.
> The goal is to prevent the agent from getting derailed by basic noise
Ah, I see. Personally I haven't seen agents getting slower and less precise of that, but I guess if that's the issue you're seeing, then it makes sense to try to address that.
Out of curiosity, what model/tooling are you using, only Claude Code? I've mostly been using Codex as of late, and it tends to deal with those things pretty easily, while none of the agents seems to be able to survive longer on their own without adding up too much technical debt too quickly. But maybe that's at another lifecycle than where you are getting stuck currently.
This is some next level nitpicking. It's like criticizing XCode or Idea config of someone, instead of their product (or more popularly whether their website hijacks the back button). But at least in this case the dev config is checked in and reproducible.
reply