It's not hard to pick holes in this approach by showing the code being generated is flawed. Also, code quality is different from code velocity, better to write 10 lines that more accurately describes functionality than 50.

PMs now expect that you can create a Java micro service that does basic REST/CRUD from a database and get it into production in a total of two days.

That is hard if you are working in Notepad and have to write your own class import statements and write your own Maven POM or Gradle file. It’s a lot quicker in an IDE with autocomplete and auto-generated Maven POMs. And with AI it’s even faster but at the risk of lower code maintainability.

> PMs now expect that you can create a Java micro service that does basic REST/CRUD from a database and get it into production in a total of two days.

Have you heard of malicious compliance? Give the PMs what they ask for, then show them how what they've asked for is flawed. Your job as an engineer is not to just take orders blindly, it's to push for a better engineered solution. It's really not hard to show that what these PMs are asking for is stupid.

A new micro-service in two days is easy with an IDE and autocomplete. But now with AI the PM will likely push to have it in production in a day. Which is possible, but quality will be questionable.

> A new micro-service in two days is easy with an IDE and autocomplete.

Is your username accurate, are you currently retired? I hope you know there's a big difference between something that is functional and something that is production ready.

Somewhat retired last year. Looking for something new to do. Basic Java micro service with Spring Boot ands it is three hours of coding to write and read from a database and expose over REST interface. Two hours for a tests. Rest of the time is to set up environments, coupling everything, documentation. Two days is do-able if you have a good CI/CD template and your Azure/AWS is setup correctly.

I hope the companies you worked for had someone else taking care of security, as what you've described is a ransomware writer's wet dream.

You have a gateway / platform for that. You aren’t exposing those services to the internet.

> You aren’t exposing those services to the internet.

You aren’t knowingly exposing those services to the internet.

FTFY. Furthermore, internal services can still be abused to get data that shouldn't be shared. For example, imagine if your imaginary API was for a HR system, and could be used to determine salary information for staff.

If you aren't considering API security, you're almost bound to make major mistakes, and I'd bet money that most APIs designed and implemented in 2 days have tons of security holes.