261 karma · joined January 4, 2016
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.
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 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.
Turns out, Zed is also busy pumping out AI features and the code editing experience is degrading. I'm actively shopping for a replacement.
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.
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.
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.
The fact that the base language is an order of magnitude (or two!) slower has almost never mattered. If my work gets to the point where it does, and I have an excuse to go mess around with a rust extension or some cool optimized library, things are going very well.
I've been professional developer for over 20 years now, and I've read this forum obsessively for much of that time. I've seen people write things like, "Most engineers would kill for a 5% speedup" and I think, on what planet? Most engineers have much larger problems that cannot be so easily quantified. Come to think of it, I think that there is an allure to performance optimization due to the fact that it can be so easily quantified.
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
Nevertheless it’s been a helpful rule of thumb to not overthink optimizations.
I fiddled with transferring the saved token from my keychain to the agent user keychain but it was not straightforward.
If someone knows how to get a subscription to Claude to work on another user via command line I’d love to know about it.
PJ = private jet
Diamond hands and to the moon are crypto trader slang
Makes me laugh answering this question, because the meaning is all there if you skip over all the meme words.
To answer your question directly, if somewhat glibly, I’m glad I rebased every time I go looking for something in the history because I don’t have to think about the history as a graph. It’s easier.
More to your point, there are times when blame on a line does not show the culprit. If you move code, or do anything else to that line, then you have to keep searching. Sometimes it’s easier to look at the entire patch history of a file. If there is a way to repeatedly/recursively blame on a line, that’s cool and I’d love to know about it.
I now manage two junior engineers and I insist that they squash and rebase their work. I’ve seen what happens if they don’t. The merges get tangled and crazy, they include stuff from other branches they didn’t mean to, etc. the squash/rebase flow has been a way to make them responsible for what they put into the history, in a way that is simple enough that they got up to speed and own it.
I suspect pyright has caught up a lot but I turned it off again rather recently.
For what it’s worth I did give up on cursor mostly because basedpyright was very counterproductive for me.
I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.
When that token expired I didn't have the patience to go through it again. Using an API key looked like it would be easier.
If this is of interest to anyone else, I filed an issue that has so far gone unacknowledged. Their ticket bot tried to auto-close it after 30 days which I find obnoxious. https://github.com/anthropics/claude-code/issues/9102#issuec...
Separately, I have spent the last three years building a web app that replaced a heap of automation scripts for a ~50 person business. These were much more modern than what the OP describes but it had some of the same qualities. The scripts mostly generated google sheets and emails. The replacement is a python web app using SQLite. Moving the company data into a proper database has been a very significant step for them. In some ways, the project feels a lot like custom business software that got built in the 90s.
I have a python web app that creates a DB connection per request (not ideal I know) and immediately attaches 3 auxiliary DBs. This is a low traffic site but we have a serious reliability problem when load increases: the ATTACH calls occasionally fail with "database is locked". I don't know if this is because the ATTACH fails immediately without respecting the normal 5 second database timeout or what. To be honest I haven't implemented connection pooling yet because I want to understand what exactly causes this problem.