Someone who worked more in embedded systems may say something like “everything is ‘just’ a state machine.”
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.
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.
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.
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.
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)
One my standard coding tests for LLM is a spherical geometry problem, a near-triangle with all three corners being 90 degrees.
Until GPT-5, no model got it right, they only operated in the space of a euclidian projection; perhaps notably, while GPT-5 did get it right, it did so by writing and running a python script that imported a suitable library, not with its own world model.
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
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.
I suppose technically a database is just a CRUD app
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.
A lot of apps are just about putting data into a DB and then providing access to that data. Maybe using the data to draw some nice graphs and stuff. That's a crud app.
It's not the Pinnacle of complexity, just more complex than your average app.
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)
The custom text rendering bit alone should have been a good cue for this distinction.
But sure, I’m being too pedantic here I suppose.
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
Everything is a CRUD app if you're high on buzzwords.
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.
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.