[spamizbad]

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.

[Aurornis]

> 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]

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.

[bodhi_mind]

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.”

[araes]

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.

[SAI_Peregrinus]

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.

[munchbunny]

> 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.

[fny]

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.

[ErigmolCt]

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

[erans]

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.

[DenisM]

>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.

[ozim]

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]

Umm... Complexity (especially with integrations) and regulations were two areas explicitly mentioned in the article as areas where you can still differentiate.

[grahac]

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.

[jlarocco]

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.

[j45]

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.

[beachy]

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]

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.

[jayd16]

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]

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.

[FredPret]

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.

[Theodores]

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.