[HN Gopher] "Be Different" doesn't work for building products an...
___________________________________________________________________
"Be Different" doesn't work for building products anymore
Author : grahac
Score : 120 points
Date : 2025-10-06 16:09 UTC (6 hours ago)
(HTM) web link (iamcharliegraham.substack.com)
(TXT) w3m dump (iamcharliegraham.substack.com)
| SCHiM wrote:
| > Your company can scream to anyone that listens that all the
| competition is AI SLOP, but when hundreds of companies are
| pitching the same solution, your one voice will get lost.
|
| If you cannot out compete "AI SLOP" on merit over time (uptime?
| accuracy? dataloss?), then the AI SLOP is not actually sloppy...
|
| If your runway runs out before you can prove your merit over that
| timeframe, but you are convinced that the AI is slop, then you
| should ship the slop first and pivot onec you get $$ but before
| you get overwhelmed with tech depth.
|
| Personally, I love that I can finally out compete companies with
| reams of developer teams. Unlike many posters here, I was limited
| by the time (and mental space) it takes to do the actual writing.
| dmbche wrote:
| What company did you outcompete
| Tade0 wrote:
| Your comment encourages me to make an AI SLOP version of a
| product I had in mind.
| contagiousflow wrote:
| But you're not just trying to out compete one AI slop, you must
| compete with ALL of them. And over time the AI slop to
| thoughtful company ratio is only going to increase
| hkon wrote:
| I don't think it matters for developers. They compete in the
| short term.
| bee_rider wrote:
| It certainly seems possible that AI slop could be flawed in
| some major ways while still competing well in the market:
| security is usually invisible to users until it isn't, similar
| uptime and bugs, accessibility can be ignored if you don't mind
| being an unethical person.
|
| Then again this is also often a flaw with human-generated slop,
| so it is hard to say what any of this really means.
| HappyPanacea wrote:
| > accessibility can be ignored How good are AI-assisted
| accessibility tools now? Is the poison also the cure here?
| pyrale wrote:
| I guess the point is that startups are dead because scaling up
| becomes harder, doesn't mean that organic growth is harder. In
| fact, the potential ways forward offered by the article are not
| really dependent on VC funding.
| constantcrying wrote:
| The honest reading of this is that everyone is able to deliver
| "good enough" and caring has become worthless.
| acephal wrote:
| Yes, this is why the biggest winner of LLMs is off-shoring
| andrewmcwatters wrote:
| Bullshit. Practically an AI slop article itself. The rest of us
| actually building products know reality is different because
| we're intimately familiar with our competitors and their
| limitations.
|
| Copying and playing catch up was possible before AI.
|
| I really wish we could downvote submissions like this. It adds
| nothing of meaning to the discussion of the subtleties of
| competitive product development.
| grahac wrote:
| Sorry. This is totally not AI slop. AI-edited for grammar, but
| human-created.
|
| What industry are you building in? And have you been building
| in it a while or is it a new startup?
| DenisM wrote:
| On a tangent, I sometimes avoid correcting typos and awkward
| expressions because it adds non-ai signal. I do t
| intentionally add any, but I let them be.
| grahac wrote:
| I like that this is a meta comment :)
| cloverich wrote:
| I think this puts the onus in the wrong direction. I _love_
| LLM coding and write probably 70% of my code that way. But
| having seen its (current) limits, and building a few toy apps
| myself, I'd love to see examples of successful, complex
| products that are mostly vibe coded. Until I see that, I'll
| continue to believe the current crop of LLM is best suited
| for building prototypes, helping get initial ideas shipped,
| and helping speed up very experienced developers working in
| well trodden ground (i.e. mostly CRUD in popular languages /
| frameworks), because that's what most peoples experience is
| (at best - many here wouldn't be nearly as generous as my
| takes).
| grahac wrote:
| Look at the AI visibility tools. They all integrate with
| multiple LLM models, include scheduling, management of
| multiple external processes, data parsing, site-scraping,
| graphs, as well as multiple database structures. They need
| retry and error logic, real-time displays and updates, and
| multiple flow UX's, and Stripe integration with webhooks,
| and subscription management.
|
| Same thing with competitor monitoring. These tools require
| scraping multiple sites, checking X, Facebook, Jobs sites,
| Crunchbase, etc, aggregating data and displaying and making
| sense of changes. And the same multi-process management,
| queuing, and Stripe integrations.
|
| A few years ago, these would both fit into businesses
| requiring many months of development to get it all running.
| Now we are seeing dozens of companies emerging in each of
| these categories each month as they take weeks to build.
| And if one finds a cool aha (a new integration or graph or
| UX flow or positioning) the others can quickly follow in a
| week or less of AI-agent coding.
|
| There are dozens of other categories where this is
| happening too.
|
| The hard part of figuring out the nuances of the APIs and
| integrations and retries and AWS integrations and Rabbit MQ
| configurations and corner cases can all be done by AI with
| the right context.
| continuational wrote:
| So where are all the successful AI slop products?
| WesolyKubeczek wrote:
| It's not so much about AI slop being successful, it's about
| non-slop being drowned in slop so much its voice can't be
| heard.
| gsaines wrote:
| This confirms what I've been discovering. I wrote about the
| details here: https://www.georgesaines.com/blog/2025/9/8/why-
| is-b2c-user-a...
|
| Maybe it's just that the AI noise has been cranked to 11, but it
| sure feels like there's something fundamentally different from
| building and selling software today vs the last time I was
| building new products back in 2015. A decade is a long time, but
| it didn't feel nearly so weird even as recently as 2021 / 2022.
| That makes me think it's the AI slop noise, but maybe I'm
| incorrect.
| redmattred wrote:
| I think you may be missing the mark on your conclusions for why
| your products had difficulty acquiring paid users.
|
| People still pay for software, but for high stakes problems
| like finding a new job, managing your mental health, or
| caretaking an aging parent, etc. taking the leap on a not quite
| fully baked product offering seems unrealistic.
|
| Also with Skritter you used a completely different customer
| acquisition strategy. Longform blog content + SEO is a way
| different beast than SEM.
| gsaines wrote:
| Thanks for engaging with this. I'm not trying to troll or be
| sarcastic. Could well be the case that painted door testing
| just doesn't work on B2C. What I learned on Skritter and
| CodeCombat is that if you have a couple of years to devote
| full time to building, it's almost always possible to power
| through bad channel / market fit with good product and build
| a small company.
|
| The problem is that it's not a very good idea to invest in
| that way if you both like money and can hold down a corporate
| job (not saying everyone meets these two criteria BTW).
|
| The 4 steps to epiphany is outdated, and The Mom Test is
| great if you have existing deep industry expertise and
| credibility. If you lack either, though, it's really not
| obvious how anyone tests product ideas without 12+ months of
| investment.
| advisedwang wrote:
| > Where a great idea in a space once had 5-10 competitors,
| hundreds now appear - all competing for attention. Big companies
| used to move slowly, but now a ragtag team of two developers at a
| large firm can whip up something that looks top-of-market to the
| untrained eye in a matter of weeks.
|
| Perhaps I'm out of touch, but I haven't seen this explosion of
| software competition. I'd LOVE to see some new competitors for MS
| Office, Gmail, Workday, Jira, EPIC, Salesforce, WebKit, Mint, etc
| etc but it doesn't seem to be happening.
| Eric_WVGG wrote:
| You're right.
|
| The iOS app store would currently be flooded with newcomers in
| niche spaces -- workout apps, notes, reminders, etc. And games,
| my god, there would be vibed clones of every game imaginable.
|
| It's simply not happening.
| bad_haircut72 wrote:
| Because writing code hasnt been the bottleneck for success on
| the app store in probably a decade, its all how to game
| algorithms / find someone with the power to boost your app
| hobs wrote:
| And the same is true for almost all those names the GP
| posted - they are big because of network effects - most
| people dont have time to evaluate the "quality" of
| software. In the long term the "quality" of software can be
| extremely variable, so mostly people just hitch their
| wagons to existing tools because if everyone else is doing
| it, it must make sense.
| wyre wrote:
| Could Apple's $99 fee to get on the App Store be contributing
| to with holding this flood, or their app review process?
| dpark wrote:
| App Store is already flooded with competitors for every
| simple niche.
|
| That's why this article makes no sense to me. The "Cambrian
| explosion" was the introduction of the app stores on phones.
| There are 2 million apps on Apple's store.
| makeitdouble wrote:
| For JIRA competitors are a dime a dozen. A lot of them are
| targeted at startups and small shops who heard JIRA was hell
| and think their needs are really basic and will be for a long
| time.
|
| The funniest I actually had to deal with was Monday. The very
| premise is that task management is simple and the visual
| interface will reflect that. Bright colors, low information
| density, minimal data model and very screenshotable screens.
| Then when actually using it for a dev team, the first question
| is how long we decide to try it before giving a verdict.
|
| > Gmail
|
| It really depends on what feature you rely on that aren't IMAP.
| If it's Google services integration, they might never be a
| competitor ever, for instance.
| airstrike wrote:
| Some of us are building those... It just takes a little more
| time than vibe-coded AI slop
| kbuchanan wrote:
| I think this list demonstrates the OP's point--entrenched,
| resource-heavy, and reputable firms have and will continue to
| capture most of the markets, not for lack of competition, but
| by ownership over the distribution channels.
|
| Having said that, I don't think it's all AI (this trend's been
| going on for a while), nor do I think startups can't thrive--as
| the pie gets bigger, competitors can carve out yet smaller
| niches, as the OP points out.
| spamizbad wrote:
| Can't say I agree with this article at all. This has not been my
| experience.
|
| I don't quite know how to articulate this well, but there's
| something that I'd call a "complexity cliff" in the software
| business: if you want to compete in certain spaces, you need to
| build very complex software (even if the software, to the user,
| is easy to use). And while AI tools can assist you in the
| construction of this software, it cannot be "vibe coded" or
| copied whole-cloth - complexity, scale, and reliability
| requirements are far too great and your potential customer base
| will not tolerate you fumbling around.
|
| You eventually reach a point where there are no blog posts or
| stackoverflow questions that walk you through step-by-step how to
| make this stuff happen. It's the kind of stuff that your company
| and maybe a few dozen others are trying to build - and of those
| few dozen, less than 10 are seeing actual success.
| grahac wrote:
| If the software is doing complicated integrations, that may be
| a barrier as said in the article.
|
| And to be clear, this is people using teams of Claude Code
| agents (either Sonnet 4.5 or Sonnet 5 and 5.5 in the future).
| Reliability/scale can be mitigated with a combination of a
| senior engineer or two, AI Coding tools like the latest Claude
| Code and the right language and frameworks. (Depending on the
| scale of course) It no longer takes a team senior and mid-level
| engineers many months. The barriers even for that have been
| reduced.
|
| Completely agree that using Lovable, Bolt, etc aren't going to
| compete except as part of noise, but that's not what this
| article is saying.
| Aurornis wrote:
| > there's something that I'd call a "complexity cliff" in the
| software business: if you want to compete in certain spaces,
| you need to build very complex software (even if the software,
| to the user, is easy to use)
|
| I recognized something similar when I first started
| interviewing candidates.
|
| I try to interview promising resumes even if they don't have
| the perfect experience match. Something that becomes obvious
| when doing this is that many developers have only operated on
| relatively simple projects. They would repeat things like
| "Everything is just a CRUD app" or not understand that going
| from Python or JavaScript to C++ for embedded systems was more
| complicated than learning different syntax for your if blocks
| and for loops.
|
| The new variant of this is the software developer who has only
| worked on projects where getting to production is a matter of
| prompting an LLM continuously for a few months. Do this once
| and it feels like any problem can be solved the same way. These
| people are in for a shock when they stray from the common path
| and enter territory that isn't represented in the training
| data.
| sfn42 wrote:
| I'm in that boat, everything is just a crud app. I've worked
| on some fairly complex apps but at their core they were crud
| apps and most of their complexity were caused by bad
| developers overcomplicating and fumbling things.
|
| That's not to say something like Figma isn't on an entirely
| different level, but most apps aren't Figma and don't need to
| be. Most apps are simple crud apps and if they aren't it's
| usually because the devs are bad.
|
| It's also worth noting that a crud app can be quite complex
| too. There can be a lot of complexity even if the core is
| simple.
|
| I also think that those of us who can recognize simple apps
| for what they are and design them simply are also the people
| best equipped to tackle more complex apps. Those guys who can
| make a simple crud app into an incomprehensible buggy monster
| certainly can't be trusted with that kind of complexity.
| pixl97 wrote:
| Sometimes complexity exists because what you're doing is
| complex and their is a minimum to how simply it can be
| abstracted.
| sfn42 wrote:
| Yeah, but based on my own experience, most of the time
| complexity exists because devs suck. I know because I've
| simplified lots of code written by others, because
| rewriting it is simpler than maintaining their huge mess.
| SoftTalker wrote:
| Or because they used the project as an excuse to learn a
| complicated but (in this case) unnecessary framework or
| technology stack as an resume enhancer.
| Aurornis wrote:
| > Most apps are simple crud apps and if they aren't it's
| usually because the devs are bad.
|
| I heard this a lot from candidates who had only worked on
| software that could be described as an app. They bounced
| from company to company adjusting a mobile app here,
| fitting into a React framework there, and changing some
| REST endpoints.
|
| There is a large world of software out there and not all of
| it is user-facing apps.
| airstrike wrote:
| I agree 100%. IMHO this is the software that is vibe-
| codeable, by the way.
| jasode wrote:
| _> I heard this a lot from candidates who had only worked
| on software that could be described as an app. _
|
| Similar to that thinking, I made a previous comment how
| many developers in the "L.O.B. Line-Of-Business / CRUD"
| group are not familiar with "algorithms engineering" type
| of programming:
| https://news.ycombinator.com/item?id=12078147
|
| Vibe coding is easiest for CRUD apps. However, it's
| useless for developing new scientific/engineering code
| for new system architectures that require combining
| algorithms & data structures in novel ways that Claude
| Code has no examples for.
| h3half wrote:
| I can attest to that. I was using Gemini to help with
| some spherical geometry that I just couldn't figure out
| myself. This was for an engineering system to define and
| avoid attitude deadzones for a system that can rotate
| arbitrarily.
|
| About 75% of the time the code snippets it provided did
| what it said they did. But the other 25% was killer.
| Luckily I made a visualization system and was able to see
| when it made mistakes, but I think if I had tried to vibe
| code this months ago I'd still be trying.
|
| (These were things like "how can I detect if an arbitrary
| small circle arc on a unit sphere intersects a circle of
| arbitrary size projected onto the surface of the unit
| sphere". With the right MATLAB setup this was easy to
| visualize and check; but I'm quite convinced it would
| have taken me a lot longer to understand the geometry and
| come up with the equations myself than it actually took
| me to complete the tool)
| wyre wrote:
| is Claude Code actually useless or is is a prompt
| engineering/context issue?
| strken wrote:
| Do you have any advice for entering group 2? I graduated
| university expecting to at least _see_ jobs that needed
| those skills at least some of the time, but the hardest
| problem I 've worked on was a variant of the knapsack
| problem and it happened in my first year out.
| kakacik wrote:
| I haven't done anything with an UI for decade and a half.
| Backend integrations, data transformations, piping,
| transfer protocols and so on. Javascript hell avoided so
| far. No thank you
| tracker1 wrote:
| Just to interject one bit... I actually really like JS/TS
| for basic data transformations, piping and ETL type work
| in general. If you understand how type coercion works
| with JS it can be really powerful as a tool for these
| types of workloads.
| samrus wrote:
| Agree
|
| I work on a vision based traffic monitoring system, and
| modelling the idea of traffic and events goes into so
| much complexity without a word of code written
|
| These people are working on problems that have tutorials
| online and dont know that someone had to make all that
| trcf22 wrote:
| Why wouldn't figma be considered a crud app? It's still
| basically adding and updating things in a DB no? With some
| highly complex things like rendering, collab and stuff.
| (Fair question btw)
| airstrike wrote:
| It's very, very far from a CRUD app or "just updating a
| DB". GUI-heavy apps are notoriously hard to get right.
| Any kind of "editable canvas" makes it 10x harder. Online
| collaboration is hard, so that's another 10x--there are
| known solutions, but it's an entire sidequest you have to
| pour a massive amount of effort into.
|
| Custom text editing and rendering is really hard to do
| well.
|
| Making everything smooth and performant to the point it's
| best-in-class while still adding new features is...
| remarkable.
|
| (Speaking as someone who's writing a spreadsheet and
| slideshow editor myself...among other things)
| dpark wrote:
| It is a CRUD app, though, which is why that
| classification isn't generally meaningful. CRUD basically
| just means the app has persistent storage.
| zdragnar wrote:
| "Having CRUD operations" and "Just a CRUD app" are very
| different things.
|
| The custom text rendering bit alone should have been a
| good cue for this distinction.
| dpark wrote:
| That was the point. It _is_ a CRUD app but it is not
| _just_ a CRUD app.
| airstrike wrote:
| When people say "a CRUD app" they mean "an app that is
| mostly just CRUD"
| zdragnar wrote:
| I'm trying to imagine a scenario with a non-trivial app
| that is missing a create, read, update or delete
| operation. I'm coming up with so few examples that I have
| to imagine the colloquial use of CRUD app means _just_
| CRUD operations.
| samrus wrote:
| You should look into figma. Its one of the few marvels of
| software engineering made in recent times.
|
| If you want to know how tough realtime editing is, try
| making a simple collaborative drawing tool or something.
| Or an online 2 player text adventure game
|
| Theres a reason tutorials for those arent common
| throwaway7783 wrote:
| What makes Figma more complex?
| sfn42 wrote:
| Collaboration and the whole editor UI in general is a
| much more complex task than your average glorified PDF
| with some dynamically rendered data.
|
| It's not the Pinnacle of complexity, just more complex
| than your average app.
| tracker1 wrote:
| I'd say the multi-user aspects and level of scale add
| quite a lot of complexity in to the mix.
| trenchpilgrim wrote:
| Check out their old blog post on how they got real-time
| collaborative editing without conflicts to work:
| https://www.figma.com/blog/how-figmas-multiplayer-
| technology...
| bawolff wrote:
| > It's also worth noting that a crud app can be quite
| complex too. There can be a lot of complexity even if the
| core is simple.
|
| I suppose technically a database is just a CRUD app
| sfn42 wrote:
| Yeah, that's essentially what I mean when I say crud app.
| It's basically a web api written in something like C# or
| whatever you prefer, which receives HTTP requests and
| translates them into DB operations. CRUD and views
| basically.
|
| For this type of development you want the DB to handle
| basically all the heavy lifting, the trick is to design
| the DB schema well and have the web API send the right
| SQL to get exactly the data you need for any given
| request and then your app will generally be nice and
| snappy. 90-99% of the logic is just SQL.
|
| For the C# example you'd typically use Entity Framework
| so the entirety of the DB schema and the DB interaction
| etc is defined within the C# code.
| tracker1 wrote:
| I prefer to just use Dapper for most DB interactions with
| C#... EF (and ORM tooling in general) can come with a lot
| of gotchas that simply understanding the SQL you are
| generating can go a long way to avoid.
| sfn42 wrote:
| Dapper is nice, but what you don't get as far as I know
| is migrations. With EF the app just spins up the whole DB
| from scratch which is great for onboarding or when you
| just needed a new laptop etc. Also EF is fine as long as
| you know what you're doing, or at least pay attention to
| what you're doing.
| tracker1 wrote:
| I use grate for migrations. I prefer a more manual, hands
| on approach to that as well.
| chihuahua wrote:
| I think you're missing the point of the comment you've
| replied to. That comment is talking about implementing
| the DB. When you're implementing a DB, you can't just
| forward reads and writes to another DB. Someone has to
| actually implement that DB on top of a filesystem, raw
| disk, or similar storage.
| aliher1911 wrote:
| With the post's logic if you work on DB you likely have
| an SQL engine that is a CRUD on top of storage engine.
| And storage engine is a CRUD on top of some disk storage,
| which is CRUD over syscalls on files. Think Mysql using
| MyRocks using RocksDB. And keep applying until there's no
| sense left.
| bawolff wrote:
| I was actually going for the opposite point - databases
| generally meet the definition of CRUD app. You create
| rows, read them, update them and delete them (literally
| SQL verbs INSERT, SELECT, UPDATE, DELETE). But they are
| highly complex pieces of software. People who program
| them are generally hard core.
| ben_w wrote:
| > I'm in that boat, everything is just a crud app. I've
| worked on some fairly complex apps but at their core they
| were crud apps and most of their complexity were caused by
| bad developers overcomplicating and fumbling things.
|
| Far too much of my recent work has been CRUD apps, several
| with wildly and needlessly overengineered plumbing.
|
| But not all apps are CRUD. Simulations, games, and document
| editors where the sensible file format _isn 't_ a database,
| are also codebases I've worked on.
|
| I think several of those codebases would also be vulnerable
| to vibe coding*; but this is where I'd focus my attention,
| as this kind of innovation seems to be the comparative
| advantage of humans over AI, and also is the space of
| innovative functions that can be patented.
|
| * but not all; I'm currently converting an old C++ game to
| vanilla JS and the web, and I have to carefully vet
| everything the AI does because it tends to make un-
| performant choices.
| munchbunny wrote:
| > I try to interview promising resumes even if they don't
| have the perfect experience match. Something that becomes
| obvious when doing this is that many developers have only
| operated on relatively simple projects. They would repeat
| things like "Everything is just a CRUD app" or not understand
| that going from Python or JavaScript to C++ for embedded
| systems was more complicated than learning different syntax
| for your if blocks and for loops.
|
| I agree and disagree here. IMO the sign of experience is when
| you understand which details really matter, and which details
| are more or less the same across the different stacks, and
| also when they don't know enough yet to differentiate and
| need to ask someone else.
| bodhi_mind wrote:
| Saying everything is a CRUD app is a reflection on the level
| of abstraction a developer usually works in.
|
| Someone who worked more in embedded systems may say something
| like "everything is 'just' a state machine."
| rhines wrote:
| It's also IMO valid. CRUD isn't derogatory. It's also not
| particularly illuminating though. Almost everything _is_ a
| CRUD app. If you get the fundamental data structures,
| access patterns, and control flow right for those CRUD
| operations, you have the foundations for what can be a
| successful app. And then you enhance it further - games add
| nice graphics, collaborative workspaces add good conflict
| resolution, social media sites add addictive recommendation
| systems. The core is CRUD but that doesn 't mean the work
| stops there.
| SAI_Peregrinus wrote:
| Embedded systems using memory-mapped I/O are just dozens of
| CRUD apps, each "register" in the memory map. You don't even
| need to worry about the C & D parts, just read & update. We
| can structure each peripheral's access via a microservice...
|
| Everything is a CRUD app if you're high on buzzwords.
| nomel wrote:
| What's the endpoint for the interrupt service? Does it use
| OAuth?
| araes wrote:
| Not actually critiquing the comment, just somewhat for my own
| memory and ref, there's several other "verbs" attached to a
| lot of those systems.
|
| B / L / S - Browse / List / Summarize, M / T - Move /
| Transfer, C / R - Copy / Replicate, A / E - Append / Expand,
| T / S - Trim / Subtract, P - Process, possibly V / G / D -
| Visualize / Graph / Display
|
| There's probably others that vary from just a Create (POST,
| PUT), Read (GET), Update (PATCH), Delete (DELETE) the way
| they're interpreted in something like REST APIs.
| DenisM wrote:
| >You eventually reach a point where there are no blog posts or
| stackoverflow questions that walk you through step-by-step how
| to make this stuff happen.
|
| I wonder if we can use this as a"novelty" test. If AI can
| explain or corect your ideas, it's not a novel idea.
| FredPret wrote:
| This is exactly right and is what one would expect from
| improving technology. A fractal frontier of new niches crack
| open as the economy keeps expanding.
| ozim wrote:
| Agree. This blog entry has vibes of: ,,I am software developer
| so I am so smart I can do everything and I can definitely make
| revolutionary healthcare app".
|
| Ignoring actual complexity of things, regulations and fact that
| there are areas that no one will take seriously some vibe coder
| and you really have to breath in out and swim with the right
| fish to be trusted and considered for making business with.
| tylerg wrote:
| Umm... Complexity (especially with integrations) and
| regulations were two areas explicitly mentioned in the
| article as areas where you can still differentiate.
| SoftTalker wrote:
| Also areas where large incumbents will keep upstarts out
| via regulatory capture.
| jayd16 wrote:
| Isn't this agreeing with the article? You can't just build
| something and hope for a market, you need to invest heavily to
| have a chance. You both are saying that, no?
| layer8 wrote:
| I think GP is saying that this was already the case before
| LLMs. I.e. LLMs are only helping with things that were never
| part of a moat to begin with.
| j45 wrote:
| There's a lot of ways to define different.
|
| It's a poor choice of word to use as a clearly and universally
| understood axiom.
|
| Doing only what AI can generate will only generate the average
| of the corpus.
|
| Maybe it's part of the reason folks with some amount of
| meaningful problem solving experience, when added to AI are
| having completely different results, there is someone behind
| the steering wheel actually pushing and learning with it and
| also directing it.
| erans wrote:
| true that there is a some kind of a ceiling of what can or
| can't be done. But that ceiling is way up there. Also, there
| are enough examples and articles and code that allows enough
| combination to be made so that its _good enough_ - and that is
| a very important bar.
|
| There are A LOT of businesses (even big ones managing money and
| what not) that rely on spreadsheets to do so much. Could this
| have been an app/service/SaaS/whatever ? probably.
|
| What if these orgs can (mostly) internally solidify some of
| these processes? what if they don't need an insanely expensive
| salesforce implementor that can add "custom logic" ?
|
| A lot of times companies will replace "complex software" with
| half complex process!
|
| What if they don't need Salesforce at all because they need a
| reasonable simple CRM and don't want to (or shouldn't) pay
| $10k/seat/year ?
|
| There are still going to be very differentiating apps and
| services here and there, but as time move on these
| "technological" advantages will erode and with AI they erode
| way faster.
| fny wrote:
| I'm going to give a very concrete example of this so people can
| understand.
|
| I built a fitness product eons ago where there a million rules
| that determined what should happen for prescribing exercises to
| athletes (college/pro teams).
|
| If you gave this to an agent today, you will get a tangled mess
| of if statements that are impossible to debug or extend. This
| is primarily because LLMs are still bad at picking the right
| abstraction for a task. The right solution was to build a rules
| engine, use a constraint solver, and use some combinatorics.
|
| LLMs just don't have the taste to make these decisions without
| guidance. They also lack the problem solving skills for things
| they've never seen.*
|
| Was 95% of the app CRUD? Sure. But last I checked, CRUD was
| never a moat.
|
| *I suspect this part of why senior developers are in extremely
| high demand despite LLMs.
|
| ---
|
| Another example: for many probability problems, Claude loves to
| code up simulations rather than explore closed form solutions.
| Asking Claude to make it faster often drives it to make coding
| optimizations instead of addressing the math. You have to guide
| Claude to do the right thing, and that means you have to know
| the right thing to do.
| abraae wrote:
| I think there's truth in what you say (though if you are
| building something where you rely on blog posts you are
| probably doomed anyway).
|
| But AI has huge value in gratuitously bulking out products in
| ways that are not economically feasible with hand coding.
|
| As an example we are building a golf launch monitor and there
| is a UI where the golf club's path is rendered as it swings
| over the surface.
|
| Without AI, the background would be a simple green #008000
| rectangle.
|
| With AI I can say "create a lifelike grass surface, viewed from
| above, here the individual blades of grass range from 2-4 mm
| wide and 10-14mm length, randomly distributed, and are densely
| enough placed that they entirely cover the surface, and shadows
| are cast from ...".
|
| Basically stuff that makes your product stand out, but that you
| would never invest in putting a programmer onto. The net result
| is a bunch of complex math code, but it's stuff no human will
| ever need to understand or maintain.
| layer8 wrote:
| Your example either supports "be different", because the
| competition won't think of it or won't come up with the right
| prompting, or it supports TFA, because it's easily replicated
| by the competition. It's not clear which one you're arguing
| for, given that GP argues against TFA.
| Theodores wrote:
| I don't agree with the article either.
|
| My view is that every company has its own DNA and that the web
| presence has to put this DNA in code. By DNA, I mean USP or
| niche. This USP or niche is tantamount to a trade secret but
| there doesn't even have to be innovation. Maybe there is just
| an excellent supplier arrangement going on behind the scenes,
| however, for projects, I look for more than that. I want an
| innovation that, because I understand the problem space and the
| code platform, I can see and implement.
|
| A beginner level version of this, a simple job application
| form. On the backend I put the details from the browser session
| into form data. Therefore, HR could quickly filter out those
| applying for a local job that lived in a foreign country. They
| found this to be really useful. Furthermore, since some of our
| products were for the Apple ecosystem, I could get the
| applicant's OS in the form too, plus how long they agonised
| over filling in the form. These signals were also helpful.
|
| To implement this I could use lame Stack Overflow solutions.
| Anyone scraping the site or even applying had no means of
| finding out if this was going on. Note the 'innovation' was not
| in any formal specification, that was just me 'being
| different'. In theory, my clumsy code to reverse lookup the IP
| address could have broken the backend form, and, had it done
| so, I would have paid a price for going off-piste and adding in
| my own non-Easter Egg.
|
| I would not say the above example was encoding company DNA, but
| you get the idea. How would this stack up compared to today's
| AI driven recruitment tools?
|
| As a candidate I would prefer my solution. As the employer, I
| too would prefer my solution, but I am biased. AI might know
| everything and be awesome at everything, however, sometimes
| human problems require human solutions and humans working with
| other humans to get something done.
|
| Would I vibe code the form? Definitely no! My form would use
| simple form elements and labels with no classes, div wrappers
| or other nonsense, to leverage CSS grid layout and CSS
| variables to make it look good on all devices. It took me a
| while to learn to do forms this way, with a fraction of the
| markup in a fraction of the time.
|
| I had to 'be different' to master this and disregard everything
| that had ever been written on Stack Overflow regarding forms,
| page layout and user experience.
|
| AI does not have the capability to do super-neat forms like
| mine because it can't think for itself, just cherry-pick Stack
| Overflow solutions.
|
| I liken what you describe with running out of Stack Overflow
| solutions to hill walking ('hiking'). You start at the base of
| the trail with vast quantities of others that have just stepped
| out of the parking lot, ice cream cones in hand. Then you go a
| mile in and the crowd has thinned. Another mile on and the
| crowd has definitely thinned, big time. Then you are on the
| final approach to the summit and you haven't seen anyone for
| seemingly hours. Finally, at the summit, you might meet one or
| two others.
|
| Stack Overflow and blog posts are like this, at some stage you
| have to put it away and only use the existing code base as a
| guide. Then, at another level, you find specifications,
| scientific papers and the like to guide you to the 'summit'. AI
| isn't going to help you in this territory and you know you
| haven't got hundreds of competitors able to rip off your
| innovation in an instant.
| jlarocco wrote:
| It actually sounds like you agree with the article quite a bit.
|
| If your product doesn't solve problems on the difficult side of
| the "complexity cliff" then vibe coders will copy it and drive
| your profit to zero.
| ErigmolCt wrote:
| I think the article is more reflective of the low-to-mid
| complexity product landscape, where surface-level features
| dominate and differentiation is minimal. But you're absolutely
| right: once you're building something that touches real-world
| complexity, there's a massive moat that AI tools can't easily
| bridge
| tylerrobinson wrote:
| This article is based on vibes just like the trends it
| hypothesizes.
|
| To pick just one claim:
|
| "Big companies used to move slowly, but now a ragtag team of two
| developers at a large firm can whip up something that looks top-
| of-market to the untrained eye in a matter of weeks."
|
| This is just pure speculation with no consideration of success or
| longevity. Big companies are going faster now? Where? Which ones?
|
| AI coding allows you to build prototypes quickly. All the reasons
| big companies are slow haven't budged.
| rafaelero wrote:
| Even with all these tools available, big companies would still
| be unable to compete in speed simply because in 99% of cases
| they don't have the required culture set in place.
| nonethewiser wrote:
| >This is just pure speculation with no consideration of success
| or longevity. Big companies are going faster now? Where? Which
| ones?
|
| Yes but there is a more fundamental problem. The claim doesnt
| even make sense:
|
| >"Big companies used to move slowly, but now a ragtag team of
| two developers at a large firm can whip up something that looks
| top-of-market to the untrained eye in a matter of weeks."
|
| That was never the problem. I mean really, what is the
| implication of this? That big companies moved slowly because
| the developers were slow? What? No one thinks that, including
| the author (I imagine).
|
| Its from many layers of decision-making, risk aversion,
| bureaucracy, coordination across many teams, technical debt,
| internal politics, etc.
|
| This manifests as developers (and others) feeling _slowed down_
| by the weight of the company. Developes (and others) being
| relatively fast is precisely how we know the company is slow.
| So adding AI to the development workflow isn 't going to speed
| anything up. There are too many other limiting factors.
| ErigmolCt wrote:
| Yeah, the line about big companies suddenly moving fast felt
| more like wishful thinking than grounded observation
| Dig1t wrote:
| I see this as a great thing. Venture Capital has been way too
| focused on software for a long time. It's time for the money in
| tech to start flowing to other things like hardware, biotech,
| etc. we've seen this start happening for a little while already
| with companies like Anduril, but hopefully it will continue
| accelerating because of this.
| nradov wrote:
| VC money never stopped flowing to biotech. It just doesn't get
| as much attention on HN.
|
| https://www.fiercebiotech.com/biotech/fierce-biotech-fundrai...
| kibwen wrote:
| _> The result is a Cambrian explosion of software launches._
|
| This software... Is it in the room with us right now?
| mlinhares wrote:
| People have been using chatgpt so much they completely
| disconnected from reality.
| jatins wrote:
| Would actually be interesting to see if there is some product
| hunt or Launch HN stats that prove/disprove this
| sarchertech wrote:
| There was an article that made it the front page of HN a few
| weeks ago that showed that there hasn't been an explosion of
| new software.
| gatinsama wrote:
| I think you mean this one:
|
| Where's the shovelware? Why AI coding claims don't add up
| https://mikelovesrobots.substack.com/p/wheres-the-
| shovelware... https://news.ycombinator.com/item?id=45120517
| Kiro wrote:
| 10% of all new websites are built with Lovable. I presume it's
| mostly broken shovelware but still an explosion of launches.
| danjl wrote:
| > Where a great idea in a space once had 5-10 competitors
|
| This article feels like it is targeted at drop shippers,
| competing on brand or maybe derivative features, rather than
| ideas.
| rchaud wrote:
| Vibe coded apps might do OK in the $5/mo product space (assuming
| people pay that instead of staying in the free tier) but will
| fall apart for anything even resembling B2B.
|
| Buying business tools comes with the expectation of support and
| customization, the complexities of which become unmanageable when
| the lead developer is AI.
|
| You don't hear much about WYSIWYG app builder platforms like
| Bubble.io anymore because once the hype subsided, it was clear
| that it wasn't scalable beyond extremely limited CRUD
| functionality.
| gitmagic wrote:
| > So what does work?
|
| I would add hardware products to that list. While they also have
| become somewhat easier and cheaper to create, the threshold is
| still much higher than for software and SaaS products.
| makeitdouble wrote:
| An asterisk to this: SEA competition is way fiercer than people
| in the west give it credit for.
|
| There's more and more product that I wish existed, and one
| search in AliExpress returns me what I exactly wanted plus some
| more. 5 years ago the product just existed and quality was meh,
| nowadays it's pretty much on par.
|
| I had to recently look for camera gear, and the amount of
| adapters or quirky tripods is just great. Ulanzi for instance
| is a pretty well known brand at this point.
| calmbonsai wrote:
| I completely disagree. "Be Different" was never an actual selling
| point. Being "simple and effective" for the user was and still
| is.
|
| While one can vibe-code simple CRUD at scale, one can not vibe-
| code the complex infrastructural coordination, security
| guardrails, and reliability externalities that maintain an
| effective business model at scale.
| thenanyu wrote:
| there's this things that happens where blog boys love to say Big
| Important Stuff (that isn't true) and in the 1% chance that it
| becomes true they point back on it and say "I am a goddamned
| genius" and if it hits the 99% no one remembers their bullshit.
| karmakaze wrote:
| Buying a vibe coded app is like buying something that looks like
| what you want from AliExpress. There's a small chance it might be
| good enough for your needs and you get a good deal. I might buy
| some small thing there that I don't care much about, or take a
| chance if I can't find anything close anywhere else. But for
| things I do care about I'll go through curated channels to filter
| out the fluff.
| tracker1 wrote:
| Or you pay $39 for what is supposed to be a hand tool, but is
| something the size of an earing that gets delivered.
| Joel_Mckay wrote:
| Most modern software are a type E-program :
|
| https://en.wikipedia.org/wiki/Lehman's_laws_of_software_evol...
|
| AI Slop only has relevance to those that imagine meaning in
| syntactically correct nonsense. =3
| carabiner wrote:
| The audience is everything bit is so true. In 2016, people paid
| $100k to dig a hole: https://www.npr.org/sections/thetwo-
| way/2016/11/27/503502142...
| nonethewiser wrote:
| I guess the argument they make for why "Be Different" doesnt work
| any more is because people can use AI to copy it.
|
| I actually think AI just makes products converge onto whatever
| the AI averages out to.
|
| It would be interesting to see this explored further. It seems
| like being different might actually have an even more pronounced
| effect now (for good or bad).
| keiferski wrote:
| At some point, the idea of a verified, trustworthy review
| platform will need to make a comeback.
|
| The easier it is to make a software product, the harder it will
| be to differentiate between what's good and what's hastily
| assembled.
| ErigmolCt wrote:
| When hundreds of tools look polished but behave inconsistently,
| trust becomes the differentiator
| nachox999 wrote:
| maybe 'Being different' for building products means doing
| physical products in 2025
| roncesvalles wrote:
| >The result is a Cambrian explosion of software launches.
|
| Citation needed. There was a HN post a few weeks ago (I've lost
| it since) that said there isn't actually a measurable increase in
| App Store submissions and other such metrics to indicate that
| more software applications are being launched, in the last few
| years.
|
| Also, in my view one of the most overlooked moats that incumbent
| software companies have is product quality. You can't upset Uber
| and Lyft primarily because you don't have the resources/skills to
| build an app _of that quality_ (and your VC doesn 't trust you
| can build one even given the resources). It's not due to business
| dev, marketing or "network effect" reasons; a lot of drivers tag-
| team both Uber and Lyft anyway, it doesn't cost them anything to
| onboard into a 3rd app even if it initially yields them 1
| passenger a week.
| Animats wrote:
| Would someone please name a few products in this space, where
| there's a glut of vibe-coded apps? Thanks.
| WA wrote:
| Not names, but categories: Habit trackers, period calendars,
| journaling apps, calorie trackers, workout tracking apps,
| symptom trackers, budget planning apps, tax/tip calculators,
| meditation apps, productivity timers, recipe collection apps,
| affirmation / inspiring quotes apps, SaaS boilerplates, social
| media scheduling tools, AI chat bot, AI wrappers for all of the
| above.
|
| You'll find hundreds of apps for every single keyword. But on
| the other hand, it's still a winner takes all market, so the
| top 1-5 per category make ~95% of revenue.
|
| Edit: To clarify, imho these categories have been popular
| forever, because that's what every new indie dev thinks about
| first when they have a "great" idea. They're not necessarily
| tied to vibe coding and would've been released even without AI.
| SeeManDo wrote:
| The first sentence in this article made it unreadable as it
| contained "red ocean"
|
| tldr; typical corporate software development babblespeak slop
| jiveturkey wrote:
| It's quite hilarious to see the top comment thread is the "punch
| is just a punch" (or now: bell curve meme) unfolding in real
| time.
| autonomousErwin wrote:
| I'm becoming more convinced that this kind of rhetoric is usually
| peddled by individuals who haven't actually built anything
| notable (granted, that's most of us).
|
| If all you're doing is using AI to build products, by definition,
| you're gravitating to the mean.
|
| The AI doesn't care about a delightful product, it cares about
| satisfying its objective function and the deeper you go the more
| the two will diverge simply because building a good product is
| _really_ complex and there are many many paths in the decision
| maze.
| mfdupuis wrote:
| > The best way to avoid the red ocean is to build for an obscure
| and complex niche.
|
| This seems like the counter-argument... You need to build
| something incredibly different. You need to message differently,
| you need to distribute differently.
|
| If the argument is that convincing the world that you're
| different is harder than ever I buy that. So much fluff and noise
| out there that it's harder than ever to break through that noise
| and cut through the skepticism. But for that, it's more important
| than ever to be different.
| abnercoimbre wrote:
| Are you working towards this? What examples do you have in
| mind? (I agree with your thesis btw)
| ghc wrote:
| I think this is meant to be satire, but it's subtle enough that
| it went over a lot of heads here. Well, that or I'm reading too
| much into it, but...
|
| Everything the author said was just as true pre-GPT. He's
| imparting basic business knowledge under the guise of "oh, now
| that there's this AI thing, you can't just build it have users
| show up."
___________________________________________________________________
(page generated 2025-10-06 23:01 UTC)