11 ms·

Unless I’ve missed some major development then I have to strenuously disagree. AI is primarily good at writing isolated scripts that are no more than a few page

Unless I’ve missed some major development then I have to strenuously disagree. AI is primarily good at writing isolated scripts that are no more than a few pages long. 99% of the work I do happens in a large codebase, far bigger than anything that you can feed into an AI. Tickets come in that say something like, “Users should be able to select multiple receipts to associate with their reports so long as they have the management role.” That ticket will involve digging through a whole bunch of files to figure out what needs to be done. The resolution will ultimately involve changes to multiple models, the database schema, a few controllers, a bunch of React components, and even a few changes in a micro service that’s not inside this repo. Then the AI is going to fail over and over again because it’s not familiar with the APIs for our internal libraries and tools, etc. AI is useful, but I don’t feel like we’re any closer to replacing software developers now than we were a few years ago. All of the same showstoppers remain.

luckydata 2y ago
Google's LLM can ingest humongous contexts. Check it out.
CamperBob2 2y ago
All of the code you mention implements business logic, and you're right, it's probably not going to be practical to delegate maintenance of existing code to an ML model. What will happen, probably sooner than you think, is that that code will go away and be replaced by script(s) that describe the business logic in something close to declarative English. The AI model will then generate the code that implements the business logic, along with the necessary tests. So when maintenance is required, it will be done by adding phrases like "Users should be able to select multiple receipts" to the existing script, and re-running it to regenerate the code from scratch. Don't confuse the practical limitations of current models with conceptual ones. The latter exist, certainly, but they will either be overcome or worked around. People are just not as good at writing code as machines are, just as they are not as good at playing strategy games. The models will continue to improve, but we will not.
- prewett 2y ago
  The problem is, the feature is never actually "users should be able to select multiple receipts". It's "users should be able to select multiple receipts, but not receipts for which they only have read access and not write access, and not when editing a receipt, and should persist when navigating between the paginated data but not persist if the user goes to a different 'page' within the webapp. The selection should be a thick border around the receipt, using the webapp selection color and the selection border thickness, except when using the low-bandwidth interface, in which case it should be a checkbox on the left (or on the right if the user is using a RTL language). Selection should adhere to standard semantics: shift selects all items from the last selection, ctrl/cmd toggles selection of that item, and clicking creates a new, one-receipt selection. ..." By the time you get all that, it's clearer in code. I will observe that there have been at least three natural-language attempts in the past, none of which succeeded in being "just write it down". COBOL is just as code-y as any other programming language. SQL is similar, although I know a fair amount of non-programmers who can write SQL (but then, back in the day my Mom taught be about autoexec.bat, and she could care less about programming). Anyway, SQL is definitely not just adding phrases and it just works. Finally, Donald Knuth's WEB is a mixture, more like a software blog entry, where you put the pieces of the software inamongst the explanatory writeup. It has caught on even less, unless you count software blogs.
  - CamperBob2 2y ago
    I will observe that there have been at least three natural-language attempts in the past, none of which succeeded in being "just write it down". COBOL... I think we're done here.
    - guappa 2y ago
      Please ping me in 5 years to reassess. I'm ready to bet 1 month of my salary that human software developers will still exist then.
      - fragmede 2y ago
Kiro 2y ago
Cursor has no problem making complicated PRs spanning multiple files and modules in my legacy spaghetti code. I wouldn't be surprised if it could replace most programmers already.
- esafak 2y ago
  How well does it propagate the effects of the files it has modified?
- guappa 2y ago
  Not everybody's job is necessarily as simple as yours.
  - Kiro 2y ago
    It's anything but simple; good try though. From your comments, it's clear you've already made up your mind that it can't possibly be true and you're just trying to find rationalisations to support your narrative. I don't understand why you feel the need to be rude about it though.
    - guappa 2y ago
      My comments stem from real world experience, since I do exist outside of my comments (although I understand it can be hard to imagine). Every single person who claimed AI was a great help to their job in writing software that I've encountered was either inexperienced (regardless of age) or working solely on very simple tasks.
      - CamperBob2 2y ago
        The fact that it's even remotely useful at all at such an early, primitive stage of development should give you pause. When it comes to stuff like this, the state of the art at any given time is irrelevant. Only the first couple of time derivatives matter. How much room for growth do you have over the next 5-10 years?

luckydata 2y ago

Google's LLM can ingest humongous contexts. Check it out.

CamperBob2 2y ago

All of the code you mention implements business logic, and you're right, it's probably not going to be practical to delegate maintenance of existing code to an ML model. What will happen, probably sooner than you think, is that that code will go away and be replaced by script(s) that describe the business logic in something close to declarative English. The AI model will then generate the code that implements the business logic, along with the necessary tests. So when maintenance is required, it will be done by adding phrases like "Users should be able to select multiple receipts" to the existing script, and re-running it to regenerate the code from scratch. Don't confuse the practical limitations of current models with conceptual ones. The latter exist, certainly, but they will either be overcome or worked around. People are just not as good at writing code as machines are, just as they are not as good at playing strategy games. The models will continue to improve, but we will not.

prewett 2y ago
The problem is, the feature is never actually "users should be able to select multiple receipts". It's "users should be able to select multiple receipts, but not receipts for which they only have read access and not write access, and not when editing a receipt, and should persist when navigating between the paginated data but not persist if the user goes to a different 'page' within the webapp. The selection should be a thick border around the receipt, using the webapp selection color and the selection border thickness, except when using the low-bandwidth interface, in which case it should be a checkbox on the left (or on the right if the user is using a RTL language). Selection should adhere to standard semantics: shift selects all items from the last selection, ctrl/cmd toggles selection of that item, and clicking creates a new, one-receipt selection. ..." By the time you get all that, it's clearer in code. I will observe that there have been at least three natural-language attempts in the past, none of which succeeded in being "just write it down". COBOL is just as code-y as any other programming language. SQL is similar, although I know a fair amount of non-programmers who can write SQL (but then, back in the day my Mom taught be about autoexec.bat, and she could care less about programming). Anyway, SQL is definitely not just adding phrases and it just works. Finally, Donald Knuth's WEB is a mixture, more like a software blog entry, where you put the pieces of the software inamongst the explanatory writeup. It has caught on even less, unless you count software blogs.
- CamperBob2 2y ago
  I will observe that there have been at least three natural-language attempts in the past, none of which succeeded in being "just write it down". COBOL... I think we're done here.
  - guappa 2y ago
    Please ping me in 5 years to reassess. I'm ready to bet 1 month of my salary that human software developers will still exist then.
    - fragmede 2y ago

Kiro 2y ago

Cursor has no problem making complicated PRs spanning multiple files and modules in my legacy spaghetti code. I wouldn't be surprised if it could replace most programmers already.

esafak 2y ago
How well does it propagate the effects of the files it has modified?
guappa 2y ago
Not everybody's job is necessarily as simple as yours.
- Kiro 2y ago
  It's anything but simple; good try though. From your comments, it's clear you've already made up your mind that it can't possibly be true and you're just trying to find rationalisations to support your narrative. I don't understand why you feel the need to be rude about it though.
  - guappa 2y ago
    My comments stem from real world experience, since I do exist outside of my comments (although I understand it can be hard to imagine). Every single person who claimed AI was a great help to their job in writing software that I've encountered was either inexperienced (regardless of age) or working solely on very simple tasks.
    - CamperBob2 2y ago
      The fact that it's even remotely useful at all at such an early, primitive stage of development should give you pause. When it comes to stuff like this, the state of the art at any given time is irrelevant. Only the first couple of time derivatives matter. How much room for growth do you have over the next 5-10 years?