When asked about what jobs the robots would come for first, I would have had to say that digital artist was pretty low on my ranking before now.
It won't be long before most software engineer positions are eliminated while some are replaced by software "technicians" with enough expertise to command AI to generate working code. Perhaps the technicians will be tasked with building tests and some automation, but even that stuff can be delegated to AI to an extent.
This may seem far off because the present economy is accustomed to paying engineers large sums of money to write apps. Even with the retractions we've been seeing in hiring and venture capital, there's just enough easy money still there and the capabilities of code-writing AIs isn't quite there yet.
All we need is a significant market correction and the next generation of AI to wipe out a large swath of tech jobs.
The next step regardless is applying technologies like DALL-E to web design, and for said technology to be widely used, open and affordable. We won't need web designers or even UXD.
Then we won't need as many engineers when AI can solve a lot of common problems in building software. AI can do it better because it won't spend inordinate amounts of time dillydallying over next-gen frameworks, toolchains, and preprocessors. AI won't even have to worry about writing "clean" and maintainable code because those things will no longer matter.
For that scenario to be possible, general AI needs to be developed first.
A huge (and awful) part of software engineering is figuring out what exactly the stakeholders want you to build or fix. Sometimes, they themselves don't even know.
Dealing with ambiguos jira tickets, poorly reported bugs, non-existent requirements, missing or outdated documentation; these are the "common problems" in building software. Current AI technology isn't even close to being able to sort these types of problems today, and it won't be until a monumental breakthrough in the field is achieved.
Generating art is "easy" in the sense that art can't be wrong or right, it just is.
Generating the backend of a streaming platform? I'd like to live long enough to see it.
Ask any creative out there what the hard part of their job is.
Yeah, but that part can be learned by anyone without a CS degree.
Perhaps not everything in software can be automated, but I could see a team of 10 programmers be replaced by 1 person (programmer or not) skillful enough to control a bunch of AI software tools.
I already see a clear path that'd take about 20 years to execute properly. That's assuming low pressure conditions and a very large amount of funding though, both of which aren't typically present in reality.
The result is essentially what GP describes, with a path to AGI in the form of extremely competent tool AI. We're going to hit self-assembling programs before we hit true AGI.
I can't say I'm particularly excited to see such things become reality. Fortunately, humans usually find a way to fuck things up. Our species' collective incompetence is the largest barrier to AGI currently, which may be a blessing in disguise depending on how you look at it.
Engineering is a different ballgame... If anything, all the code monkeys will simply become QA monkeys/test-engineers, because you need to be really sure that your black box algorithm is actually doing what you think it should be doing.
People keep trying to make simplified programming environments for significantly less-trained people and they keep failing. Is mixing in an AI actually going to make it easier to get a result that has no crippling bugs?
Yeah. I've even worked in one of those environments for a year (not my choice).
I'm of the opinion those kind of environments won't ever work. They'll either be:
1. Extremely cookie-cutter (e.g. make a clone of our "standard app" with a insignificant little tweaks).
2. Require software engineers to get anything useful out of them, and those engineers will feel like they're working with one hand tied behind their backs (or banging their heads against a wall).
IMHO, one of the main skills of a software engineer is translating user requirements into technical requirements that work and understanding when they work. I don't think skill is automatable without a fairy-tale AGI.
> No, but when have crippling bugs ever stopped software businesses from shipping it anyway?
A lot? Depends on your definition of "crippling." A software engineer will gripe and say, "I don't want to use this;" something that's awkward but the people who use it can still get their work done; or the system literally incapable of performing its function?
In software, yeah boiler-plate and function-level code-generation... I could also see generating trivial UIs for CRUD apps, or no-code data-pipelines for small businesses... maybe even generating high-level architectures for new services... but we're far off from AI auto-generating code for enterprise applications or foundational services. The differentiation being making changes within an existing complex domain/code-base, in contrast with generating new assets from nothing.
Source: My family owns one of the largest civil engineering firms in my home province.
Pick any random Jira ticket for a large software project. Could an AI understand and implement that feature into a larger project? Can it correctly deploy it without interruptions to production jobs? Will it correctly implement tests and decent code coverage? If there are regressions will it know how to go in and fix them? If there are bugs reported by users will it be able to investigate and accurately fix them? What about when multiple branches of feature development have to be merged, will it know how to do it correctly? Will it know how to write high performance software or just use shitty random algorithms?
If it can’t do these things AI is basically useless. Because this is basically 90% of software development.
Most likely, the APP-E or GAME-E, given a prompt generate an application or game, will not generate C++/JavaScript/Swift/Kotlin but directly target the pixel space, running in a 60+ FPS loop a single "function" such as `nextFrame(currentState)`.
It will probably be here in the next few years: write a prompt such as "2D game like Mario but with butterflies" and receive a 2GB blob which opens a window accepting inputs and changing the pixels accordingly. Or, something more serious, a prompt like "invoicing application following the laws of France, Material Design, store the database in AWS using <token>". APP-E or GAME-E doesn't need to totally replace software development, just be good enough to replace in 99% of use cases.
Bugs/tests could probably be solved by some mechanism for injecting localized prompts: given an already generated binary, fine tune it accordingly to a list of other prompts.
As for deployment, it's already pretty much solved with the CI/CD solutions galore all around, not sure why you would need generative statistics for it.
What DALL-E offers is a glimpse of the next 30 years, and probably 99% of the infrastructure required to run it to its full potential is not here yet. Just as in 1992 (3 years after the HTTP proposal, but 2 years before the launch of Netscape) there were only glimpses of what a connected world would look like.
My point was that something like APP-E or GAME-E seems very plausible in the near future and it is more likely to render pixels with the underlying logic encoded in an inscrutable sparse matrix, somewhat the consequence of a beefier DALL-E with regard to the data set, the learning modalities, and the attention span, than to write programs to be compiled/interpreted by any current language stack.
With software it might take days of testing to verify the result, and then repeat that for every iteration. Would be cheaper to build the thing!
Where AI might work is in some restricted subset of software, like a web CRUD app where you say "I want an app that stores a TODO list with dates". With the constraints of it being crud, it just needs to AI the database and arrangement of fields and so on.
The AI is not programming so much as it is choosing which "rails-like scaffolds" to initiate.
The serious engineers are all working on things that go far deeper, and they could never be replaced.
If you want to build a business big enough to be listed on the NASDAQ, you need real developers, and you need to pay them real money.
One could think that much of art is just pretty form without sense and that is why DALL-E works.
Most art is not "pretty form without sense". It actually has sense and meaning more often than not, so we can debate what a particular piece "means".
The difference with engineering is that art's meaning is way more subjective, and that if I "miss the point" or simply disagree with the consensus on its meaning, this doesn't make an airplane go down or a nuclear reactor to melt down.
One, coming up with a correct description of a program is what computer programming actually is. Implementation is something we're always looking to do faster, so we can describe more behaviors to the computer.
Two, we're nowhere near the scale of software production which would clear market demand. If everyone who writes code for a living woke up and was ten times as productive, there would be more churn than usual while the talent finds its level, but the result would be ten times as much code per year, not five times and 50% unemployment.
Today I wrote a little bit of code to generate a prefix trie and write it out in a particular format, with some extra attention to getting the formatting 'nice'. This took me about three hours.
It won't be long before something in the nature of Copilot could have gotten this down to, maybe, a half hour for results of the same (minimal, acceptable) quality.
Wonderful! Can't wait, I'll be six times as productive at this kind of task.
This might make it hard, on the margin, for some of the more junior and glue-oriented developers to find work, but I think the main result will be more software gets written, the same way using a structured programming language got people further in a day than writing in assembler did.
In a good number of cases it is more difficult to communicate what needs to be built rather than actually building the end product.
The recent work with DALL-E 2 echos a similar problem, coming up with a descriptive prompt can be difficult to do and needs fine tuning to be done. Not unlike trying to communicate with a graphic designer your expected intentions and giving similar works to draw from.
However, software development is probably the most thoroughly documented job, the job with the most information online how to do it right, the job with the best available training set. There is a lot of quality code (yes, bad code too), a lot of questions and answers with sample code (stackoverflow...) available. Maybe we've even already written most the software needed in the near future, it's just not available to everyone who needs it (because no one knows all the things out there and also these might be in several pieces in several repos).
Now the one critical thing I think is still needed, based on how actually we create software is an agent that has reasonable memory, that can handle back references (to what it has been told earlier), i.e. one that can handle an iterative conversation instead of a static, one time prompt.
This might be a big leap from where we are now or it may seem like one but AI/ML keeps surprising us for the past decade or so with these leaps. Another thing that may be needed is for it to be able to ask clarification questions (again, as a part of an iterative conversation). I'm not sure about this latter one, but this is definitely how we do the work.
You still need correct code, and the halting problem says you can't prove whether code does what you want it to. At the end of the day, someone needs to be able to go in and fix shit the AI did wrong, and to do that you need to understand the code the AI wrote.
> You still need correct code, and the halting problem says you can't prove whether code does what you want it to. At the end of the day, someone needs to be able to go in and fix shit the AI did wrong, and to do that you need to understand the code the AI wrote.
This might have been your point, but chances are the "code the AI wrote" will be an unmaintainable mess, so "fixing it" means throwing it away and re-doing it.
There's a reason why the general models aren't being released. The second you look under the hood and start poking the unhappy paths you see that it doesn't understand anything and you're talking to something dumber than a hamster.
I lean towards the latter but with a healthy dose of "it's deeply weird and hard to get anything useful from". But that doesn't make it any less magical.
And no - it's not "intelligent" in any human sense.
But I can't relate to people who pooh-pooh it as if there's nothing exciting happening. Either they are deliberately cultivating a dismissive air, or they are deeply jaded and weary.
EDIT - There's a 3rd option. People are making a rhetorical point because they perceive a need to correct an imbalance in the general mood. This is actually the most likely explanation and is often under-appreciated as motivator in public statements. I've noticed it in myself frequently.
This was true for state of the art in 2010: https://xkcd.com/1425/ today you have a free phone app that does both. Of course it also classifies a spoon as a large breasted robin which is why you need a human in the loop. It's even truer in programming.
I think that in the very long run programming work will be automated, but by that stage we will either be post-scarcity or reconstituted in computation substrate.
I'm looking for ways to hedge my reliance on my skills.
The 20th time you hear that is when you stop caring.
however, I find that my job (SWE) is about 1% programming and 99% strategizing, designing & communicating.
After experimenting with GitHub Co-Pilot I can see that day being 50% - perhaps even just 25% - as far as it used to feel.
I don't know, after all the predictions about self-driving cars, I'm cautious. Especially considering that back then, it almost seemed obvious that we'd have self-driving cars by now. Cars were certainly capable of driving themselves back in 2016, it just seemed like we needed to iron out a few kinks. How long could that possibly take?
Now, I have no idea when it'll happen.
I'm not necessarily saying that it'll take AI forever to do what humans can do. Rather, I think its very hard to make good predictions with all the hype slightly deceptive marketing.
An AI artist can get away with a 5% success rate and still be considered viable for replacing humans.
Likewise, and AI programmer can be right only 50% of the time with expert oversight (someone sitting there fixing the code), or 90% with non-expert oversight.
Also, if your bar for accidents is "slightly better than a drunk driver and even less accountable", sure, then we can fully deploy that right now. Unfortunately this really isn't sufficient and car companies are fully aware. There's a reason Mercedes made headlines by taking responsibility for the car for ten seconds after disengaging the auto pilot and why they're the only ones who are doing this so far.
To most people, the "readiness" of self-driving cars doesn't even come about when they would accomplish parity with human drivers across all situations, because they should be better. And we're not even close to parity with human drivers across a large swath of common situations.
Unless you have links showing otherwise...
We can also talk about AI support service crap with accounts banned/locked without the user having any way to know why or prove he didn't break any terms of the contracts.
I'm biased from the terrible experience I had trying to get my kids to learn online in the pandemic, but I think schoolteacher might be one of the mass professions that is least susceptible to being AI Engineered away.
Ethicist is probably a safe career path too, but there aren't that many of those. And Politicians will of course prevent robots from taking over their jobs.