The problems we spend our days solving may change. But there will always be problems for humans to solve.
It all boils down to who is capturing the value for the effort and time expended. If a mediocre software engineer can compete against senior engineers with such augmentation, that seems like a win. Less time on learning language incantations, more time spent delivering value to those who will pay for it.
Your own example of the CEO becoming a CTO can be used in every level and part of the business.
Now the receptionist is building office automation tools because they can describe what they want in plain English and have this thing spit out code.
Approximately nothing.
The average knowledge worker somewhat more, but lots of them are at the level of “I can consume a pivot table someone else set up”.
Sure, there are highly-productive, highly-skilled excel users that aren't traditional developers that can build great things, but they aren’t “your average person”.
https://news.ycombinator.com/item?id=26386419 (HN: Excel Never Dies)
https://news.ycombinator.com/item?id=20417967 (HN: I was wrong about spreadsheets)
https://mobile.twitter.com/amitranjan/status/113944938807223... (Excel is every #SAAS company's biggest competitor!)
We may not call them developers or programmers (or we might; I’ve been one of them as a fraction of my job at different times, both as a “fiscal analyst” by working title and as a “programmer analyst” by title), but effectively that's what they are, developers using (and possibly exclusively comfortable with) Excel as a platform.
Is it a coincidence that the same company that makes Excel is trying to… “democratize” and/or de-specialize programming?
I don’t really think so, but shrug.
And sure, we do now have tools like square space which fully automate making a basic business landing page and online store. But the bar has been raised and we now have far more complex websites without developer resources being wasted on making web stores.
I read Mythical Man Month many years ago and enjoyed it. Time for a re-read. Of course it won't cover the third wave very well though. Would love to see a blog post cover that.
Edit:
To expand a little and not sounds so completely negative towards AI, seems like there could be value in training models to predict whether a patch will be accepted, or whether it will cause a full build to fail.
It would be a "cool tool" if it inspected the code statically and dynamically. Testing the code to see if it actually does what the AI thinks it should do. From running small bits of code on unit level to integration and acceptance testing. Suggest corrections or receive them. _That_ will save time and I and companies will pay for.
Also you cannot call this the "third revolution" if it is a paid service.
2. While I agree with your stance, it is not by itself sufficient. If you provide the automation but you do not correct the perverse incentives (or you worry about correcting them only later) that you mention, then you are contributing to widening the disparity between a category of workers (who have now lost their leverage) and those with assets and capital (who have a reduced need for workers).
Regardless, programmers would be hypocritical to decry having their jobs automated away.
If you're asking why do people respond the way they do to disparity, then I can only speculate that it has something to do with the meaning of life.
By your reasoning, maybe we don't need backhoes and should just hire a bunch of guys with spoons instead?
historically when has that sort of 'tit-for-tat' style of argument ever been helpful?
the correct approach would be "we've observed first hand the problems that we've cause for society, how can we avoid creating such problems for any person in the future?"
It might seem self-serving, and it is, but 'two wrongs don't make a right'. Let's try to fix such problems rather than serving our sentence as condemned individuals.
It's not tit-for-tat, it's a wake up call. As in, what exactly do you think we've been doing with our skills and time?
> ""we've observed first hand the problems that we've cause for society"...
But not everyone agrees that this is actually a problem. There was a time when being a blacksmith or a weaver was a very highly paid profession, and as technology improved and the workforce became larger, large wages could no longer be commanded. Of course the exact same thing is going to happen to developers, at least to some extent.
How many?
> I don't think it's controversial that we become fair game for that same automation process we've been leading.
This is not correct. A human (developer) displacing another human (business person) is entirely different than a tool (AI bot) replacing a human (developer).
Regardless, this is the Lump of Labour fallacy (https://en.wikipedia.org/wiki/Lump_of_labour_fallacy).
In this case, it is assumed that the global amount of development work is fixed, so that, if AI takes a part of it, the equivalent workforce in terms of developers, will be out of job. Especially in the field of SWE, this is obviously false.
It also needs to be seen what this technology will actually do. SWE is a complex field, way more than typing a few routines. In best case (technologically speaking) this will be an augmentation.
That's not what is happening though, a few developers replace thousands of business and industry people with automated tools. Say, automated route planning for package delivery, would take many thousands of humans if not for the AI bots that do the job instead.
> SWE is a complex field, way more than typing a few routines. In best case (technologically speaking) this will be an augmentation.
Of course there will always be some jobs for humans to do. Just like there are still jobs for humans loading thread into the automated looms and such.
But your arguments against automation displacing programming jobs ring hollow. People said the same thing about chess playing programs, they would never be able to understand the subtlety or complexity like a human could.
Without reading and understanding the lump of labour fallacy, it can't be understood the relation between the fallacy and the displacement of jobs. In short, the fallacy is not incompatible with the displacement argument; the difference is in the implications.
> But your arguments against automation displacing programming jobs ring hollow. People said the same thing about chess playing programs, they would never be able to understand the subtlety or complexity like a human could.
Chess is a finite problem, SWE isn't, so they can't be compared.
If there is a pathway to improving this AI assist efficiency say by restricting the language, methodology, UI paradigm and design principles, it will happen quick due to market incentives. The main reason SWE is complex is it's done manually in myriad subjectively preferred ways.
Only some software developers seem interested in replacing themselves in order to enrich their corporate masters (mains?) even further.
Just don't use this tool!
And one could argue that this means we all pay more for health and legal services than we otherwise would. You have to calculate both costs and benefits; what price does society pay for those few people having very high paying jobs?
The challenge in software development is understanding the real world processes and constraints and turning them into a design for a functional & resilient system that doesn't collapse as people add every little idea that pops into their head.
If the hard part was "typing in code" then programmers would have been replaced long ago. But most people can't even verbally explain what they do as a series of steps & decision points such that a coherent and robust process can be documented. Once you have that it's easy to turn into code.
It... couldn't, in net.
Tools which improve developer productivity increase the number of developers hired and the number of tasks for which it is worthwhile to employ them and the market clearing price for development work.
See, for examples, the whole history of the computing industry as we’ve added more layers of automation between “conceptual design for software” and “bit patterns in hardware implementing that conceptual design as concrete software”.
It might displace or disadvantage some developers in specific (though I doubt a large portion) by shifting the relative value of particular subskills within the set used in development, I suppose.
A tool which increases how rapidly we can output code—correct code—would allow for more time spent on hard tasks.
I can see the quality of some "commodity" software increasing as a result of tools in this realm.
Or, perhaps, lower unit costs of computing lead to far far greater demand for computing since it became practical to apply to more domains.