eddy162

Thanks for replying!

What I'd love is for Auto Mode to show the full diffs one-by-one as they're being implemented in the CLI (or VS Code).

On top of that, an option where Claude explains what it's doing in every step, as if you're watching someone talk while they implement a coding challenge, would be really helpful (and would also reduce interrupting it when it looks like it's deviating from the Plan).

The use-case this would support is to have a full understanding and confidence in what Claude is doing while it's implementing a Plan in Auto Mode. The reason is that it's much less tiring/overwhelming for me to follow along an implementation compared to reviewing a giant PR after the fact, and it's helped reduce my coding fatigue by a lot.

Edit Tool:

Currently I tell it to use the Edit tool because it doesn't reliably show the diffs in Auto Mode (I have the latest version; I've sent numerous feedback reports on this), and later in a session (when implementing my feedback) it will often make multiple edits in some unreadable bash command. So my only option to see the full diffs during implementation and to have it explain/break down bash commands is to go into Manual Mode.

Documentation & Comments:

Even with an initial prompt instructing it so, Claude always needs to be interrupted so that it will rewrite comments to something readable to humans.

While very long "technical"/Claudish paragraph comments and MD files might work for future Claude's (and improve benchmarks/coding scores by making implementations technically more comprehensive), my goal is that a human coder should be able to understand how the codebase (React/Node/Python/Polars) works by reading on their own rather than needing their own AI to summarize everything.

I've even seen it rewrite existing human-written concise comments into blocks of Claude-ish, as if it's trying to make everyone dependent on it in order to do anything to the codebase.

I wonder if an optional built-in skill could help improve this, as I admit I haven't experimented with building any of my own (my concern with customizing Claude.md is to not overload it with too many instructions; I'm on vanilla Claude Code). Note: This is all on Fable on xhigh.

Saying the answer is auto mode almost feels insulting as a developer. Claude loves showing me the most obscure bash commands where it hides its edits to numerous files and runs who knows what that there's barely a time where I don't have to ask it to use edit mode and to show human-readable bash commands. Using Claude has become a fight in maintaining control over how my codebase works so that I'm not dependent on Claude to do literally anything.

Plan mode is what makes it easy for me to update my mental model of the codebase, and helps me decide if the mental overhead of all the changes that are needed are even worth doing, which are now the biggest limiting factors (reading the code diffs just doesn’t scale anymore).

Felt like this read my mind, I was shocked recently at how good Cursor (with Claude) is at answering questions given its Slack/GSuite MCP connections; and a lot faster than Glean. Also amazing to see how this can literally give better answers than some humans would.

Work in the industry: way too many planners and transit consultants are fixating on too many stops as being a problem, likely since it's the one piece of infrastructure they can control when roads and traffic lights are designed for cars not people.

Depending on the road network and land-uses, removing stops only 200-metres apart to make them 400-metres apart (the industry standard) could decrease access to transit within a 5-minute walk by anywhere from 10-50%+, so it's limited to where you can actually apply it without penalizing (ie. putting them outside of a 7-10-minute walk) so many customers that they look for alternatives.

In Europe stop spacings are much longer even for local routes (over 400-800-metres), but this is because everyone generally lives within walking distance for their errands, so transit is used only for longer, more commute-like trips, where a longer walk for faster travel times makes sense. Accessibility is also less of a priority there so they're less sensitive to requests from seniors and those with disabilities, with many buses not being wheelchair accessible. In US/Canada, a lot of transit riders live over a 20-30-minute (often with hostile walking conditions like crossing highway ramps) walk from the nearest grocery store, school, pharmacy, etc., so they'd oppose adding 2-3-minutes of walking to shorten a 10-minute bus ride.

Moreover, closely spaced stops are really only an issue in older (pre-war) downtowns where frequent stops are the result of decades of requests from residents (especially seniors) and from schools/churches/grocery stores/retirement homes/medical clinics. Out in the suburbs, buses usually bypass most stops, and schedules take that into account. And in places with amazing land-use like Pheonix and Vegas, you have long stretches of nothing so of course there'll be higher average stop spacings.

Lastly, much of the time-savings from express routes (that skip stops) and bus stop consolidation/balancing, is from being more in sync with the lights, which are usually designed for through traffic (ie. a green wave). Transit Signal Priority can help achieve significant savings (over 10-30%+) without removing any stops, though moving stops to after the light makes it more effective (and even that can be politically difficult).

Amtrak just added a new train from Minneapolis to Chicago to fix this exact issue as delays on the Empire Builder tend to be worst in the plains/mountains, so hopefully you can give them another chance: https://www.amtrak.com/borealis-train

I'd never heard about Placemark yet this fills a gap I've been seeing in the mapping market having worked in local government - data management in ArcGIS is $$$, awful, and limited to a handful of GIS specialists, while Felt has nowhere near the data capabilities like joining and transformations that Placemark has. The real money in mapping is from enterprise & government, which requires a lot of upfront work to sell to. Hopefully other companies in the space (like Scribble Maps, Felt, or Esri via ArcGIS Online) fill in some of the feature gaps left by Placemark.

This is super super cool! This kind of visualization is so much more useful for finding a transit-friendly spot to live than the generic TransitScores real-estate websites have. Would be nice if the frequency of bus routes could be visualized too, and hope you find a way to add more cities painlessly. Having worked in transit planning, this is really useful for network gap analysis - like finding areas where connectivity could be improved.

Two big differences between taxis and Uber/Lyft, which explain their massive losses and weren’t mentioned by the article:

1. They provide insurance: It’s estimated that around half of Lyft’s operating expenses are for insurance [1], which in their filings is mainly under Cost of Revenue but some settlement expenses and other non-mandatory insurance coverage would be under General & Administrative [2] [3]. This was pretty surprising to me, as I never thought it’d be this much.

2. Costly driver incentives: Technically this is under Sales & Marketing, which is around 10% of expenses [2] [3]. However, Uber/Lyft can choose how much of a commission to take so that the driver keeps driving, so the incentive would then come at the cost of lower revenue.

These are vital to their operations because:

1. Commercial insurance could cost $400-700+ a month [4]; taxi drivers pay this themselves, but Uber/Lyft drivers don’t, paying a much smaller surcharge to their personal auto insurance because Uber/Lyft cover third-party liability during rides.

2. They need lots of drivers driving around in order to provide short wait-times. Outside of city centres, the wait-times for taxis can be pretty long, often requiring a reservation made hours in advance. Uber/Lyft gave people the freedom of owning a car at a price usually not more than $5-15 over a transit fare.

But being able to provide a ride in just a few minutes anywhere in a city even late at night isn't free. For instance, in NYC around 41% of driver time in 2018 was driving around waiting for a ride [5], which they aren't paid for. If there are plenty of drivers, Uber/Lyft can profit off them and let them churn, but if they're needed to properly serve an area or time-of-day (ie. keep wait-times low), that's where retention bonuses and letting them keep more of the fare come in as to motivate them to keep driving.

So in a way, when you're taking or driving a profitable ride where Uber/Lyft are making a large margin (like airport-to-downtown rides), you're subsidizing someone who picked-up or waited five minutes for a ride late at night outside some suburban bar. It's the latter kind of trips that most people wouldn't take a taxi for, having previously been made on transit, a personal car, carpooling, or not made at all.

This is a bit like how public transit works. The customers travelling on packed buses/trains in peaks subsidize those on the emptier late-night buses/trains. But remove that late-night service and some of those customers will buy a car and stop taking transit altogether.

As Uber/Lyft are forced to become profitable during a labour shortage, the profitable trips are becoming more expensive (often more than airport taxis) and the less-profitable trips are getting longer wait-times as less is being spent on driver retention (along with higher prices but maybe not as much because of the increased price-sensitivity of those trips).

This model was unsustainable from the start. Even with AVs, their R&D would explode and they’d have to assume the full cost of operating, maintaining, and insuring their fleet, all of which are currently offloaded to their drivers.

1: https://www.insurancejournal.com/news/national/2019/10/31/54... 2: https://investor.lyft.com/news-and-events/news/news-details/... 3: https://www.sec.gov/Archives/edgar/data/1759509/000156459019... (26-27) 4: https://www.carinsurancecomparison.com/taxi-car-insurance/ 5: https://www.reuters.com/article/us-uber-new-york-idUSKBN1YR1...

Sidenote: Am a transit planner and software dev, so researching ridehailing’s pretty interesting/relevant to me.