gwking

My interpretation is much less dramatic. If you find a way to make a dollar from 95 cents of tokens and scale it in any meaningful way, you would be foolish to tell hacker news about it.

It is hands down the most user hostile UX I put up with. The fact that I put up with it speaks volumes about the value proposition that the underlying models bring to the table.

I’m in the process of dumping codex for more open harnesses that don’t add problematic new features every week. Because Anthropic insists that I have to use their harness with the subscription, eventually I’m either going to wrap `claude -p` to get away from the crappy TUI or else I’ll just unsubscribe and use other models. Their bad UX has alienated me as a paying customer.

The last paragraph says: > At some point your docs will outgrow a single folder, and then all bets are off. You’ll want a separate repo with its own build process...

My question is, why is this taken as a given? Is it so hard to have docs and code live together in version control after a certain scale? If so, what is the specific problem and what is the cause?

I ask because I've never been that satisfied with the various ways I've tried to organize projects in git. Recently I've been trying to keep the source, tests and docs together in the same tree so that changes are more localized. It seems to be helping me keep track of things, especially with coding agents so eager to make changes all over the place. I find their proclivity to repeat the same idea in multiple locations (agent instructions, docs, docstrings, help strings, comments) especially problematic.

I appreciate humor here, but there are now a dozen of these comments on every thread about Claude. They no longer adding anything substantial and dilute the discussion.

I don't mean to pick on this comment in particular. The majority of my work day is now spent reading AI generated text, and I look at HN (too much!) because I want to read human commentary. Humans pretending to be obnoxious AI on repeat is net negative to say the least.

I started using Zed daily about 6 months ago after 10 years of VS Code. VS Code was having idiotic regressions (like randomly inserting a copy of the final line of a file on save) while they were busy pumping out AI features.

Turns out, Zed is also busy pumping out AI features and the code editing experience is degrading. I'm actively shopping for a replacement.

I switched to using Codex for the last two weeks, and while the prose has been better, there have been a lot more technical oversights. I'm now having fable review codex commits and it finds deep issues. I'v also done the reverse where opus/fable do the work and then I have codex revise all of the prose prior to reading anything myself. This has also been effective; I'm not sure which is the better approach.

I'm so pumped for v8!

I meant does the rare SQLite bug tend to manifest in litestream for the same reason it showed up in Tailscale.

I wonder if this also affected litestream disproportionately, because litestream also inserts itself into the checkpoint process.

I wonder if making the index uppercase is strictly better in this sense, or if both upper and lowercase have chars that take more bytes.

I have one weird trick for people who are exploring this vein. I last opened an Xcode project about five years ago so I could be way behind the times.

Having spent many years fighting with Xcode professionally, I was thrilled when swift build came out, and then appalled at how badly Xcode adopted it. Eventually I realized that you can set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` (or whatever you want to call it) function in your package.

I cannot remember exactly but there was something annoying about setting up a new project; I think by default Xcode assumes that you want a swift package to be treated as a dependency that is checked out from git, but there was a way to drag and drop a local dependency in the same project directory and then it worked.

What this buys you is that files are no longer tracked by Xcode, so renames/merges no longer trigger project.pbxproj surgery. Instead you specify the swift package directories and are done.

I used this for some large personal projects and was very happy with it.

At one point I also wrote my own build tool that imitated all of the steps that Xcode took so that I could truly be Xcode-free. That also worked (and was not even that hard) but I went back to Xcode because the debugger UI was better than what I could get out of VS Code at the time, and especially because I was playing around with the Metal debugger.

I've been working on a wrapper harness that runs claude as a separate user named `agent`. I tried this about a year ago and couldn't get it to work because of OAuth and the keychain, but took another pass recently and claude had enough self-knowledge about recent changes to say we could do it with CLAUDE_CODE_OAUTH_TOKEN. It has required building a some tooling around permissions setup with ACLs but it works on macOS today.

In terms of risk, I see it as halfway between stock claude with the sandbox and full-blown container or machine isolation.

I was recently thinking that as Claude's own sandbox gets better I'm doubting the ROI on my belt-and-suspenders project, but your comment reminds me why I'm doing it.

It is not currently published open source but I'm happy to talk about it with strangers.

The grocer on my block is so tiny that I hit the max zoom before it shows up. If you pan around fiddle I can occasionally get it to appear, but it effectively does not exist according to google maps.

The suitability of Litestream for production disaster recovery is also an open question in my mind. I used 0.3.x for several years and when I tried to upgrade to the 0.5.x series there were runaway disk usage problems that would have caused downtime had they made it to prod. As far as I can tell these have not been entirely addressed, although recent bug reports suggest that they might be getting closer.

I want to love it, and I don't take open source projects like this for granted. But during my last production upgrade I chose to decommission Litestream in favor of a dumber, less granular solution using sqlite3_rsync and nightly backups because there is no point in using a backup system that is not rock solid.