>
You give it a set of requirements for an api, with edge conditions written in plain English. Test cases are provided. And the vanilla api is generated.Sometimes I wonder where some of the posters here work or if I'm working in a dystopia.
>You give it a set of requirements for an api with edge conditions written in plain English
This part is the job! If my job was 100% writing logic, it would be infinitely easier. Defining the requirements, evaluating the tradeoffs, discovering the edge conditions is where the bulk of my time goes. The only time someone did this for me was when I was a junior developer. Maybe I'm overestimating things, but I find it hard to believe that most engineers pulling huge salaries are just shuffling around fields on JSON API. Do you really need AI to expose a CRUD interface to Postgres?
Edit:
This idea that LLMs will replace engineers (or lawyers, or any traditionally "skilled" field) is hype. It's the same mistake that the customer makes when he's shocked that he gets a bill for $10,000 for replacing a screw in his car engine. You are conflating the actual physical labour requirements of the job (sitting down and coding) with the actual knowledge value that is being used when you do the job.
For example, take a look at Redis. Redis is a great codebase, especially for those that want to learn C. It's simple - there are exceedingly few mind-bending, hardcore, engineering algorithms in Redis. Antirez is an amazing software engineer, but Redis is not the fastest database, nor is it most durable. But what you see is the meticulous application of understanding engineering tradeoffs; there are things Redis does incredibly well and things that it doesn't that is made easier by the overall architecture of the code. How would you even begin to prompt this to an LLM? Again the code isn't complex, but the engineering is, and the act of turning those ideas and communicating them either to an LLM or to a C compiler, is engineering.
No one comes home from a long day and says "Honey, I'm tired I spent all day typing JSON schemas and function signatures".
Sometimes I wonder where some of the posters here work or if I'm working in a dystopia.
>You give it a set of requirements for an api with edge conditions written in plain English
This part is the job! If my job was 100% writing logic, it would be infinitely easier. Defining the requirements, evaluating the tradeoffs, discovering the edge conditions is where the bulk of my time goes. The only time someone did this for me was when I was a junior developer. Maybe I'm overestimating things, but I find it hard to believe that most engineers pulling huge salaries are just shuffling around fields on JSON API. Do you really need AI to expose a CRUD interface to Postgres?
Edit:
This idea that LLMs will replace engineers (or lawyers, or any traditionally "skilled" field) is hype. It's the same mistake that the customer makes when he's shocked that he gets a bill for $10,000 for replacing a screw in his car engine. You are conflating the actual physical labour requirements of the job (sitting down and coding) with the actual knowledge value that is being used when you do the job.
For example, take a look at Redis. Redis is a great codebase, especially for those that want to learn C. It's simple - there are exceedingly few mind-bending, hardcore, engineering algorithms in Redis. Antirez is an amazing software engineer, but Redis is not the fastest database, nor is it most durable. But what you see is the meticulous application of understanding engineering tradeoffs; there are things Redis does incredibly well and things that it doesn't that is made easier by the overall architecture of the code. How would you even begin to prompt this to an LLM? Again the code isn't complex, but the engineering is, and the act of turning those ideas and communicating them either to an LLM or to a C compiler, is engineering.
No one comes home from a long day and says "Honey, I'm tired I spent all day typing JSON schemas and function signatures".