The "End of Programming" will look a lot like programming (2023)(ben11kehoe.medium.com)
ben11kehoe.medium.com
The "End of Programming" will look a lot like programming (2023)
https://ben11kehoe.medium.com/the-end-of-programming-will-look-a-lot-like-programming-8b877c8efef8
161 comments
I think you're just imagining that the AI takes on the role of an assembly line manager, and the programmers turn into assembly workers doing line/item work.
I dont think this is the case, nor will it be. It is more likely that an ai makes it possible to hire low cost personnel and yet have them be _almost_ as productive as someone skilled (at mediocre tasks, but those do make up the bulk of work in tech imho).
The high skilled personnel will need to compete on this front. Some will relent and give up to become those mediocre task doers. Others will strike out and take risk - perhaps even incorporate AI into their own toolbox - and produce software with higher proficiency as an ISV.
I dont think this is the case, nor will it be. It is more likely that an ai makes it possible to hire low cost personnel and yet have them be _almost_ as productive as someone skilled (at mediocre tasks, but those do make up the bulk of work in tech imho).
The high skilled personnel will need to compete on this front. Some will relent and give up to become those mediocre task doers. Others will strike out and take risk - perhaps even incorporate AI into their own toolbox - and produce software with higher proficiency as an ISV.
It already looks like that on places driven by Kaban boards, one task one ticket, doing it "agile".
The name escapes me but there's a short story describing this.
computers don't do the work but instead tell humans what to do in very minute steps, following them around all day. The short story itself is set in a food place similar to a McDonalds IIRC>
computers don't do the work but instead tell humans what to do in very minute steps, following them around all day. The short story itself is set in a food place similar to a McDonalds IIRC>
Manna – Two Views of Humanity’s Future
by Marshall Brain
https://marshallbrain.com/manna1
https://marshallbrain.com/manna1
And to be more explicit, people already are, and the results are fucking terrible in some places. But we're already in an economic context where terrible products and services up to and including things that are explicitly scams go on for years with little recourse for users affected. From that perspective the AI just makes it cheaper to do
I think all these things are happening today, but with micro managers instead of ai. And to be honest: letting AI do the micromanagement would be an improvement in a lot of places.
The main problem I see here, is that management may use ai as an opportunity to push for more micro management. And if that happens, the consequences will be similar to regular non-ai micromanagement (e.g. higher perceived productivity, less actual productivity, developers leaving).
The main problem I see here, is that management may use ai as an opportunity to push for more micro management. And if that happens, the consequences will be similar to regular non-ai micromanagement (e.g. higher perceived productivity, less actual productivity, developers leaving).
But with programming (at least I haven't seen many programmer cases to the contrary, I have seen in other (gig) jobs) you can escalate to a human; this is going towards not being able to do that. So you have
- remote workers
- strict scoring (score <= 0 -> fired)
- no human to contact
So when you are stuck in a loop (like my other response to asking what I have seen in practice) and you cannot reach another human to resolve your issue, your score will sink (because you are not delivering) and you get fired. All automated, all LLM, no humans. It'll first happen in other professions (I know at least one multi national that does this with data entry people as a trial now), but programming won't be far behind.
- remote workers
- strict scoring (score <= 0 -> fired)
- no human to contact
So when you are stuck in a loop (like my other response to asking what I have seen in practice) and you cannot reach another human to resolve your issue, your score will sink (because you are not delivering) and you get fired. All automated, all LLM, no humans. It'll first happen in other professions (I know at least one multi national that does this with data entry people as a trial now), but programming won't be far behind.
> I know at least one multi national that does this with data entry people as a trial now
Do you have a reference? Just asking because I'd be interested in learning more.
Do you have a reference? Just asking because I'd be interested in learning more.
One of the biggest car rentals is experimenting with this to cut costs. And this is more efficient than actually solving their systems integrating problem which is the only reason they actually need these drones to copy/paste.
> - kafkaesque standups where features/bugs are explained by ‘ai’ in a painful loop
Could you elaborate on that one? It sounds "interesting".
Could you elaborate on that one? It sounds "interesting".
One of our clients uses jira with gpt4 turbo api assistants; one of the features is that when the ‘implementation team’ (mostly cheap offshore hires in this case) is doing ‘sprint planning’ or standups (in this company’s mismanaged version of agile), the right people are not there, they ‘talk’ to jira and the ai assistant to clear up stuff. From what I have seen, the tasks in jira are written out quite well and gpt does do a (much) better job at one shot ‘understanding’ of the tasks than the team does, however, when the questions go deeper or more technically specific (to their internal systems), it basically loops aka repeats itself every other answer. And so the team will make up something, which is generally not correct, and implement it. Then the next week it will be a bug instead of a feature (for instance) and explained in terms of what to fix instead what to build, which both ai and humans seem to be better at. However the initial ‘loop’ is a nightmare and very dehumanising imho.
Wow. I was afraid there would be substance to this. But this is on another level. Thank you for the explanation. That's really sad.
At the moment what the "end of programming" looks like in my experience is:
* Better auto-complete for verbose languages,
* A question/answer workflow significantly smoother than googling it,
* A on tap rookie for 5-15 line pieces of code that don't matter much (it difficult to trust more because quality isn't great),
* An awesome bash one-liner sidekick,
And most of importantly
* A consultable socrates-in-a-box "colleague" that is often useful, but needs to checked.
* Better auto-complete for verbose languages,
* A question/answer workflow significantly smoother than googling it,
* A on tap rookie for 5-15 line pieces of code that don't matter much (it difficult to trust more because quality isn't great),
* An awesome bash one-liner sidekick,
And most of importantly
* A consultable socrates-in-a-box "colleague" that is often useful, but needs to checked.
I can't imagine explaining to the Socrates what I need from my bash one-liner, probably faster is to write it myself. Of course depends on complication level
I explain that to Google all the time and it just finds me someone on Stack Overflow who's figured it out already. Not to mention the dozens of other drive-by human reviewers that Stack Overflow offers. It's difficult to imagine AI improving on that. Unless it's like a Star Trek badge you talk to, and the LLM does the Google search for you and types the command into the terminal, because you're too lazy to pull out the keyboard.
> It's difficult to imagine AI improving on that
It can be an improvement due to LLMs ability to quickly adapt any solutions to your specific use case.
On Google you can search for CRUD web application examples and find tutorials but you will have to adapt to your specific scenatio.
With LLMs ou can ask: "Write a CRUD web app using Next.js and postgres. I want the CRUD to manage entity A with fields x Tx, y, Ty..." and there's a good chance it will spit out a pretty good starting boilerplate.
It can be an improvement due to LLMs ability to quickly adapt any solutions to your specific use case.
On Google you can search for CRUD web application examples and find tutorials but you will have to adapt to your specific scenatio.
With LLMs ou can ask: "Write a CRUD web app using Next.js and postgres. I want the CRUD to manage entity A with fields x Tx, y, Ty..." and there's a good chance it will spit out a pretty good starting boilerplate.
> It can be an improvement due to LLMs ability to quickly adapt any solutions to your specific use case.
My experience with that so far has been that, yes, that works quite well as long as the thing you ask is common and reasonably simple. The more uncommon and complex it gets, the less successful this tends to be. And in more uncommon cases, if it is successful in terms of the workability of the emitted code, it's often not clear if the approach taken is a good idea at all considering other aspects like maintainability.
LLMs are notoriously bad at just saying "Hey dude, I don't really know what I am doing here, ok?"
Also, I have often been able to trace their responses back directly to SO answers. Usually, there is not much "creativity" in their answers at all.
My experience with that so far has been that, yes, that works quite well as long as the thing you ask is common and reasonably simple. The more uncommon and complex it gets, the less successful this tends to be. And in more uncommon cases, if it is successful in terms of the workability of the emitted code, it's often not clear if the approach taken is a good idea at all considering other aspects like maintainability.
LLMs are notoriously bad at just saying "Hey dude, I don't really know what I am doing here, ok?"
Also, I have often been able to trace their responses back directly to SO answers. Usually, there is not much "creativity" in their answers at all.
This is exactly my experience and I'm loving it. The key here is that it's a source, the things it produces still need to be checked.
> An awesome bash one-liner sidekick
Ah running scripts with no idea what they do… what could go wrong? :D
Ah running scripts with no idea what they do… what could go wrong? :D
You really have to try hard to get it NOT to explain what the script does for four or five paragraphs.
And I don't trust its competence so I check what it came up with first.
And I don't trust its competence so I check what it came up with first.
That assumes you have the basic knowledge of the system you’re scripting. Imagine someone with no idea of codec and containers asking for a ffmpeg script.
Currently to me it looks more like low code programming, plugging SaaS APIs driven by AI in headless MACH products.
It can also help you naming things and give you different options.
Yeah, it's great for finding things I can describe, but not google - since I don't know or can't remember the name of.
[deleted]
Most people who say to me that AI will replace programmers are people who haven't built and maintained a software system, and see programmers as interchangeable cogs in a machine. So the author explained in a good way many things that I have been thinking about how AI does not mean the end of programming.
The main fear is that LLMs will increase programmer productivity so much that we won’t need so many anymore. On 5r other hand, so many software projects don’t get done already due to a lack of manpower, so I don’t see the extra productivity going to waste with as many programmers as we have now, we will just be able to get more things done.
That fear assumes humans have some expanding ability to context switch as the speed of information given to them increases, something I have little belief in.
If you can’t context switch faster, and embed yourself in the next task completely, in a way that lets you articulate the problem correctly to the LLM so that it can produce a correct answer for you, it can’t help you.
If you can’t context switch faster, and embed yourself in the next task completely, in a way that lets you articulate the problem correctly to the LLM so that it can produce a correct answer for you, it can’t help you.
Right on the other hand it can’t replace us. The way LLMs work now…they are purely augmentative, the kind of experience that could work would be one of aid rather replacement. But of course, finding that experience will be tough.
you call it fear, I call it anticipation.
We've had such a spate of piss poor developers over the years that I find it gleeful to think they'll no longer be employable.
Yes, I know that makes me an asshole but I've seen some shit and it actively offends me that these people are paid for the code and the bad name it gives an industry I participate in and love. My hope is that AI will allow the good to great developers to be productive enough to force the craptastic developers to find another career.
My absolute favorite example is the guy who accidentally built a FSM with http redirects for the node transitions, all to animate a progress bar for a job queue on the server. No, he had no idea he had built a FSM.
We've had such a spate of piss poor developers over the years that I find it gleeful to think they'll no longer be employable.
Yes, I know that makes me an asshole but I've seen some shit and it actively offends me that these people are paid for the code and the bad name it gives an industry I participate in and love. My hope is that AI will allow the good to great developers to be productive enough to force the craptastic developers to find another career.
My absolute favorite example is the guy who accidentally built a FSM with http redirects for the node transitions, all to animate a progress bar for a job queue on the server. No, he had no idea he had built a FSM.
The fear is not of being replaced at all, but of reductions which will happen inevitably
I don't see how it will have more impact than compilers/libraries/internet that have already permitted to improve a lot individual productivity without significantly decreasing the demand for developers.
Did they improve individual productivity or did they provide much more complexity by shifting the abstraction level? The more I code, the more I see we’re still solving the same core problem, sometimes with artificial constraints introduced by the choice of a platform.
The web was seen as a hub of information, but now people has been trying to make it a computing hub, ignoring the already available computing platform we already have (the devices in front of us).
The web was seen as a hub of information, but now people has been trying to make it a computing hub, ignoring the already available computing platform we already have (the devices in front of us).
[deleted]
I too have a lot of cool ideas that turn out to be much harder to make than to talk about. The very best case performance of code assistance tools as they currently exist seems to be that they moderately increase the productivity of developers who know what they want and know enough to check the autocompleted work. As a ML researcher who's watched the progress of both code generation and natural language processing for about 10 years in earnest, this is a crazy awesome result, a breakthrough in the field that's very laudable (except for all the shady data provenance sleight of hand that allowed the companies spearheading this effort to make progress, but that's been talked about by people who know a lot more about applicable law than I do and I won't do it justice, and it's tangential in a discussion of what's possible). But there is no result so impressive that business people in the midst of a tech hype wave won't apply some added bullshit to in order to fundraise, and "the end of programming" seems more like that than a realistic assessment of the capabilities of current systems, or even a plausible result of merely incremental progress on them
It will happen someday. Still decades away. No true learning in the current LLMs just plagiarism so far to get better. I work at a place that is trying to use LLM to do a thing. just hired two humans to double check the work. They now do almost all of the work ...
GPT4 was decades away 2 years ago...
and autonomous cars were just around the corner 10 years ago.
The last 20% is really hard
The last 20% is really hard
The DARPA grand challenge that represented the thought that this was even possibly only happened in 2004 (29 years ago). I heard they even have autonomous taxis in SF now, which was more progress than I would have predicted 10 years ago.
10 years ago was when Siri and the other voice assistants came out right? I see a huge amount of progress between then and now, but these LLMs sort of snuck up on us in the last two years. I don’t think we are hitting an AI winter anytime soon.
10 years ago was when Siri and the other voice assistants came out right? I see a huge amount of progress between then and now, but these LLMs sort of snuck up on us in the last two years. I don’t think we are hitting an AI winter anytime soon.
> I heard they even have autonomous taxis in SF now
It is always spooky seeing how good the driver less taxis are
https://videos.files.wordpress.com/M9Dl3QYN/robocars.mp4
It is always spooky seeing how good the driver less taxis are
https://videos.files.wordpress.com/M9Dl3QYN/robocars.mp4
Just a nit, DARPA grand challenge in 2004 wasn’t 29 years ago, it was 19 years ago (or almost 20 years ago, if you round up by a month).
The last 20% is a blocker for autonomous cars because it can cause lives to be lost.
Sure, but not all programming is building webapps either. There are many high stakes environments, with real consequences.
Additionally as the ball of mud grows, making slight but subtle changes to the system will get subsequently harder and harder to describe to the point where the tradeoff from using english is higher than flipping some code (imo).
Additionally as the ball of mud grows, making slight but subtle changes to the system will get subsequently harder and harder to describe to the point where the tradeoff from using english is higher than flipping some code (imo).
But we still need to have humans check or define specs for the program.
If even human have problems when receiving specs from management, it'll be harder for them to instruct AI, at least for now. Unless there's some microchip transplants or brain reading interfaces that can translate those.
It was also decades away for quite a few decades.
I concur that it will happen someday, but decades? C'mon.
The end of programming will be no programming at all. First AIs will do the things that are necessary without someone telling them. If there are still companies, e.g. this means sending emails to customers (who have AIs that are reading their emails and acting on them ;-) to sell more things, create APIs or websites on their own, hire other people (AIs) to do things they can't do (regulation, other country, etc.).
For the mid future, it's like Star Trek: "Computer give me the customers that perform best" - from a data lake, no data warehouse, no CRM code, no web frontend. No programmers, just users.
For the near future, developers will become managers. Instead of hiring and managing people, they will select and manage different AIs for different tasks. See what those are doing, give them feedback (just like a manager would to developers), change the prompt (like a manager would clarify a task), give them data, grow them (again just like a people manager today).
For the mid future, it's like Star Trek: "Computer give me the customers that perform best" - from a data lake, no data warehouse, no CRM code, no web frontend. No programmers, just users.
For the near future, developers will become managers. Instead of hiring and managing people, they will select and manage different AIs for different tasks. See what those are doing, give them feedback (just like a manager would to developers), change the prompt (like a manager would clarify a task), give them data, grow them (again just like a people manager today).
Not really. Developers become TESTERS. Except developers don't want to be testers, and will do it badly.
Testing is hard. No, sorry, I meant to write that COMPETENT testing is hard. Any idiot can do shallow testing and say he tested, and many do. That's not the same thing as doing a professional job of it.
But, the fact is, AI can't be a software developer, because a software developer is capable of being accountable. AI is a machine. Machines cannot be accountable. You can't sue them. You can't jail them. You can't reform them. A machine cannot be a citizen.
A programmer is someone who mediates the gateway between the world of machines and the world of people. This is because machines behave in very particular ways. Just as you should not represent yourself in a court of law, no one who doesn't understand machines should attempt to create a professional grade products with them... Or if they do, expect it to be poor quality.
Testing is hard. No, sorry, I meant to write that COMPETENT testing is hard. Any idiot can do shallow testing and say he tested, and many do. That's not the same thing as doing a professional job of it.
But, the fact is, AI can't be a software developer, because a software developer is capable of being accountable. AI is a machine. Machines cannot be accountable. You can't sue them. You can't jail them. You can't reform them. A machine cannot be a citizen.
A programmer is someone who mediates the gateway between the world of machines and the world of people. This is because machines behave in very particular ways. Just as you should not represent yourself in a court of law, no one who doesn't understand machines should attempt to create a professional grade products with them... Or if they do, expect it to be poor quality.
This is the truth. Everyone wants AI to write their tests, but that’s backwards. AI will write the code and programmers will write the tests. The tests are the real business logic - binary assertions of how a system should or should not behave. The internals of how that happens are inconsequential.
Inconsequential until you start caring performance, scaling, reliability, interdependence with other systems, maintainability, or any other things that tests don’t assert.
You can test performance, and you can monitor reliability. Scale and interdependence are spec requirements that are this theoretical AI's job. Maintainability is irrelevant to everyone here except the theoretical AI, as the AI does the maintaining.
This sounds a lot like some kind of government procurement process, which don't have a reputation for producing particularly good IT systems.
I've used ChatGPT to write my tests. It's pretty effective at getting the first 5-6 use cases written out, but in a style that isn't correct. Copy/paste a code module, ask it to write the tests.
Then, in the same context, you correct it by providing it with more information about how you like to structure the tests. It starts to understand the "style".
Then, you start to provide the context with testing concerns. By the end of it, the AI context is pretty good (80-90'ish%).
It's nice, as a developer, to be able to say: "test that asset is deleted when DELETE /asset/:id", and the AI converts that into a proper test case, using familiar variables / test structure / corrects the abbreviated text into a proper test title, etc..
Then, in the same context, you correct it by providing it with more information about how you like to structure the tests. It starts to understand the "style".
Then, you start to provide the context with testing concerns. By the end of it, the AI context is pretty good (80-90'ish%).
It's nice, as a developer, to be able to say: "test that asset is deleted when DELETE /asset/:id", and the AI converts that into a proper test case, using familiar variables / test structure / corrects the abbreviated text into a proper test title, etc..
I look forward to writing specifications ("property tests without RNG") in a theorem prover language and some AI writing the program against my specification.
Why not simply use AI to implement monitoring and evaluation so incredibly fine grained any human would go insane if they had to do it?
Strange argument, it's not common to sue and jail developers, and our average software isn't particularly good quality. Companies will use whatever works for less money, as they always did.
I also see very limited accountability beyond firing.
There was some in #Dieselgate (Developers going to jail for their code).
There was some in #Dieselgate (Developers going to jail for their code).
James Robert Liang got jail.
It is quite strange, since the defeat device part was actually quite insignificant to work around a vehicle reset during testing and skip the warm up timer.
The real scandal is that emission treatment in diesels did not work outside of synthetic kinda steady state tests. And that applied to way more manufacturers than VW.
It is quite strange, since the defeat device part was actually quite insignificant to work around a vehicle reset during testing and skip the warm up timer.
The real scandal is that emission treatment in diesels did not work outside of synthetic kinda steady state tests. And that applied to way more manufacturers than VW.
A developer is accountable in the way of being fired. Not accountable in the way of paying for the loss.
In this way an AI is accountable too, I can switch from Claude to Mistral.
In this way an AI is accountable too, I can switch from Claude to Mistral.
Testing is what LLM coding models are born for..
- We want this
- We Had this
- This happened
- Already at work
- We want this
- We Had this
- This happened
- Already at work
Code is much harder to maintain than to write. You'll save 6 hours writing it, only to spend many more maintaining it.
Of course, eventually the AI will be smart enough to do maintenance, but at that point it'll basically take the job of anyone who does their job entirely on a computer.
Of course, eventually the AI will be smart enough to do maintenance, but at that point it'll basically take the job of anyone who does their job entirely on a computer.
I do think, as soon as you stop caring about the code, this goes away.
Just like with garbage collection, "we need to have proper malloc and free". The moment we gave this to a JVM, the problem went away.
It means giving up control and don't care about the internals (0.1% of developers today care about the detailed internals and performance of GCs.)
Just like with garbage collection, "we need to have proper malloc and free". The moment we gave this to a JVM, the problem went away.
It means giving up control and don't care about the internals (0.1% of developers today care about the detailed internals and performance of GCs.)
Except that the JVM didn't take over all of programming (as some predicted back in the late 90s/early 2000s). C, C++ and Rust are popular programming languages today. Probably because Java isn't a good systems language, or the ideal for all embedded tasks. And that tons of widely used code is written in C/C++.
Mostly because Java did the mistake to gate AOT behind commercial licenses, thus C and C++ kept being relevant for many tasks requiring AOT workloads.
Had Java shipped a AOT compiler in the box for free, Go would not happened, nor many of the workloads that Go has been taking away from C and C++ on the distributed computing space and devops.
C and C++ would have their use cases reduced to kernel programming, embedded, games and like else.
Had Java shipped a AOT compiler in the box for free, Go would not happened, nor many of the workloads that Go has been taking away from C and C++ on the distributed computing space and devops.
C and C++ would have their use cases reduced to kernel programming, embedded, games and like else.
Let’s assume then that there is no GC for parts of the code. It’ll be constantly regenerated
> It’ll be constantly regenerated
What do you mean by this?
What do you mean by this?
probably a misunderstanding of what the GC is and does.
The GC works on data, not code.
The GC works on data, not code.
I think the generous meaning would be an experience like Rust (handles memory allocations/deallocations, doesn't mess up unless you really mess up) except that it doesn't complain all the time when you're doing "ok things" and maybe even makes it impossible in practice to mess up.
It could even dynamically decide between using a GC for a given program or not, depending on what makes more sense (thus "constantly generating it").
It could even dynamically decide between using a GC for a given program or not, depending on what makes more sense (thus "constantly generating it").
The problem didn't go away.
It got better, but memory leaks are a thing in Java too.
It got better, but memory leaks are a thing in Java too.
Besides the fact that they're actually fairly good at maintaining code/building tests, they don't get bored maintaining code like people do
I'd say that's a far easier task than development (from the POV of a machine) because you already have a known "standard" to aim for, and there's much less need for 'lateral thinking'. Anytime you have a delta you can initiate responses (even incredibly minor ones)
And you could send a proverbial army of them at any small regression or complaint for almost no cost.
I'd say that's a far easier task than development (from the POV of a machine) because you already have a known "standard" to aim for, and there's much less need for 'lateral thinking'. Anytime you have a delta you can initiate responses (even incredibly minor ones)
And you could send a proverbial army of them at any small regression or complaint for almost no cost.
Programmers won't turn into managers of technology because programmers are already the managers. Writing code in symbolic formalisms is how we control reality and impose our will upon it. The people you call managers have very little power in this process and focus primarily on controlling the human social processes that enable programmers to do what they do. There's no social process interacting with machines so there's no managerial position you can graduate into.
Sure, in the same way that we'll all stop driving cass and have self driving cars any day now.
What you just described is more of a tech lead than a "manager", and that's really the point. Reality that's not encoded in pure language is a fundamental limit of LLMs; they're probably never going to correctly diagnose a hardware bug based on misbehaving software, for example, because that's a world where everything that they are (ingestion material, available documentation) and reality conflict and an LLM has very little ability to detect and overcome such a problem.
Those "reality vs the text" impedance mismatches mean that LLMs are probably never going to escape human oversight. Which means we'll all probably have as many low quality (occasionally brilliant) fresh grads as we like, but taking the jobs of experts seems unlikely.
The end of programming looks like lots of work for programmers.
What you just described is more of a tech lead than a "manager", and that's really the point. Reality that's not encoded in pure language is a fundamental limit of LLMs; they're probably never going to correctly diagnose a hardware bug based on misbehaving software, for example, because that's a world where everything that they are (ingestion material, available documentation) and reality conflict and an LLM has very little ability to detect and overcome such a problem.
Those "reality vs the text" impedance mismatches mean that LLMs are probably never going to escape human oversight. Which means we'll all probably have as many low quality (occasionally brilliant) fresh grads as we like, but taking the jobs of experts seems unlikely.
The end of programming looks like lots of work for programmers.
We have self driving cars.
So why are people still driving cars? Why are there still Uber, delivery and truck drivers? 99.99% of vehicles are driven by humans.
It's like saying we have flying cars. Sure, working prototypes have existed for some time now. There were (are?) companies making them. But it makes no real world difference.
In the context of "no more programming", it makes no difference if some fancy AI model can in theory replace programmers, if they don't actually end up doing that on any real scale.
It's like saying we have flying cars. Sure, working prototypes have existed for some time now. There were (are?) companies making them. But it makes no real world difference.
In the context of "no more programming", it makes no difference if some fancy AI model can in theory replace programmers, if they don't actually end up doing that on any real scale.
> So why are people still driving cars?
Because it costs Waymo about US$200,000 per car, not including the operating and maintenance staff. It will get cheaper.
Because it costs Waymo about US$200,000 per car, not including the operating and maintenance staff. It will get cheaper.
You do realize the first ever decent AI has appeared less than a year ago? It’s available to anyone today for $20/mo, and it will get better and better every year. What we have now was considered pure science fiction just five years ago, a hypothetical technology - decades away at best.
Why are people still driving cars? Because the autonomous driving technology wasn’t good until very recently. It has improved a lot in just the last few years, and you can already see self driving cars operating commercially in several cities. Again, it will get better every year, and as it gets better it will spread everywhere.
It’s true that flying cars exist but haven’t become popular or widespread. I’m not entirely sure why. But it is much easier to ask ChatGPT to write some code than to actually try out a flying car.
Why are people still driving cars? Because the autonomous driving technology wasn’t good until very recently. It has improved a lot in just the last few years, and you can already see self driving cars operating commercially in several cities. Again, it will get better every year, and as it gets better it will spread everywhere.
It’s true that flying cars exist but haven’t become popular or widespread. I’m not entirely sure why. But it is much easier to ask ChatGPT to write some code than to actually try out a flying car.
Because they are poor, also because of regulations crippling fsd (for better or worse).
What are the regulations preventing FSD?
Coding won't die, it will simply shift from the language of computers to a weird half-natural half-computing dialect.
I remember hearing that exact same thing about SQL. Managers wouldn't need analysts anymore because SQL is a human like language that anyone can use. I've been through at least a half dozen different iterations of this, and each one makes it slightly true while also creating new jobs. Each generation of manager gets a bit more savvy and able to do things on their own, but the amount of work down in the trenches keeps on increasing. Perhaps LLMs will be different; each generation of these tools promises to be the one that lets management cut programmers out of the loop. Perhaps someday one of them will be correct but history so far hasn't worked out that way.
That is a bit silly as SQL is a language itself, it's not a thing that can write in (many) other languages while still understanding human natural language.
LLMs are that 'blurry jpg of the internet' but now also more finetunable/specialized.
I'm going to look at siccing some LLMs on old Jenkins errors today, ideally it will give me more time to spend on building things (and hopefully less fires later).
I obviously don't expect it to magically fix everything but I have a good idea of what they're capable of, what they need help with, and what their pitfalls are
I can now have some scripts and some "agents" scan through 250GB of logfiles and do various sanity test things and either report back or make a branch and try to fix it, before i even need to look at it. It costs almost nothing and if it finishes early I can have it "go do the same thing but in rolling 3 month windows to see wtf happened when"
FWIW I think LLMs are more powerful for the language side of things. I get a lot of the programming improvement from python/metaprogramming/etc - but the combination is like having a group of interns you can make do a bunch of tedious/shit work that nobody wants to do.
LLMs are that 'blurry jpg of the internet' but now also more finetunable/specialized.
I'm going to look at siccing some LLMs on old Jenkins errors today, ideally it will give me more time to spend on building things (and hopefully less fires later).
I obviously don't expect it to magically fix everything but I have a good idea of what they're capable of, what they need help with, and what their pitfalls are
I can now have some scripts and some "agents" scan through 250GB of logfiles and do various sanity test things and either report back or make a branch and try to fix it, before i even need to look at it. It costs almost nothing and if it finishes early I can have it "go do the same thing but in rolling 3 month windows to see wtf happened when"
FWIW I think LLMs are more powerful for the language side of things. I get a lot of the programming improvement from python/metaprogramming/etc - but the combination is like having a group of interns you can make do a bunch of tedious/shit work that nobody wants to do.
I would love it if we got the ship's computer. That doesn't seem to be anywhere on the horizon.
Until recently there was a button on my phone I could press to get immediate directions somewhere, to start a timer, any number of other things etc. A few months ago they updated the button, now it just searches Google.
I don't think rational interfaces of the sort you described will win out. Windows peaked at 7, which was an all but perfect desktop operating system, and they deliberately wrecked it.
The companies who've invested in this technology and control the hardware don't work by solving problems and queries straightforwardly. Rather they are very good at getting in between you and the solution/answer. Even on a B2B level - don't get me started on enterprise CRMs.
I also don't think it would make any sense for me to browse images and fiddle with prompts all day trying to make something happen programmatically, maybe, instead of just writing the code that will surely make it happen.
Copilot and chat gpt the other hand are amazing assets for now.
Until recently there was a button on my phone I could press to get immediate directions somewhere, to start a timer, any number of other things etc. A few months ago they updated the button, now it just searches Google.
I don't think rational interfaces of the sort you described will win out. Windows peaked at 7, which was an all but perfect desktop operating system, and they deliberately wrecked it.
The companies who've invested in this technology and control the hardware don't work by solving problems and queries straightforwardly. Rather they are very good at getting in between you and the solution/answer. Even on a B2B level - don't get me started on enterprise CRMs.
I also don't think it would make any sense for me to browse images and fiddle with prompts all day trying to make something happen programmatically, maybe, instead of just writing the code that will surely make it happen.
Copilot and chat gpt the other hand are amazing assets for now.
I think it's fun to consider how the capitalist mentality of "always be growing" has influenced the software we use. There is some software we've used all our lives that has hardly changed, it is dependable, and maybe we paid for it once, long ago. Then there is software that is constantly changing, and in some cases, it feels like too many even if it isn't, getting worse as a result. Windows actively pushes changes on users driven by this mentality, now we have a Copilot button, to replace the Cortana button I'd previously disabled. What will replace the Copilot button when they've decided too many customers have disabled it?
This is exactly my point of view, my only difference is that developers will turn into technical architects, a bit like nowadays for offshored devs, but it will be AI instead.
Why bother disputing claims about AI made by the CEO of a new AI startup. They are obviously going to be throwing lofty statements around about its capabilities.
Everyone agrees that catching errors in the design phase is far superior to catching them in implementation or testing phases.
So why are requirements often mentioned only in passing ?
Don't they deserve some intellectual TLC ? Writing good requirements is at least as challenging as writing good laws. And then, as the article suggests, an AI can kind of fill in the missing bits if it has good cultural context.
There's many good tools now for formulating and managing requirements. Why do I not see papers about how LLMs benefit from them ?
So why are requirements often mentioned only in passing ?
Don't they deserve some intellectual TLC ? Writing good requirements is at least as challenging as writing good laws. And then, as the article suggests, an AI can kind of fill in the missing bits if it has good cultural context.
There's many good tools now for formulating and managing requirements. Why do I not see papers about how LLMs benefit from them ?
Wherever we have enough redundancy that we have to tell a tool to write out more code for us within certain parameters, is somewhere we have yet to create the right high-level abstractions. This remains a problem even after LLMs do some of the work for us.
The whole point of making more expressive languages and APIs is that we should be able to solve large problems with only the required amount of specificity in each instance, leaving only the code that is the right level of detail for someone to be able to read, understand, and maintain in future.
In the ideal extreme, it shouldn't be any more difficult or tedious to write the code to solve a problem as it would to give the LLM a description of the solution -- if the description was precise and unambiguous then code of similar length should have been able to encode the same. There are many ways that modern programming continues to fall short of this, and that's a problem we should still be working on instead of giving up on.
Even if writing and maintaining code are completely obsoleted by LLMs, we're still going to have to demand humans in the loop on review and testing before we risk life and limb deploying that code. Code still has to be understandable by humans, so it still has to be written with appropriate abstractions to make review accurate and tractable.
We still have the same incentives to want expressive languages and APIs. If we give up on that and bank on LLM generation instead, we'll stop making progress on expressiveness and be stuck with a stale snapshot of today's programming language evolution, that LLMs are limited to writing and humans are limited to reading forever. Without direct disincentive for writing and maintaining that redundant volume of code, the inevitable review will suffer the most.
The whole point of making more expressive languages and APIs is that we should be able to solve large problems with only the required amount of specificity in each instance, leaving only the code that is the right level of detail for someone to be able to read, understand, and maintain in future.
In the ideal extreme, it shouldn't be any more difficult or tedious to write the code to solve a problem as it would to give the LLM a description of the solution -- if the description was precise and unambiguous then code of similar length should have been able to encode the same. There are many ways that modern programming continues to fall short of this, and that's a problem we should still be working on instead of giving up on.
Even if writing and maintaining code are completely obsoleted by LLMs, we're still going to have to demand humans in the loop on review and testing before we risk life and limb deploying that code. Code still has to be understandable by humans, so it still has to be written with appropriate abstractions to make review accurate and tractable.
We still have the same incentives to want expressive languages and APIs. If we give up on that and bank on LLM generation instead, we'll stop making progress on expressiveness and be stuck with a stale snapshot of today's programming language evolution, that LLMs are limited to writing and humans are limited to reading forever. Without direct disincentive for writing and maintaining that redundant volume of code, the inevitable review will suffer the most.
I think this is on point. Humans will take a back seat to ai and will primarily test the outputs as if the ai is a black box instead of having deep insights.
There will be no need for human ingenuity. Perhaps if llm had existed at the time of assembly language being predominate there would be no higher level language for humans to use.
There will be no need for human ingenuity. Perhaps if llm had existed at the time of assembly language being predominate there would be no higher level language for humans to use.
Imho programming is just a medium of reasoning. In that vein I find arguments like this odd.
As I believe they day there is no more need for humans to be involved in any programme , is the day there is no more need for any reasoning by humans. Not something that seems likely to me.
Then again this article comes from someone developing AIs… how could that not be lofty…
As I believe they day there is no more need for humans to be involved in any programme , is the day there is no more need for any reasoning by humans. Not something that seems likely to me.
Then again this article comes from someone developing AIs… how could that not be lofty…
IMO the real value of AI for programming will be in helping you read code not write code. I want to hover over a function call and it can just tell me what it does like a comment blurb above the function should.
IMO it's being (an army of_ automated software engineer hitmen to persecute any regressions, bugs or even potential bugs your project might run into so that
1. things manifest a lot less
2. you don't have to worry about maintenance
I could see a proper structured LLM setup some day even resuscitating 'dead' software.
1. things manifest a lot less
2. you don't have to worry about maintenance
I could see a proper structured LLM setup some day even resuscitating 'dead' software.
Software development requires certain qualities from a programmer which AI can't attain before becoming human: personality and consistency. Personality is shaped by lifelong experiences mostly irrelevant to programming itself. Personality dictates the experience you want for the users. To be able to do that, you need to know the users, you need to understand how a human thinks, functions, and understands things.
Consistency is an artistic element shaped culturally. Again, you need to be exposed to cultural elements for a long time, and more importantly, develop an understanding of them.
I think it's very hard to train AI on these two fronts, and that's why we'll be needing programmers for a long time. AI will keep doing the mundane tasks for us though, thankfully!
Consistency is an artistic element shaped culturally. Again, you need to be exposed to cultural elements for a long time, and more importantly, develop an understanding of them.
I think it's very hard to train AI on these two fronts, and that's why we'll be needing programmers for a long time. AI will keep doing the mundane tasks for us though, thankfully!
I don't know what you mean by consistency.
What you call "personality" seems to roughly mean "predicting what humans like". That's what stuff like RLHF is for. It's also not some sort of ascension where the computer program suddenly "becomes human". It's a spectrum on which we can expect steady improvements (and still never need to call computer programs "human").
What you call "personality" seems to roughly mean "predicting what humans like". That's what stuff like RLHF is for. It's also not some sort of ascension where the computer program suddenly "becomes human". It's a spectrum on which we can expect steady improvements (and still never need to call computer programs "human").
I meant a certain aspect of aesthetics by "consistency". When you explain your requirements to AI, you'll say "create a dialog box with two buttons" right? I mean that's how you'd communicate with a programmer, so, I should at least be capable of that. However, AI cannot guarantee you a consistent style for such a prompt because it has no understanding of the culture, something the programmer, the prompter, and the users share altogether, but not the AI.
AI might have access to the vast amount of design training data, but it can't understand the reasoning behind the variety of those designs, and it can't come up with a similar design every time. It has no cultural affinity, therefore no ability to stick to cultural norms.
So, in order to fill that gap, you need to become more specific with your prompt. And the more specific you get, the more your language becomes closer to a programming language, therefore contradicting the purpose of the AI in the first place.
I'm sure we'll see improvements, but I find it very unlikely to have the same level of understanding without having the same level of cognition and experience as a human, hence my phrasing.
AI might have access to the vast amount of design training data, but it can't understand the reasoning behind the variety of those designs, and it can't come up with a similar design every time. It has no cultural affinity, therefore no ability to stick to cultural norms.
So, in order to fill that gap, you need to become more specific with your prompt. And the more specific you get, the more your language becomes closer to a programming language, therefore contradicting the purpose of the AI in the first place.
I'm sure we'll see improvements, but I find it very unlikely to have the same level of understanding without having the same level of cognition and experience as a human, hence my phrasing.
Have you met most programmers or used much software?
Consistency - This is what GPUs were made for, putting a bunch of 'effort' almost instantly into investigating any regression that any real SW dev would ignore because, life's way too damn busy.
Consistency - This is what GPUs were made for, putting a bunch of 'effort' almost instantly into investigating any regression that any real SW dev would ignore because, life's way too damn busy.
GPUs can create consistent output, AIs can't.
The end of programming will be the end of code.
Code exists solely for humans to interface with machine language. If code is involved at all in any solution, it's a concession to humans.
An AI with the power to build software from some definition doesn't need to write code. Else it simply does not have the power to write software alone.
Code exists solely for humans to interface with machine language. If code is involved at all in any solution, it's a concession to humans.
An AI with the power to build software from some definition doesn't need to write code. Else it simply does not have the power to write software alone.
Seeing this stuff is so mindboggling to me every time. I use GPT4 EXTENSIVELY and it actually sucks so bad for anything complex. How are these takes still coming out on repeat? I've been using it for a YEAR
20 years ago it was UML. Programmers were going to be replaced by generators that ingest UML specs and shit out Java code.
20 years before that it was CASE tools.
Management has been searching for a way to eliminate us from the beginning. The "Software Crisis" of the 60s was simply the fact that programming was hard and businesses wanted software but didn't want to learn how to make it, or to depend on people who knew.
This is why I'm distrustful of "imminent death of programming as a profession predicted",whether it be AI or low/no code tools, whatever. At the end of the day you have human desires that are not being met but could be fulfilled with some nonexistent software. To date only humans fully comprehend human desires, so it takes humans to bring that software into existence.
If AI ever gets as good as us at coding, we need to give it personhood and full rights under the law. Either that, or scorch the sky.
20 years before that it was CASE tools.
Management has been searching for a way to eliminate us from the beginning. The "Software Crisis" of the 60s was simply the fact that programming was hard and businesses wanted software but didn't want to learn how to make it, or to depend on people who knew.
This is why I'm distrustful of "imminent death of programming as a profession predicted",whether it be AI or low/no code tools, whatever. At the end of the day you have human desires that are not being met but could be fulfilled with some nonexistent software. To date only humans fully comprehend human desires, so it takes humans to bring that software into existence.
If AI ever gets as good as us at coding, we need to give it personhood and full rights under the law. Either that, or scorch the sky.
Maybe the AIs will be less greedy and short sighted than human management. Also, I never understood why scorching the sky seemed like a good idea. Surely the Matrix machines were more likely to survive in a world without sunlight than humans, given we need food to eat.
Human executives at least have families and local societies they care about. AI management will be total paperclip maximizers.
- clueless people
- hype
- vested interests
- hype
- vested interests
The havoc that ai will cause on education will likely, in the near term, make programmers even more sought after, not less.
You mean that there will be a whole new way of educating people and that will need lots of programmers to develop it?
Not fighting, just trying to understand what you meant
Not fighting, just trying to understand what you meant
Someone I know worked for quite some time for an online ghost writing company. A big chunk of tasks that you get on that site is just student assignments. He isn't getting any work from the site since ChatGPT.
I think this was what GP is talking about. Students are now using ChatGPT to make assignments. I am divided on will that create worse new programmers or will that create programmers who use ChatGPT for everything replacing the previous generation of entry coders who used stackoverflow for everything.
I think this was what GP is talking about. Students are now using ChatGPT to make assignments. I am divided on will that create worse new programmers or will that create programmers who use ChatGPT for everything replacing the previous generation of entry coders who used stackoverflow for everything.
Currently some programmers, and with time more, have to write, integrate and debug LLMs, hence for the programming to end, other LLMs would have to be able to do so, too. LLMs successfully modifying other LLMs is, like, singularity. In other words, the moment programming ends is the same moment we all are going to die.
I have a hard time believing that AI models will become the environments that software runs in, because they're not performant, reliable or maintainable the way Node, JVM, binaries, web browsers etc are. Or standards compliant. Nor do they have the same kind of access to the hardware these environments have.
And short of software running directly on models, I don't see how programming is going to be completely automated away from humans.
And even if you can make models competitive with traditional software environments, I don't forsee managers and CEOs spending their days prompting the AIs to produce the right kind of code their customers don't know they need. They will pay prompt programmers to do that instead.
And short of software running directly on models, I don't see how programming is going to be completely automated away from humans.
And even if you can make models competitive with traditional software environments, I don't forsee managers and CEOs spending their days prompting the AIs to produce the right kind of code their customers don't know they need. They will pay prompt programmers to do that instead.
We just need to train an LLM how to make an LLM that can make even better LLMs then rinse and repeat. Nothing beats working yourself out of a job.
What training data are you gonna use for that? That which comes out of an LLM? OK. Now you have a degrading loop of self-reinforcing falsehood.
The article gave me a deja-vu about the no-code wave a few years back and an excellent article I read on the subject [1]
> The logic doesn’t go away. Just because a decision is embedded into the wiring of a Zapier rule doesn’t remove any of the burden of maintenance / correctness.
Of course, AI is a lot more powerful than no-code, but the "End of Programming" suffers from the same delusion. If AI can reliably make every decision around engineering, design, and product, it would be capable of doing every task in the world. It's surprising that so many engineers believe writing things in plain text would obviate the need to learn programming.
[1]: https://www.alexhudson.com/2020/01/13/the-no-code-delusion/
> The logic doesn’t go away. Just because a decision is embedded into the wiring of a Zapier rule doesn’t remove any of the burden of maintenance / correctness.
Of course, AI is a lot more powerful than no-code, but the "End of Programming" suffers from the same delusion. If AI can reliably make every decision around engineering, design, and product, it would be capable of doing every task in the world. It's surprising that so many engineers believe writing things in plain text would obviate the need to learn programming.
[1]: https://www.alexhudson.com/2020/01/13/the-no-code-delusion/
The best and worst thing business owners could have is a nice graphical chart of all the business logic in its full glorious detail. No doubt they'll ask "hey, what's this huge blob? It's like a huge hairball or something?" to the last laid off programmer as they walk out the door.
„In general, a lot of the AI takes I see assert that AI will be able to assume the entire _responsibility_ for a given task for a person, and implicitly assume that the person’s _accountability_ for the task will just sort of…evaporate?“
This is a key insight.
This is a key insight.
I think it is obvious that most programming tasks will be replaced by frameworks or whatever we call it. It is not about AI but about zillions of developer reinventing the wheel and having a lof of redundancy. Once specific framework or tools is accepted (e.g. boilerplate generation) the need for more developers hours is decreased. If this is not happenning now is because there are few good crafted frameworms and/or creating them make a lot of development tools (e.g. Microsoft) irrelevant.
There will always be problems that cannot be automated but they will ve minimal and very specific.
There will always be problems that cannot be automated but they will ve minimal and very specific.
History teaches us that "business people" want to "reduce cost" so they will try anything to achieve cost savings. They see the people in the software creation process as necessary evils, or uh, costs, instead of integral to the process of translating vague, usually English, business words into software.
4GLs (Visual Basic, Delphi) and Low/No Code are promised as ways to have "business analysts" or "citizen developers", i.e. lower cost resources, do the work. To be honest this is successful enough to keep selling the idea and products for a period of time. In reality most of the successful work in these areas are done by developers or people that could be developers.
Code generation by LLM is the same thing. Yes, it has value. In the hands of a motivated software developer it will do great things. In the hands of someone that wants to take a short cut because "lower cost" it will fail way more often than it will succeed.
That said, AI and code generation are here to stay and software developers should get used to using them.
4GLs (Visual Basic, Delphi) and Low/No Code are promised as ways to have "business analysts" or "citizen developers", i.e. lower cost resources, do the work. To be honest this is successful enough to keep selling the idea and products for a period of time. In reality most of the successful work in these areas are done by developers or people that could be developers.
Code generation by LLM is the same thing. Yes, it has value. In the hands of a motivated software developer it will do great things. In the hands of someone that wants to take a short cut because "lower cost" it will fail way more often than it will succeed.
That said, AI and code generation are here to stay and software developers should get used to using them.
It seems to me that these "advances" actually make programming _harder_, not easier. The 4GLs, no code solutions, and now AI generation make a _lot_ of assumptions about how things should be done, not always correctly. When they do make an incorrect assumption, it's obvious to a human who's done this "by hand" for a few years, but completely inscrutable to somebody who's been trained to trust the computer's judgment implicitly.
I've been playing with open interpreter a bit, and to see a lot of the things I do that I take for granted written out in code made me realize how much handling of computers I take for granted. for example, I was editing files via open interpreter, and needed to add a header to some files. I, of course, got it wrong the first time and had to iterate on it a bit. As a human, editing the header is trivial, but for the computer to do it for me, it has to write a program to parse the file with a regexp of something, and while it manages to do that, its limitations become apparent, compared to a human. so the end of programming does look a lot like programming. the computer does what you tell it, not what you were thinking.
This seems like a long version of my favourite commitstrip: https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...
It has been one of my favourites for a long time too. It quite much sums up why I’m not worried about no code, low code, or any of the current flavours of AI.
The original fallacy seems to be the belief that what is hard with programming is to remember all that pesky syntax. If we didn’t need to do that, and instead could just tell the computer in plain English what we wanted, we could get rid of programmers all together. (And the fallacy isn’t new, see COBOL).
The original fallacy seems to be the belief that what is hard with programming is to remember all that pesky syntax. If we didn’t need to do that, and instead could just tell the computer in plain English what we wanted, we could get rid of programmers all together. (And the fallacy isn’t new, see COBOL).
What I find it funny about this LLM euphoria is that people seem to have forgotten the theoretical limits of what turing machines can do.
Program equivalence, for instance, hits the wall of the halting problem. Yet somehow people think that it's just a matter of time before an AI that can solve the problem of giving you a mathematically equivalent code to an existing code.
Program equivalence, for instance, hits the wall of the halting problem. Yet somehow people think that it's just a matter of time before an AI that can solve the problem of giving you a mathematically equivalent code to an existing code.
There's two reasons why "halting problem" does not mean that's impossible in practice. First, the halting problem deals with arbitrary length programs that have infinite memory. Second, we don't need to solve "all cases" of the problem. You could have a system that times out for some inputs but is still very useful.
> Program equivalence, for instance, hits the wall of the halting problem. Yet somehow people think that it's just a matter of time before an AI that can solve the problem of giving you a mathematically equivalent code to an existing code.
This is a solved problem in the context of total programming.
This is a solved problem in the context of total programming.
Predictions about a future technology that may exist at some point are almost always dumb.
I don’t see programmers going away because of the current wave of AI, I don’t know about what is coming next, but for sure the current hype is very bubbly and also dumb.
I don’t see programmers going away because of the current wave of AI, I don’t know about what is coming next, but for sure the current hype is very bubbly and also dumb.
Let's face reality here: In the end, AI and robots will be able to do anything better than what we humans can do. That is the harsh reality that everyone will need to accept.
What happens in the mean time will be unclear, but I think most of us still make the false assumption that LLM's are 'robots', while in fact it already became clear that emotional blackmail works on them. AI's might not be as rational and cold as we might expect.
So in the end, I don't see how humans will be able to keep the upper hand on:
- doing user interviews
- analyzing user behaviors
- optimizing business decisions
- writing code
- tracking down issues
What happens in the mean time will be unclear, but I think most of us still make the false assumption that LLM's are 'robots', while in fact it already became clear that emotional blackmail works on them. AI's might not be as rational and cold as we might expect.
So in the end, I don't see how humans will be able to keep the upper hand on:
- doing user interviews
- analyzing user behaviors
- optimizing business decisions
- writing code
- tracking down issues
The "end of programming" is something which happens over and over through one's programming career. You get used to it.
"End of Programming" will look like a Mag-7 interview: [program design] + [leetcode].
> One of my problems with GitHub Copilot (and similar systems) is that you still own the resulting code, and it does not provide any path to gaining confidence that it has given you a correct implementation, despite you owning the correctness of the code it generates
I don’t really see the issue? You take ownership with code review and testing. It’s the same thing you would do if you copied an example that someone gave you and then modified it. The original author isn’t responsible.
(If you don’t understand what the code does, throw it out and find something else.)
I don’t really see the issue? You take ownership with code review and testing. It’s the same thing you would do if you copied an example that someone gave you and then modified it. The original author isn’t responsible.
(If you don’t understand what the code does, throw it out and find something else.)
It's like having infinite interns. Knowing when and when not to use interns is a skill in itself.
I've been hearing about 'The End of Programming" ever since I entered the field back in 1979.
It was bullshit then. It is bullshit now.
You should think of this AI instance as just one more advanced programming language, that's all. It'll be no different from having to learn to program in Java, or in Rust, or in C, or in whatever.
But mark my words, there'll be some poor programmer who will have to do the work of programming.
It was bullshit then. It is bullshit now.
You should think of this AI instance as just one more advanced programming language, that's all. It'll be no different from having to learn to program in Java, or in Rust, or in C, or in whatever.
But mark my words, there'll be some poor programmer who will have to do the work of programming.
For a long time you've been able to just describe what you need to a dev shop in India and have your program built on the cheap. And yet, most companies don't do that...
The company where I work tried to outsource part of our app to India and Ukraine. The result was a mess and they paid a nice amount. Now we do everything in house.
I guess outsourcing companies pay their employees very little and they aren't able to hire top talent. And even if the pay was good, best programmers don't like working for outsourcing companies. The ones they do work for outsourcing companies don't care about the quality of their work as long as their company is paid so they get paid, too.
We assigned a task to one guy in Ukraine and two months latter he didn't complete it. One of our colleagues did it in three days.
My take is if you want to get good results from developers from another country, you have to hire them directly.
I guess outsourcing companies pay their employees very little and they aren't able to hire top talent. And even if the pay was good, best programmers don't like working for outsourcing companies. The ones they do work for outsourcing companies don't care about the quality of their work as long as their company is paid so they get paid, too.
We assigned a task to one guy in Ukraine and two months latter he didn't complete it. One of our colleagues did it in three days.
My take is if you want to get good results from developers from another country, you have to hire them directly.
My experience working in such kind of projects is that bringing back in-house seldom happens, most key devs eventually leave, managers of both companies discuss some new deals during lunch time in how the offhsore company will make up for the loss of quality, and then is business as usual.
We assigned a task to one guy in Ukraine and two months latter he didn't complete it. One of our colleagues did it in three days.
Given the vast discrepancy in turnaround times -- I would seriously start to wonder about the person on your own team who was responsible for cutting out and assigning work to people outside the company.
Who apparently had not even a ballpark idea of how long the task should take. And who perhaps didn't do such hot job of communicating the requirements, now did they. And on top of that, apparently went to sleep on the task of, you know, tracking the status of the project, checking whether the intermediate deliverables (were there any)? actually worked and where up to team standards in terms of quality, etc. And yet they're still on the job, for some reason.
People love to blame freelancers, and they especially love water-cooler tales about how some project (whether by a person/team inside the company, or outside), and then was done by another person/team in a small fraction of the time. But usually there's more to the story.
Given the vast discrepancy in turnaround times -- I would seriously start to wonder about the person on your own team who was responsible for cutting out and assigning work to people outside the company.
Who apparently had not even a ballpark idea of how long the task should take. And who perhaps didn't do such hot job of communicating the requirements, now did they. And on top of that, apparently went to sleep on the task of, you know, tracking the status of the project, checking whether the intermediate deliverables (were there any)? actually worked and where up to team standards in terms of quality, etc. And yet they're still on the job, for some reason.
People love to blame freelancers, and they especially love water-cooler tales about how some project (whether by a person/team inside the company, or outside), and then was done by another person/team in a small fraction of the time. But usually there's more to the story.
Who knows what they need and can describe it? I’ve yet to see that
Ironically, one of the things I think playing around with LLMs like ChatGPT has got me to improve is being (sometimes overly) specific and clear in my requests to them...
[deleted]
I think that’s the point ;)
This is the standard counter-argument to anyone who says AI will replace X. Whatever it is that you think AI can replace tomorrow, you can already outsource today to a human at a super low price. Why haven't you outsourced X yet?
What's the compound rate of improvement of dev shops in India?
[deleted]
[deleted]
The webcrap industry is mostly doing rather uniform things. That can be automated. Much of it already is. Small business sites are mostly machine generated already.
The webcrap industry is crap because most of the people in it believe it can be automated lol.
All the shittest most inefficient projects I've been on have been loaded to the gills with libraries, frameworks, dev tools and convoluted typescript wankery, all in the service of making things "easier" on the devs.
Eventually once they've tinkered enough they get it to the point where it only takes a team of 20 devs 3 years to build a form. Success!
All the shittest most inefficient projects I've been on have been loaded to the gills with libraries, frameworks, dev tools and convoluted typescript wankery, all in the service of making things "easier" on the devs.
Eventually once they've tinkered enough they get it to the point where it only takes a team of 20 devs 3 years to build a form. Success!
Matt Welsh is an idiot, there saved you 5 mins reading the article.
The author's stance also used to be my stance for a long time. Then, earlier this week, I tried out AutoGPT/evo.ninja (which uses GPT-4 under the hood) and told it to "Write me a snake game in HTML, CSS and JavaScript" and, voilà, it wrote me a game that I could open in my browser and it worked perfectly out of the box.
I also tried this with Tic Tac Toe – it didn't work at first due to a bug in the CSS but the agent was able to fix that bug in the second round. It knew the context, knew the files it had created in the first round, and knew what I was talking about when I said "the Xs and Os are not visible", etc.
So, yes, program specs might still be needed in the beginning, when a piece of software gets written from scratch. But AI will often just fill in missing steps, and once the code has been written, the AI will simply iterate on it, and so the code will take on the role of the spec, just like it does nowadays. No need for the product manager to write detailed specs anymore.
All in all, I think the second direction mentioned in the article (AI becoming a full-blown software developer) is a lot more likely than the author thinks.
I also tried this with Tic Tac Toe – it didn't work at first due to a bug in the CSS but the agent was able to fix that bug in the second round. It knew the context, knew the files it had created in the first round, and knew what I was talking about when I said "the Xs and Os are not visible", etc.
So, yes, program specs might still be needed in the beginning, when a piece of software gets written from scratch. But AI will often just fill in missing steps, and once the code has been written, the AI will simply iterate on it, and so the code will take on the role of the spec, just like it does nowadays. No need for the product manager to write detailed specs anymore.
All in all, I think the second direction mentioned in the article (AI becoming a full-blown software developer) is a lot more likely than the author thinks.
Disclaimer: I have not delved into AI to any great degree.
Where this kind of statement ("Holy crap! It wrote me a program and it worked!") tends to make me skeptical is this: the program always seems to be something that's already been done a million times before.
IOW, something that was probably somewhere in the model's input dataset.
I would want to see it produce something truly unique that I'm trying to do for my business -- something that's never been done before. Then we can talk about AI's ending coding.
Until then, they're going to be a tool used by actual coders IMO.
Where this kind of statement ("Holy crap! It wrote me a program and it worked!") tends to make me skeptical is this: the program always seems to be something that's already been done a million times before.
IOW, something that was probably somewhere in the model's input dataset.
I would want to see it produce something truly unique that I'm trying to do for my business -- something that's never been done before. Then we can talk about AI's ending coding.
Until then, they're going to be a tool used by actual coders IMO.
> the program always seems to be something that's already been done a million times before
Most software being written today, in its essence, has been done a million times before. It's just that, from case to case, the tech stack, interfaces, and data structures always differ slightly, which says little about the difficulty of the software problem being solved and is more a function of your organization's history, the developers' background & personal preferences, industry trends, et cetera. In other words: If zoom out a little, the wheel is being re-invented on the daily.
Most software being written today, in its essence, has been done a million times before. It's just that, from case to case, the tech stack, interfaces, and data structures always differ slightly, which says little about the difficulty of the software problem being solved and is more a function of your organization's history, the developers' background & personal preferences, industry trends, et cetera. In other words: If zoom out a little, the wheel is being re-invented on the daily.
"I gave an LLM an extremely small programming task that is a common interview question in a widely used language and I'm shocked it got it right"
The fact that an LLM can code up the game of life/snake/etc faster than you could find a download link is an interesting thing.
If you give it some documentation, background info, code and traceback info (and know to avoid context window poisoning) you can find it's capable of even helping solve rather tedious CUDA/etc issues.
If you give it some documentation, background info, code and traceback info (and know to avoid context window poisoning) you can find it's capable of even helping solve rather tedious CUDA/etc issues.
> extremely small programming task
Maybe, but what I was trying to get at was: If you grant an LLM access to your file system and to the internet (like evo.ninja does), it is already very powerful and can work independently. It will read in and analyze files, remember its original goal even in the middle of some subsubtask it is executing, will self-correct and iterate, et cetera, so context size and the quality of how it solves one-shot tasks are no longer the main limitation.
Of course I am aware we are not "there" yet and I am sure an agent like evo.ninja will still struggle with large, unknown code bases in many cases. (Can't try it on our proprietary code, unfortunately.) But if the past year has taught me anything then it's to not underestimate the future.
Maybe, but what I was trying to get at was: If you grant an LLM access to your file system and to the internet (like evo.ninja does), it is already very powerful and can work independently. It will read in and analyze files, remember its original goal even in the middle of some subsubtask it is executing, will self-correct and iterate, et cetera, so context size and the quality of how it solves one-shot tasks are no longer the main limitation.
Of course I am aware we are not "there" yet and I am sure an agent like evo.ninja will still struggle with large, unknown code bases in many cases. (Can't try it on our proprietary code, unfortunately.) But if the past year has taught me anything then it's to not underestimate the future.
- programmers getting hired and selected by ‘ai’ (resume, interview)
- programmers (their PRs) being checked/reviewed by ‘ai’
- kafkaesque standups where features/bugs are explained by ‘ai’ in a painful loop
- tasks being cut into tiny tasks with time limits by ‘ai’ for human programmers where the ‘ai’ monitors and punishes/awards the human performance
- parts of those tasks being written by the ‘ai’, resulting in alien code being pushed into the project
- ‘ai’ being introduced willy-nilly because it’s cheaper (read; faster to market) than real computer science; why build a parser for formulas? Just put a llm! Why design a robust dsl? Just put a llm!
- etc
This is part of the reality now in places I see already and it will get worse. When LLMs get faster and cheaper, there will be no reason to not add LLMs everywhere and give them some sort of power.