I don’t think this is entirely wrong, in that there is a ‘class thing’ about riding the bus, but it’s more practicality than a class marker for a lot of people.
- In SF you can either walk 1-10 minutes to the bus, wait 0-15 minutes for the bus, tap on (while watching most other passengers evade the fare), get dropped off, and then walk 1-10 minutes to your destination… or spend an additional $5-10 to get Ubered door to door at a third of the time. First and last mile are real costs.
- In SF I Uber, unless Muni/BART is a straight shot. In NYC I take the subway. It’s not really a class thing. In NYC it takes longer to Uber much of the time and it costs several more times than the subway. You still have a 1-5 minute first and last mile problem, but headways on trains is decent and above ground taxis are incredibly inconsistent with traffic.
That about matches up with the experience with social groups in similar classes in these areas too. Most of my SF friends Uber. Most of my NYC friends take the subway.
This comment is legit! So many of these comments here are wildly biased to people's own personal experiences (usually the male/female Karens are the most noisy). You make many good points here.
My question(s): Why do you think Uber works so well in SF? Why don't they get trapped on Market Street with crawling speeds?
I lived in NYC (Manhattan) many years ago and I always felt that when I needed a taxi (cold/snow/rain), they were hard to get. As a result, I almost never took a classic yellow cab in NYC/Manhattan.
I’m all for standardization but you could just use this argument to keep any suboptimal status quo in place. XML is good enough and a standard. SOAP is good enough and a standard. etc.
The claim is that Conventional Commits are good enough and standardized enough that having another structure isn’t really worth it. But “worth it” is subjective. I’d say that if you are making commits and reading PRs every work day, and the conventional commits format causes a little bit of friction, that friction can add up. Having another option other than seeing conventional commits as a law of nature gives options for teams who prefer it. (Most teams aren’t generating changelogs anyway.)
The new structure needs to be "better enough" that it overcomes the built-in deficits of the older structure, and it can't introduce so many new problems that make it a net negative.
JSON was definitely a huge improvement in simplicity and readability compared to XML for many contexts. Similarly REST a much better option than SOAP (and all of these are examples of the general over-engineered, design-by-committee architectures that came out of the late 90s/early 00s - see also the original EJB spec - before a larger trend towards simplicity and ease of use won out).
But it this case, a lot of the differences just feel like potayto/potahto, i.e. minor stylistic preferences. And I have been in jobs where more than 50% of my time was doing code reviews, and while often there were e.g. some linter rules or whatever that I found suboptimal, it was a lot easier to just go with it than waste the energy to have the battle over why I think for loops are actually OK.
That seems a bit reductive. Even with humans, there’s a range of interpretations and ways that something can be built or a task completed. Engineers remember stuff so you don’t have to keep repeating yourself. Skills are a way to describe your outcome without similar repetition.
I don’t really buy that Claude Design will remove all the complexity around design. Vibe-coded apps using Claude look simpler because they are simpler. They’re not a gigantic product suite with extremely specific UI components tailored to each use case. The ‘simplicity’ is an illusion coming from conflating the complexity of a bicycle (a vibe coded app) with an airplane (an app like Figma).
Building the same design system component in code versus in Figma is going to be slightly more succinct in code; Figma’s primitives don’t have the sort of conditionals and control flow that code has. But code is much less malleable than drawing on a screen, and creative freedom is harder to achieve in code.
UI can fix the gap where code feels less malleable than Figma, but complexity comes largely from the worlds that humans create, and humans apparently want to create 8 modes for 4 products and 2 light/dark modes. If you want the same setup in Claude, it’ll be a little easier to maintain, but not much less complex.
I admit I'm having a visceral reaction to this analogy. A bicycle is a sophisticated product whose form is almost pure function. Despite being apparenty simple, almost no regular person can draw even a reasonable facsimile of a bicycle from memory ( https://www.youtube.com/watch?v=L0_vXZ-3LFU ). Which is to say, for actually designing a functioning bicycle, the devil is in the details, and details are exactly where vibecoded apps fall down. Our lower bound for this analogy should instead be the downhill go-kart cobbled together from scrap wood you found in the dumpster.
Figma has been in trouble for a while. All the designers at my company switched to Cursor nearly a year ago. They made live mockups that don’t even need a spec to implement, because the expected behavior is already captured in the prototype. Claude Design makes it just marginally easier.
Not to mention all the people hiring UX just because they don't want to deal with it themselves, not because they need something that requires a lot of skill.
Stitch has been around for a few months from hole and it does a better job than this. I bet designers are in the honeymoon phase of people don’t know this exists and this does my whole job phase.
Feels like a lot of them are using Bootstrap, curated Tailwind elements or Wordpress templates. In which case the challenge Anthropic faces is convincing them the extra flexibility and magical "type into prompt" approach to customization of Claude Design is worth the compute cost...
Figma is answering a different question which is "are you prepared to spend time and money on full time designers to have pixel perfect layouts agreed with managers and consistent across platforms" and non-AI tooling has been orders of magnitude faster and cheaper at generating something that looks good enough as end results rather than mockups since before it existed.
Goody | Remote | $150–250K + equity and benefits | US and Canada | Full-time
I'm Mark, the technical co-founder and CTO at Goody. We're building a gifting product that every business can use to recognize employees, retain customers, and accelerate sales. Despite being something everyone does, gifting is one of the areas of commerce yet to be disrupted, and we're working on building the best and most delightful product in this space.
Our product is used by Google, Stripe, Anthropic, Meta, NBCUniversal, Notion, and others, and we also offer a developer API for commerce. Tech stack is Ruby + React + TypeScript, though we're flexible on backend language if you know Python or Node.js better. All roles are full-stack.
We're coming off of a big year and planning for scale in 2026 with openings in our engineering team.
• Staff Software Engineer ($200–250K) — for those who ship at a startup pace and have a great eye for detail
• Senior Software Engineer, Customer Engineering ($150–200K) — if you like to hear a customer request in the morning and tell them it’s shipped in the afternoon
• Senior Software Engineer, Growth ($150–200K) — be the engineer who has the most direct impact on our growth
We're looking for people who have great startup energy, want to win, and bring great vibes to our tight-knit team.
> What’s become more fun is building the infrastructure that makes the agents effective.
Solving new problems is a thing engineers get to do constantly, whereas building an agent infrastructure is mostly a one-ish time thing. Yes, it evolves, but I worry that once the fun of building an agentic engineering system is done, we’re stuck doing arguably the most tedious job in the SDLC, reviewing code. It’s like if you were a principal researcher who stopped doing research and instead only peer reviewed other people’s papers.
The silver lining is if the feeling of faster progress through these AI tools gives enough satisfaction to replace the missing satisfaction of problem-solving. Different people will derive different levels of contentment from this. For me, it has not been an obvious upgrade in satisfaction. I’m definitely spending less time in flow.
If you save 3 hours building something with agentic engineering and that PR sits in review for the same 30 hours or whatever it would have spent sitting in review if you handwrote it, you’re still saving 3 hours building that thing.
So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput (good lord, we better get used to doing more code review)
This doesn’t work if you spend 3 minutes prompting and 27 minutes cleaning up code that would have taken 30 minutes to write anyway, as the article details, but that’s a different failure case imo
> So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput
Hang on, you think that a queue that drains at a rate of $X/hour can be filled at a rate of 10x$X/hour?
No, it cannot: it doesn't matter how fast you fill a queue if the queue has a constant drain rate, sooner or later you are going to hit the bounds of the queue or the items taken off the queue are too stale to matter.
In this case, filling a queue at a rate of 20 items per hour (every 3 minutes) while it drains at a rate of 1 item every 5 hours means that after a single day, you can expect your last PR to be reviewed in ((8x20) - 1) hours.
IOW, after a single day the time-to-review is 159 hours. Your PRs after the second day is going to take +300 hours.
This is the fundamental issue currently in my situation with AI code generation.
There are some strategies that help: a lot of the AI directives need to go towards making the code actually easy to review. A lot of it it sits around clarity, granularity (code should be committed primarily in reviewable chunks - units of work that make sense for review) rather than whatever you would have done previously when code production was the bottleneck. Similarly, AI use needs to be weighted not just more towards tests, but towards tests that concretely and clearly answer questions that come up in review (what happens on this boundary condition? or if that variable is null? etc). Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions. That is, if a change is evidently risk free (in the sense of, "even if this IS broken it doesn't matter) it should be able to be rapidly approved / merged. Only things where it actually matters if it wrong should be blocked.
I have a feeling there are whole areas of software engineering where best practices are just operating on inertia and need to be reformulated now that the underlying cost dynamics have fundamentally shifted.
>Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions.
Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?
Lemme guess, you cargo culted some "best practices" to offload risk awareness, so now your code is organized in "too big to fail" style and matches your vendor's risk profile instead of yours.
> Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?
I guess the answer (if you're really asking seriously) is that previously when code production cost so far outweighed everything else, it made sense to structure everything to optimise efficiency in that dimension.
So if a change was implemented, the developer would deliver it as a functional unit that might cut across several lines of risk (low risk changes like updating some CSS sitting along side higher risk like a database migration, all bundled together). Because this was what made it fastest for the developer to implement the code.
Now if AI is doing it, screw how easy or fast it is to make the change. Deliver it in review chunks.
Was the original method cargo culted? I think most of what we do is cargo culted regardless. Virtually the entire software industry is built that way. So probably.
If your team's bottleneck is code review by senior engineers, adding more low quality PRs to the review backlog will not improve your productivity. It'll just overwhelm and annoy everyone who's gotta read that stuff.
Generally if your job is acting as an expensive frontend for senior engineers to interact with claude code, well, speaking as a senior engineer I'd rather just use claude code directly.
And when the PR you never even read because the AI wrote it gets bounced back you with an obscure question 13 days later ..... you're not going to be well positioned to respond to that.
Goody | Remote | $150–250K + equity and benefits | North/South America | Full-time
I'm Mark, the technical co-founder and CTO at Goody. We're building a gifting product that every business can use to recognize employees, retain customers, and accelerate sales. Despite being something everyone does, gifting is one of the areas of commerce yet to be disrupted, and we're working on building the best and most delightful product in this space.
Our product is used by Google, Stripe, Anthropic, Meta, NBCUniversal, Notion, and others, and we also offer a developer API for commerce. Tech stack is Ruby + React + TypeScript, though we're flexible on backend language if you know Python or Node.js better. All roles are full-stack.
We're coming off of a big year and planning for scale in 2026. We have a few new roles to accelerate our growth.
• Staff Software Engineer ($200–250K) — for those who ship at a startup pace and have a great eye for detail
• Senior Software Engineer, Customer Engineering ($150–200K) — if you like to hear a customer request in the morning and tell them it’s shipped in the afternoon. US and Canada only for this one
• Senior Software Engineer, Growth ($150–200K) — be the engineer who has the most direct impact on our growth
We're looking for people who have great startup energy, want to win, and bring great vibes to our tight-knit team.
Your position detail pages apparently require WebGL to prevent them from "crashing." That and "complex SPA" in the text (found from reader mode) tell me you might very well be overengineered.
I'd say it is quite opposite, a deep understanding of what you like and consequently understanding what will make a creation into exactly what you like. (Well I guess some people can create without understanding, just directly expressing their likes)
Since many of our likes are driven by our shared culture and physiology, many other people will appreciate such creation (even if they don't understand why exactly they like it). Others will appreciate depth of nuance and uniqueness of your creation.
Opposite to taste is approximated "good" average which is likeable but just never hits all the right notes, and at the same time already suffering from sameness fatigue.
It's subjective in the philosophical sense (the subject of the predication is involved with the judgment itself) but that doesn't mean it can't be "right" (and probably more importantly, "wrong").
Everyone who has built software knows that the hardest parts involve making complex, tricky decisions with tradeoffs. Let’s say you make a grocery list app. Now you have to make decisions about all the different ways to specify quantity. Units, weight, dollars, bunches… oh, and fractional vs. decimal weight, etc…
The claim is that now every random person now will build their own app and have to make those hard decisions instead of paying $5 a month for someone else to do that work. Comparative advantage doesn’t just apply to the cost of writing code, but also the effort of making product decisions.
Edit: I don’t mean that a grocery app should cost $5/month, the grocery app was a toy example and the $5/month refers to an example of a separate app you’d pay for with much more value.
This thread hits very close to home for me. I'm engineering the frontend for a grocery list app as a capstone project right now and I'm handling a lot of the product and feature decisions, and the discussion about "just prompt Claude to build it" versus the reality of those decisions is something my team deals with constantly.
The example of reverse-engineering your grocery store's API and building a custom solution is awesome, and it's exactly the kind of thing that's now possible. But what I've found is that even with AI assistance, there are so many interconnected decisions that make this more than a one-shot prompt project.
I pushed for us to build a mobile app specifically to take advantage of portability (use it at home for planning, at the store for shopping) and the camera (image recognition with OpenAI and scanning barcodes with expo-camera). That sounds simple, but it cascades into hundreds of UX decisions about offline-first architecture, gesture patterns, camera permissions, and more.
The units and quantities problem mentioned in this thread is just the tip of the iceberg. I'm trying to figure out a data model that mirrors how people naturally think about groceries: how they categorize items, how they plan meals versus staples versus impulse buys, how they track what's running low. Modeling those mental models is genuinely hard.
What helps is that I worked as an ecommerce shopper at Whole Foods, and I learned that stores are meticulously organized with numbered bays and predetermined routes optimized for efficiency. Translating that knowledge into a system that can intelligently sort a shopping list based on store layout (which varies by location!) and typical shopping patterns is genuinely complex.
One of my teammates put it well: this is a simple idea, but it requires a level of care, expertise, and experience to get it right. AI's incredibly helpful for implementing solutions once we've made these decisions, but the decisions themselves require domain knowledge, user research, and taste. That's the part that's hard to automate, and it's what makes this a real engineering project rather than a weekend Claude experiment.
Some things are just not suited to an app. It's still easier to jot down a shopping list on a piece of paper than to use an app and a janky mobile phone keyboard. And bonus, nobody gets to sell your shopping preferences or blast you with ads as you're trying to use it!
I spent years trying to find the PERFECT pantry tracking, auto shopping list generating, auto "what can I make tonight with what I have", auto meal preping app. The idea seemed so simple in mind back then. Let me input everything I have, then as I pull ingredients out of the fridge I just "decrease eggs by 3, decrease butter by 1tbsp, decrease bacon by 2 slices" then over time, it will just build my shopping list for me etc. I even built a requirement list and spent a year implementing my own thing.
Given the number of apps put there, from dozens of OSS hobbyist apps to industrial resturant inventory management ones, I wan't alone in thinking this is a solved problem and someone should just have the perfect interface for it. Between auto-unit converting apps, natural language processing apps, @cooklang, a million ideas about tracking pantries and ingredients and their categories, frequency of use charts, etc..
Then one time I went on a trip with a friend to his home town where we stayed at his parents house. His 78 year old mother had a 2 notepads attached to the fridge with a pencil on a string. As she worked in the kitchen, between washing hands she would just jot down random notes, cross others, doddles some on one notepad, and the other she would just add meal plans as she went along. Then when we were going to market she just ripped the page off.
Sounds so fucking simple and easy and I felt so stupid for the amount of effort I put trying to figure out the right app, the right device to mount on my fridge, how to connect power to it. How to make it not always on to blind me at night, but also so I don't have to keep fiddling with it to unlock it. how to use it with wet fingers, how to keep translating units and "catch up" when I miss updating it for a couple of meals, how to hide ingredients I don't care about and highlight ones I do, how to rearrange the interface. It seriously gave me a pause at how dumb I was that the solution is much much simpler and I pigeon holed my thinking on a tech solution for some reason.
Can't sell people notepads though. There is no margin or lock-in in that stuff.
I do hear what you're saying, and I've wrestled with "not everything should / can be an app". That being said, I'm still trying to solve food (for myself) with computers, haha.
Right now, that looks like trying to create a nutritionally-optimal "dog food for humans", using combinatorial optimization solvers. I think I'm going to write something up as a post when it becomes a bit more feature-complete.
It's living at chow.seanjohnsen.com if you're curious! Would love feedback from someone who has thought along these lines.
A grocery list app is the perfect example of the kind of thing that AI will make obsolete. Why would I pay $5/month for a list app when I can pay Claude $0.30 one time to make it for me?
I in fact did just that. I used Claude to reverse engineer my grocery store's API and build a grocery list app that automatically pulls in the aisle information for each item and sorts it by how I typically walk through the store. It's the kind of thing that would be incredibly difficult to scale but works just fine when you only have one user. No SaaS grocery app can hope to compete with me being able to tailor my own shopping list app to my exact preferences.
Your grocery store has a free API you can use? Even if that is the case, that will then soon change. If app building becomes "free" then the cost will shift over to the data access.
That is exactly the type of awesome app that can now be built. I edited my comment to clarify that the grocery app and $5/month app are separate examples, but I think your example shows that someone with coding knowledge can build something extremely useful for n=1 users which I fully support.
I just don’t think most people will end up doing that just like how most people don’t 3D print their own desk drawer organizers even when Gridfinity does all the work for you. Automation doesn’t fully replace the volition to build a thing and make tricky decisions that are familiar to us software engineers but not others.
Exactly. I think only software developers believe AI is going to kill app subscriptions, because they're the ones who can actually wrangle the output into something maintainable.
For anyone without dev or product experience, getting beyond a basic feature set and keeping it running reliably (or roll it out to > 1 user) is still a massive challenge.
Yes, that’s a possibility! And for app types that have a limited ceiling of how much value they can provide, that will definitely be a thing as an AI app can saturate all of that value.
But for apps that have a lot of ceiling, people will still gravitate to apps that have had more care and attention than someone vibe coding it once and throwing it on the store, just like how people choose those well-built and maintained apps today over using their built-in Reminders app.
- In SF you can either walk 1-10 minutes to the bus, wait 0-15 minutes for the bus, tap on (while watching most other passengers evade the fare), get dropped off, and then walk 1-10 minutes to your destination… or spend an additional $5-10 to get Ubered door to door at a third of the time. First and last mile are real costs.
- In SF I Uber, unless Muni/BART is a straight shot. In NYC I take the subway. It’s not really a class thing. In NYC it takes longer to Uber much of the time and it costs several more times than the subway. You still have a 1-5 minute first and last mile problem, but headways on trains is decent and above ground taxis are incredibly inconsistent with traffic.
That about matches up with the experience with social groups in similar classes in these areas too. Most of my SF friends Uber. Most of my NYC friends take the subway.
reply