Respectfully, I see this as an oversimplification. Though, I can definitely understand why someone would say this and I do agree to some extent.

The thing is, I think there is a lot of subtlety in most implementations. Those subtleties come from unique requirements outlined by the client/business need/ or existing patterns.

As someone who has implemented a lot of CRUD functionality, I can honestly say there is very little code overlap between any two projects. Sure, the frontend calls the same CRUD endpoints. The backend essentially performs the same DB edits... but there's a lot to be considered before and after this. And no, it has nothing to do with just validation. It's about UX, performance, maintainability, extensibility, etc. All considerations when writing the code. When you're done the CRUD project, it's distinct. I think there's empirical evidence for this in the sense that the most we can abstract CRUD, is through CMSs. I've worked with a lot of clients that have great CMSs but still need to retain developers to support the CRUD ops and everything in between.

Is this the same type of "software engineering" employed as someone writing a custom backend for a electronic stock exchange? Likely not, though that's a whole other discussion.

> Most of the developers are just translators from business requirements into react code.

This is where the real software engineering practice takes place, understanding what the business needs while staying within scope and being able to deliver a solution that's functional and maintainable long term.

I see a world in the not-too-distant future where new apps are built entirely by AI, but there will always be a need for people to translate non-technical business requirements into action items and software decisions. And legacy apps developed entirely by AI? Maybe we'll see it my lifetime but I kind of doubt it.

Sounds more like you haven’t worked so far on a sufficiently complicated engineering project otherwise you would know that translating those business requirements is actually the difficult part in the software engineering profession and not coding.

Just expressing the business requirements in a way that can be implemented as software code, with all the edge cases and exceptions covered is the really difficult part.

> business requirements is actually the difficult part in the software engineering profession and not coding.

Both are the diffucult part. Especially since "business requirements" ofent is Agile newspeak for "no spec and fuzzy demands".

I don't see how the translation is easy. If anything, accurate and precise requirements gathering is one of the hardest parts of software. How many times do you 100% correctly interpret client needs. Better yet, how many times does the client even interpret their own needs correctly and then communicate that?

Those "business requirements" vary greatly in their specificity. Dealing with the ambiguity and making reasonable judgment calls is the kind of thing you can usually expect from a more expensive engineer

You may be right up to a certain extent but requirements always have small details which are very specific to the project which will probably be missed by a generalised AI. Also taking care of things like security performance etc it's something that most fresh developers out of bootcamps will fail at. Finally requirements are rarely complete or accurate, meaning you need to have experience in order to interpret them correctly (reading between the lines in a way). So if actual coding is automated via AI at some point in the future, humans will shift from coding to requirements interpretation to feed the AI. Essentially it will be another level of abstraction.

This is completely true. Myself being a software developer. You can only add value by tailoring your code for easier maintainability. Aside from that, you’re just translating business requirements into some program.

Even if that were 100% true, people don't actually know what they want. "Business requirements" undeveloped in the minds of non-technical people are just ideas. There are immeasurable differences between what people think they want, what they actually want, what they need and what can realistically be done. Coaxing these out happens during the whole development process (even in a waterfall approach), because people are never as accurate as they need to be... Otherwise, they would not need software engineeers.

Tech is more than automating business processes 1 to 1. Many times domain experts don’t even know what’s possible, as a dev you need to work together on the requirements to go beyond their imagination.