[com2kid]

> A shell script will do exactly what it has been written to do every time, unless tampered with.

Or unless some magic environment variable changes, or one of the runtime dependencies changes, or it is run on a different operating system, or permissions aren't setup right, or one of its tasks errors out.

Shell scripts are digital duct tape, the vast majority of shell scripts do not come close to being reliable software.

> god knows how long that would take for an AI to learn something new

Did you watch OpenAI's demo yesterday? They pasted in new versions of API docs and GPT4 updated its output code. When GPT forgot a parameter, the presenter fed back the error message and GPT added the parameter to the request.

[xwdv]

AI proponents are missing the point. Anything you write to make an AI produce something is basically code. Docs are code.

You don’t have to feed a developer code or docs, you can give them a high level idea and they’ll figure it out on their own if you want.

[echelon]

That code will eventually fall away.

The big thing everyone in this single thread is missing is that AI is a metaheuristic.

I wouldn't expect to use AI to run_script.py. That's easy. I'd expect it to look at the business signals and do the work of an intern. To look at metrics and adjust some parameters or notify some people. To quickly come up with and prototype novel ways to glue new things together. To solve brand new problems.

[xwdv]

To do the work of an intern an AI must go on Jira, read a ticket, then find the appropriate repositories where code needs to be modified, write tests for its modification, submit for code review, respond to feedback in code review, deploy its changes.

It’s not there yet.

[com2kid]

> To do the work of an intern an AI must go on Jira, read a ticket, then find the appropriate repositories where code needs to be modified,

The problem is Jira workflows are designed for reporting results to upper management.

If the cost savings / productivity benefits[1] are there, new workflows will appear.

[1] Then again there are huge productivity benefits to be gained by simplifying existing Jira workflows, yet such steps are not taken.

[echelon]

This feels achievable in five years.

[JohnFen]

It always feels achievable in five years. People were saying exactly this 30 years ago.

Sooner or later it may (or may not) be a true statement, but it's awfully hard for me to say that it's any different right now than it has been before.

[vidarh]

I've had ChatGPT write code from vague statements that got close enough that it'd take the typical intern days of research to figure out. I've also had it fail spectacularly before prompted more extensively. But there are tasks I'd rather hand of to ChatGPT already today than hand to an intern, because it does the job faster and is able to correct misunderstandings and failures far faster.

E.g. I posted a while back how I had it write the guts of a DNS server. It produced a rough outline after the first request, and would fill out bit by bit as I asked it to elaborate or adjust specific points. The typical intern would not know where to start and I'd need to point them to the RFC, and they'd go off and read them and produce something overwrought and complex (I've seen what even quite experienced software devs produce when given that task; and I know how much work it took me the first time I did it).

So it may not exactly replace an intern, in that there are classes of problems that require low-level reasoning and a willingness and ability to go off and research that it's just not set up for yet and that will be harder to replace. But the problem set will change. Both in that what gets to the intern will be things where LLMs don't produce good result fast enough (I wouldn't ask an intern to do something what ChatGPT can do well with little prompting), and that interns will be more likely to go off and learn a bit and then spend more time prompting LLMs and in that sense produce more value than they could before.

[echelon]

What's different is that each subtask now feels like a weekend hackathon. Plus a bunch of engineering to ensure high quality results and build the appropriate UI/UX for human drivers.

You could solve 5% of cases now and over five years drive it up beyond 100% (where you're getting new customers and startups that had never even tried the previous methods).

[Analog24]

What developer working on anything meaningful does not rely on documentation? You certainly have to make the documentation available similar to how you would have to make it "available" to an LLM. I think you might be missing the point about what the potential use-cases for these systems are.