Yes, then there is no way to elevate Bob above Alice, but in practice I think the assumption of external indistinguishability is too strong, and even the suspicion that Alice is sketchy (i.e. without hard proof) is meaningful.
The trouble is, you can think you're dealing with a Bob, but you're actually dealing with an Alice, even after enduring multiple crises that didn't trigger their specific type of badness.
But as fun as this line of thinking is, my initial charitable post was only asking for a kind of "superficial" indistinguishability. As long as you don't think about it too hard, y'know?
My stance on this is: Try to find a way to do good that doesn't make you miserable. Lying is to yourself is a form of oppression, and lying to others is a tactic for enduring oppression. (Ask a queer person about their time in the closet if you don't understand what I mean here.) Oppression makes you miserable, and misery tends to result in vapid thinkpieces that don't scratch below the surface of the referenced source material.
But also: Be honest with yourself about what you want and why you want it. Whether for good or for ill. That way, at least you can have a modicum of peace. I wrote more about this train of thought recently, if anyone's curious: https://soatok.blog/2025/10/15/the-dreamseekers-vision-of-to...
I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework.
One off it seems fine, but a huge backbone app gets really complicated for me. Show me a huge react app vs a huge backbone app and I will understand the react much more quickly.
"It's verbose, sure, but there's no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: "when this happens, do this."
I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories - the template are here, the functions are there but the endpoints are over there and... maybe it's just the backbone app I have to update but it's much more confusing and abstracted than the react app I also have to update. And don't even get me started with adding a new component. I can drop a new component into the react app and import it anywhere and it's super fast and easy... backbone not so much.
> I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories
This is exactly my experience with large scale Backbone apps (from 10+ years ago). Even with extras like Marionette it quickly became a complete nightmare to navigate or maintain. Zombie model and view objects leaking memory was almost inescapable.
I remember in 2013 I introduced Backbone to my current company, hoping to make sense out of our existing jQuery + ASP.Net MVC application. After ~3 months of code from junior and mid level developers (in house and off shore) I began to deeply regret my decision. There was just not enough patterns and utilities in the framework to keep things from going off the rails. We eventually shifted to Angular v1 and it was glorious, things just worked and even the ceremony I needed to add felt worth the trouble for the speed of development we gained.
Angular v1 was absolutely the game-changer for sane UI patterns. Although it could choke on large datasets and models were iffy, it allowed us to worry less about the framework and more about the work at hand.
I'm getting really great results in a VERY old (very large) codebase by having discussion with the LLM (I'm using Claude code) and making detailed roadmaps for new features or converting old features to new more useable/modern code. This means FE and BE changes usually at the same time.
I think a lot of the points you make are exactly what I'm trying to do.
- start with a detailed roadmap (created by the ai from a prompt and written to a file)
- discuss/adjust the roadmap and give more details where needed
- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)
- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?
- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)
- write tests to make sure everything was covered... etc etc
Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.
I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.
I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.
I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.
Thank you for this post. I don't write much code as I'm currently mostly managing people but I read it constantly. I also do product management. LLMs are very effective at locating and explaining things in complex code bases. I use Copilot to help me research the current implementation and check assumptions. I'm working to extend out in exactly the directions you describe.
"LLMs are very effective at locating and explaining things in complex code bases." YES. I do nothing BUT write code and tracking everything down in the code base is greatly simplified by using an LLM.
This is just a new tool. I think the farming example mentioned in another post is actually a great example. I love coding. I code in my free time. It's just fun. I've been doing it for ~20 years and I don't plan on stopping anytime soon!
But at work I'm really focused on results more than the fun I can have writing code. If a tractor makes the work easier/faster why would I not use a tractor? Breaking my back plowing isn't really my end goal at work. Having a plowed field is my end goal. If I can ride around in a tractor while doing it great! If I can monitor a fleet of tractors that are plowing multiple fields at once even better!
When I go home I can plant anything I want in any way I want and take all the time I want. Of course that's probably why in my free time I end up working on games I never finish...
This is what I've seen as well - in the past a large refactor for a codebase like that seemed nearly impossible. Now doing something like "add type hints" in python or "convert from js to ts" is possible in a few days instead of months to never.
Another HUGE one is terraforming our entire stack. It's gone from nearly impossible to achievable with AI.
What about having a contribute button? I know this must be a lot of work and it's such a cool idea! If you had a way to contribute on the join page I would chip in for sure :) My husband is a writer and he uses newspapers.com to research a lot of vintage newspapers for historical context. I can imagine this being a great resource for him.
Thanks I might try that! My impression of donation pages is the conversion rate is extremely low but it will be easy to add nonetheless. I might get better results with offering something in return, like Patreon (not sure what kind of patron content I want to regularly produce though) or products.
There is a much larger database of small ads that I am not publishing on the site, mostly because they add a lot of clutter. But to a researcher they may be valuable. Eventually I want to make the backend database available to people like your husband. Something like newspapers.com makes a lot of sense, thanks for the idea!
When Claude says “Let’s try a different approach” I immediately hit escape and give it more detailed instructions or try and steer it to the approach I want. It still has the previous context and then can use that with the more specific instructions. It really is like guiding a very smart intern or temp. You can't just let them run wild in the codebase. They need explicit parameters.
Same here. Recently the camera has started shaking really badly so I'm thinking of finally getting a replacement. I have other cameras though, so the phone camera is just for convenience. It's hard to bite the bullet on a new phone when the one I have is (aside from the camera) in great shape.
I'd still be using my 6S+ if this hadn't happened to me. Apparently there's a software problem with the optical stabilization, and it goes haywire. A fix is to override the stabilization solenoids with a magnet next to the lens. Not happy that Apple never fixed this bug they introduced.
The other thing that went wrong, also apparently in an OS update, is that TouchID won't work anymore. The hardware isn't recognized.
I looked into it a bit, and found that this happens when a piece of dust gets into the lens, which steals the focusing of the camera, so it shakes because it oscillates focus from the field of view and the piece of dust. Sadly the camera module needs to be replaced, which can be purchased cheaply but medium tedious difficulty to replace - or pay to have it done not as cheaply.
