>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".
Going to guess you're both young and working at a tech company as opposed to a big company that also does some tech things.
Prior to the rise of Agile and the decrease in waterfall-style development the role of Business Analyst was very popular. It still is at many companies that do need to do waterfall development, but less so these days. The Business Analyst (BA) role is semi-technical and requires some subject matter expertise, but generally doesn't do much actual writing of code. Instead it's focused on requirements gathering, wireframe creation, test case creation & running, bug logging, and status reporting. I know you're probably saying "that's at least half of my job!" and you're right, but now go and look at the difference in pay between a BA and a developer. It turns out that if you remove the "actually writes code" part of the job, it's not worth nearly as much and I think that's what the comment above is trying to express.
In my experience, most of these aspects – requirements gathering, wireframing, test case specification, even bug logging – have a business side and a technical side.
I think Product Managers often take on a lot of these BA responsibilities, they've got the domain knowledge, but there's another step of translation from "build an X that does Y" to "build an X, in A, that does Y, but not Z, in B time, integrating with systems I, J, K". I think that takes an engineering perspective.
I've not worked with anyone titled Business Analyst that does the role you've described, but working with PMs, BI people, and others, there's a large gulf between requirements and tests that they would specify at their level, and requirements and tests that a programmer could work from.
In my experience, it's a complete myth that requirement gathering can be done in a box.
"Requirement gathering" is almost always influenced by technical capabilities. All but the simplest projects, require back and forth with guestimates about the direction and approach.
This is because its difficult to decouple the code from the requirements. And the full requirements are never contained within a doc. So you need an engineer to look at the code to see how its done. This is going to change.
So someone who doesn’t understand code is going to know whether some AI generated description/summary of existing code is accurate, without being able to verify that in anyway? And then create requirements based on that summary? I use GPT-4 as a coding assistant pretty much every day, but it a. makes mistakes or strange assumptions all the time b. can’t parse the logic of or describe complex codebases c. fails to account for obvious edge cases, like an array being empty instead of populated. I mean, maybe some companies will do this, but I hope never have to use their products or they contain any sensitive information.
Again, where do you guys work? Maybe lets not use software engineering. If I asked you today, to do requirements gathering for building a bridge across the Mississippi river, could you do it? Don't you think you would have to learn about materials, regulations, land procurement, tensile and compression strengths and all the tradeoffs of the above? And once you learned all of that and you can finally present the requirements, would it be fair to call you non-technical?
I have to strongly disagree with this. If someone non-technical does the requirements gathering, the requirements will be incomplete. Developers will then either assume their own requirements or, if they’re thorough and good at their job, check these assumptions with the business. Either way, this wastes the company’s time. Either the assumed requirements will require re-work or the company has paid two employees to do the same job that should’ve been done by one.
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".