Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new way to predict when software jobs will become automated

aifuture.substack.com

Post reply on HN
Print view View original

121–129 of 129 posts

Re: A new way to predict when software jobs will become automated

#121

Post by imtringued »

qualudeheart wrote: post #68
29athrowaway wrote: post #21

Earlier quoted context omitted.

Self-checkout at supermarkets does 90% of the work. The 10% of work remaining is done by a human supervising the self-checkout stations. And same will happen to development. Lots of tasks will be automated and less people will be needed as a result.

That’s a scenario people don’t seem to explore. The scenario in which demand for labor drops massively but human labor is still needed. Many industries would lose 80% of workers, but 20% would remain. Those 20% would be very high status and well paid, at least compared to the UBI neo-serf class that yheir former colleagues of the 80% have fallen off into. It is yhese 20% that woll form a new upper middle class. They…

You know, the entirety of economics is doomed because frankly it is just there to justify and explain wealth inequality rather than actually maximize economy efficiency. The laffer curve is the go to example people bring up. Completely made up.

Re: A new way to predict when software jobs will become automated

#122

Post by lamontcg »

Ekaros wrote: post #113
lamontcg wrote: post #111

"playing go" is actually a very constrained problem domain. "design and implement a SasS product that humans will give you money for" is a much less well-defined problem. applying AI to boilerplate will probably be effective, but that might just eliminate more outsourcing and allow local devs to be more productive, as an extension of IDEs that have various macros to reduce boilerplate. i think getting past that to th…

Go is actually pretty simple game, alternate between placing stones, if stones connected have no open spaces remove them and lose points. The decision space is huge, but that is pretty much it. Now SaaS is one thing, but who would trust industrial control software for AI. At least current one. Here is oil refinery, make money. Oh, take these bank details as well and go figure it out...

"Okay GitHub Copilot go design the flight computer for the next generation of SpaceX rockets" (proceeds to regurgitate MechJeb code from KSP).

Re: A new way to predict when software jobs will become automated

#123

Post by p1esk »

benreesman wrote: post #118
p1esk wrote: post #110

Earlier quoted context omitted.

Yeah I don't know where benreesman pulled that statement from, neither the blog post nor the original OpenAI paper claims anything of the sort. That aside, I'm not sure how impressive is an AI that could do 37% of "all coding tasks". It's like a self-driving car that only works 37% of the time.

From TFA: “OpenAI estimates that OpenAI Codex (what powers Github’s Copilot) can already complete 37% of coding tasks.”

Are you intentionally trying to hide that “coding tasks” in the blog article is a link to the paper, clearly explaining what these coding task are? And you, for some reason, decided to add “all” before “coding tasks”.

What are you trying to pull?

Re: A new way to predict when software jobs will become automated

#124

Post by WheelsAtLarge »

People seem to think that automation needs to be 100% or nothing. Automation at 80%(or whatever percent) of ideal will affect a large number of programming jobs. If you as a programmer start to compete without the use of AI vs someone that has embraced it then you are going to lose. If you can get an AI to do 80% of your work and you as a sentient being can finish the project then your output will explode vs someone that does not.

This says to me that the future programmer will be closer to a software architect. Someone that can interpret what someone wants and decide what the solution is using all the resources available including AI tools. Not all programmers can do that. I've known plenty of programmers that are great at their job but lack social skills. Those are the type that will definitely be affected by AI. Given that you don't need 100% perfection in AI to make an impact in the industry and programming jobs then I see big changes happening with-in the next 10 years at most.

Don't believe it? Look at Dall-e 2. It won't get rid of designers or such but many people will start to use it in some cases and by-pass the designer all together. Also a new crop of designers will use Dall-e 2 to create some of their work. Those that won't will be left behind.

Designers today, programmers next... Yes!

Re: A new way to predict when software jobs will become automated

#125

Post by UncleEntity »

ethbr0 wrote: post #75
UncleEntity wrote: post #56

Earlier quoted context omitted.

I would argue that horse drawn carriages were a 100% solution for something like 8000 years of human history. It’s been barely over a hundred years where there has been something that could efficiently replace them and the ‘self driving’ modern replacement have maybe 0.01% the smarts of a horse. I mean, go get drunk and pass out on the back of your horse and the chances are real good it’s going to take you home witho…

Horses produce a lot of shit, need to be fed, generate rather large biohazards when they expire, and have an oscillating motion that isn't a great match for drunkenness. "A horse for every person" probably wasn't the best of times. On the other hand, they are excellent listeners.

They’re also zero-carbon which is fairly important these days.

Re: A new way to predict when software jobs will become automated

#126

Post by vba616 »

What's all this, then?

Programming was automated 65 years ago.

The "Formula Translating System" introduced in 1957 eliminated the drudgery of programming by allowing users to simply enter equations into a computer directly.

Specifying machine instructions and memory addresses by hand rapidly became a thing of the past.

Today, having a programming assistant is as quaint as a secretary.

Re: A new way to predict when software jobs will become automated

#127

Post by saghm »

imtringued wrote: post #120
saghm wrote: post #72

Earlier quoted context omitted.

I think this experience probably varies a lot person-to-person. For someone like me who often experiences social anxiety even from the most minimal of interactions, being able to keep my earbuds in and not have to talk to a stranger can be a huge difference if I'm happening to feel stressed on a given day. The biggest issue I used to have was when I wanted to carry something out instead of putting it in a bag, but si…

You can't ruin a cashier's day by being nice to them, they won't hate you for that.

Sure, and I do always strive to be nice to anyone I have to interact with whether they're cashiers or otherwise. Social anxiety doesn't tend to be a rational thing though, so the fact that consequences aren't unlikely doesn't really make it go away. I know that nothing bad is going to happen from a minor social interaction, and yet that does absolutely nothing to make me dread it less if I'm happening to be in an anxious state. A lot of mental health things work similarly to this; for example, having depression doesn't just mean you're sad because things aren't going well, but you can be despondent despite everything going perfectly fine in your life. If you can't imagine having feelings like this that conflict with what you actually know about a situation, then you're one of the lucky ones, but you probably do know someone who would know exactly what I'm talking about.

Re: A new way to predict when software jobs will become automated

#128

Post by crdrost »

qualudeheart wrote: post #80
crdrost wrote: post #76

Marx talks about this a bit in Das Capital ... You would think that the automation of an industry improves working conditions inside of it, in practice the opposite has usually been true: fewer people work longer hours in ever-more-tedious ways. So you used to go to work to design something, but in this vision of the future, you now go to work to craft prompts to DALL-E-2 so that it can design something for you, but…

What’s the “Smalltalk revolution?”

It is in the history of the programming language Smalltalk, that it was meant to usher in a new era of computing.

This era would be built on several basic principles. The first one is that you would have no real separation between source code in some text editor, and the running program—a prophecy that has yet to come to pass. All the rest of us rely on shooting a misbehaving program in the head and birthing a similar child with slightly altered DNA to replace it... Smalltalk expects you to have a conversation with the program as it runs: the whole programming language is instrumented with reflection, and every module is hot reloadable. There is literally a method, Object.become, “OK computer, take all of the references anyone has pointing to that other object and point them to me, I will be taking over for it.” Bold.

A second conceit is that the new way to be a programmer, the new metaphor, is not one of traditional authoritarianism—think in particular of remote procedure calls. But the new metaphor will be biological: a module will peek around its environment, maintain a “homeostasis” of inner state consistency, the system as a whole will be tolerant of intra-module logical inconsistency, while the individual cells will just die if they cannot maintain consistent state, cells live, cells die, cells organize into larger tissues and organelles and organs in order to find their greater purpose.

A third great principle is fractal architecture, the idea that the parts should contain the essence of the whole. So in functional programming you might build a computer program out of parts that are not computer programs. But Smalltalk wants to say, no: every computer program in this language will be constructed out of units that are fully fledged computers in their own right, running one or many computer programs. And so there is no need for all of these computers to be on the exact same host machine, of course they can be because a computer can pretend to be multiple computers by task scheduling, but it is not necessary.

Related to that, there is a vast skepticism towards locking and atomicity. Implement virtual time, or leverage the full power of the actor model... Those are preferable.

Re: A new way to predict when software jobs will become automated

#129

Post by benreesman »

p1esk wrote: post #123
benreesman wrote: post #118

Earlier quoted context omitted.

From TFA: “OpenAI estimates that OpenAI Codex (what powers Github’s Copilot) can already complete 37% of coding tasks.”

Are you intentionally trying to hide that “coding tasks” in the blog article is a link to the paper, clearly explaining what these coding task are? And you, for some reason, decided to add “all” before “coding tasks”. What are you trying to pull?

I’m not trying to “pull” anything. I find the notion that Codex/Copilot is within 2-3 orders of magnitude from writing code I’d trust without a careful audit that does anything more than some CRUD thing in JS framework du jour to be Kurzweil-whacko singularity shit, and that the only people trying to “pull” anything here are the people training GPT-3 on everyone’s GutHub repository without permission or attribution and exploit non-expert opinion to generate yet another round of hype, hysteria, and mysticism about that magical pair of two undefinable words: “artificial” and “intelligence”.

I regret mis-quoting TFA by an article, because if I cited it correctly I’d really lay the fucking smack down here.

Have I adequately answered your condescending question?

Post reply on HN