We think that software development is entering its third wave of productivity change. The first was the creation of tools like compilers, debuggers, garbage collectors, and languages that made developers more productive. The second was open source where a global community of developers came together to build on each other's work. The third revolution will be the use of AI in coding.

The problems we spend our days solving may change. But there will always be problems for humans to solve.

This innovation does not seem like a natural successor to compilers, debuggers and languages. If today's programming environments still require too much boilerplate and fiddling with tools, it seems like better programming languages, environments that require less setup, etc would be a better use of time. Using GPT to spit out code you may or may not understand seems more like a successor to WSDLs and UML code generators. I really hope we're just in a wild swing of the pendulum towards complex tooling and that we swing back to simplicity before too long.

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.

If this is the drive behind this project, seems like you are putting too many eggs in one basket. Maybe a good attempt to get rid of the "glue" programming but, I wouldn't pay for this. Its all trivial stuff that I now need to review.

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.

I appreciate this insight, as a proponent of progress studies. It is indeed a pragmatic view of what the industry will be or should be. I believe the thing that would be also appreciated would be a pair security auditor. Most vulnerabilities in software can be avoided early on in development , I believe this could be a great addition to Github's Security Lab securitylab.github.com/

Do you or 'natfriedman have authored any works in a public repository, so that we can judge the validity of the pragmatic view?

I'm super interested to read more about your theory/analysis. Have you written on it in a blog or anything?

There's a good amount of discussion on this topic in "The Mythical Man-Month". The entire book is discussing the factors that affect development timeframes and it specifically addresses whether AI can speed it up (albeit from 1975, 1986 and 1995 viewpoints, and comparing progress between those points.)

Thanks! That's a great suggestion. I forgot that was in there.

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.

Let's solve the problem of replacing CEOs next. The above paragraph could have been written by GPT-3 already.

I think this is already happening. There's credible evidence that the Apple CEO, Tim Cook, has been essentially replaced by a Siri-driven clone over the last 7 months. They march the real guy out when needed, but if you watch closely when they do, it's obvious he's under duress reading lines prepared by an AI. His testimony in the Epic lawsuit for example. They'll probably cite how seriously he and the company take 'privacy' to help normalize his withdrawal from the public space in the coming years.

This is exactly the kind of fun, kooky conspiracy theory I've missed with all the real conspiracies coming to light over the last decade or so.

Can you cite some of this credible evidence?

I think you’re looking at the problem the wrong way. This provides less strong engineering talent with more leverage. The CEO (which could be you!) gets closer to being a CTO with less experience and context necessary (recall businesses that run on old janky codebases or no code platforms; they don’t have to be elegant, they simply have to work).

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.

That's not really how it's going to go though. Just look at what your average person is able to accomplish with Excel.

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.

> Just look at what your average person is able to accomplish with Excel.

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=24791017 (HN: Excel warriors who save governments and companies from spreadsheet errors)

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!)

Yes, Excel “runs the world”, and in most organizations, you’ll find a fairly narrow slice of Excel power users that build and maintain the Excel that “runs the world”.

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.

Well, agree to disagree here as I’ve seen it with my own eyes, but it’s kind of besides the point.

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.

LOL. But you actually make a good point here. GPT-3 can replace most comms / PR type jobs since they all sound like Exec-speak.

Usually I agree but I think Nat's comment here makes perfect sense and isn't just some PR buzzword stew. Tools like these are basically a faster version of searching stack overflow. You could have suggested that things like github and stack overflow would replace programmers since you could just copy and paste snipits to write your code.

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.

natfriedman is a human being like you and me, not an AI; let's treat them with consideration for that.

Perhaps he should go easy on the euphemisms then and show respect for the developers who wrote the corpus of software that this AI is being trained on (perhaps illegally).

OK, then ask him to go easy! Great idea, and it might get a good response.

How many jobs have developers helped displace in business and industry? I don't think it's controversial that we become fair game for that same automation process we've been leading.

>How many jobs have developers helped displace in business and industry? I don't think it's controversial that we become fair game for that same automation process we've been leading.

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.

> historically when has that sort of 'tit-for-tat' style of argument ever been helpful?

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 jobs have developers helped displace in business and industry?

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.

> A human (developer) displacing another human (business person) is entirely different

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.

> 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.

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.

Nope, before the modern approach to shipping stuff you simply couldn't get many different things unless you were in a big city. There weren't humans doing the route planning, there was no one because it wasn't worth doing at all.

> SWE is a complex field, way more than typing a few routines. In best case (technologically speaking) this will be an augmentation.

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.

Indeed. It should be the goal of society to automate away as much work as possible. If there are perverse incentives working against this then we should correct them.

1. How do you define work differently from "that which should be automated"?

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).

I agree, the fact we're even talking about this is evidence that our society has the perverse incentive baked in and we should be aware of and seek to address that.

Regardless, programmers would be hypocritical to decry having their jobs automated away.

That's why it's best to get unions or support systems (like UBI) before they're needed. It's hard to organize and build systems when you have no leverage, influence, or power left.

Why is the disparity bad?

What do you mean by "bad"? If you're asking why it makes sense to structure society with an eye toward avoiding disparity, then it's enough to just observe empirically that people have an aversion to unfair treatment. And not just people: https://en.wikipedia.org/wiki/Social_inequity_aversion

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.

Human beings need something to do to have a fulfilling life. I do not agree at all that the ultimate goal of society is to automate everything that’s possible. I think that will be horrible overall for society.

My job is probably the least fulfilling activity in my life and I'm sure that goes for a lot of people.

By your reasoning, maybe we don't need backhoes and should just hire a bunch of guys with spoons instead?

I typically find other things fulfill my life more than work.

I would be up for that, if said society did not leave us destitute as a result

Nothing is inevitable. Doctors and lawyers have protected their professions successfully for centuries.

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!

This tool only replaces a small part of a good programmer and just further highlights the differences between people blindly writing code and people building actual systems.

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.

> Doctors and lawyers have protected their professions successfully for centuries.

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?

This feels like people protesting against automation by not using the automated checkout machines at a store. Go ahead, faster queues for me.

> This is obviously controversial, since we are thinking about how this could displace a large portion of developers.

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.

I agree with this viewpoint.

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.

In just 2-3 years time DL algorithms will have as many synapses (parameters) as the human brain. The only thing needed to teach such algorithm to program better than us it to say to it that program needs to be faster, more secure and more user friendly (it's not impossible to teach this to DL alg.). This "tool" will make our work 90% easier in the next few years, so unless we have much more work to do we will earn much less and juniors will most likely be not needed anymore...

Intel put itself out of business since all the world's computing needs can now be done on one CPU.

Or, perhaps, lower unit costs of computing lead to far far greater demand for computing since it became practical to apply to more domains.