[brundolf]

Something I've been thinking about is that most claims of AI productivity apply just as well (and more concretely and reliably) to just... better tooling and abstractions

Code already lets us automate work away! I can stamp out ten instances of a component or call a function ten times and cut my manual labor by 90%

I'm not saying AI has nothing to add, but the "assembly line" analogies - where we precisely factor out mundane parts of the process to be automated - is what we've been doing this whole time

AI demands a whole other analogy. The intuitions from automating factories really don't apply, imo.

Here's one candidate: AI is like gaining access to a huge pool of cheap labor, doing tasks that don't lend themselves to normal automation. Something like when manufacturing got offshored to China in the late 20th century

If you're chronically doing something mundane in software development, you're doing something wrong. That was true even before AI.

[fhd2]

100%. I keep thinking this, and sometimes saying it.

Sure, if you're stuck in a horrible legacy code base, it's harder. But you can _still_ automate tedious work, given you can manage to put in the proverbial stop for gas. I've seen loads of developers just happily copy paste things together, not stopping to wonder if it was perhaps time to refactor.

[Cthulhu_]

Exactly that. Software development isn't about writing code, never was, it's about what code to write. Doesn't matter if I type in the code or tell an AI what code it should type.

I'll admit that assuming it's correct, an AI can type faster than me. But time spent typing represents only a fraction of the software development cycle.

But, it'll take another year or two on the hype cycle for the gullible managers being sold AI to realise this fully.

[fhd2]

Worse: If typing in code takes more time (i.e. costs more), there's a larger incentive to refactor.

I spent quite a bit of time as a CTO, and at some point there's a conversation about the business value of refactoring. That's a great conversation to have I think, it should ultimately be about business value, but good code vs bad code is a bit hard to quantify. What I usually reached for is that refactoring brings down lead time of changes, i.e. makes them faster. Tougher story these days I guess :D

[sanderjd]

I've been telling friends and family - and kids interested in going entering this field - this for years (decades actually, at this point), that I don't spend much of my time typing out code.

I've found that it's very hard for people to conceptualize what else it would be that we're spending our time doing.

[skydhash]

I think that's a good part of the issue. You have the computer that is doing stuff. And you have the software engineer that was hired to make it do the stuff. And the connection between them is the code. That's pretty much the simplistic picture that everyone has.

But the truth is that the way the computer works is alien and anything useful becomes very complex. So we've come up with all those abstractions, embed them in programming languages with which we create more abstractions trying to satisfy real world constraints. It's an imaginary world which is very hard to depict to other people. It's not purely abstract like mathematics, nor it's fully physical like mechanics.

The issue with LLMs is whatever they produce have a great chance of being distorted. At first glance, it looks like it's being correct, but the more you add to it, the more visible the flaws are until you're left with a Frankenstein monster.

[sanderjd]

Yep, well put.

But to your last part, this is why I think the worst fears I see from programmers (here and in real life) are unlikely to be a lasting problem. If you're right - and I think you are - that the direction things may be headed as-is, with increasingly less sophisticated people relying increasingly more on AIs to build an increasingly large portion of software, is going to result in big messes of unworkable software. But if so, people are going to get wise to that, and stop doing it. It won't be tenable for companies to go to market with "Frankenstein monsters", in the long term.

The key is to look through the tumultuous phase and figure out what it's gonna look like after that. Of course this is a very hard thing to predict! But here are the outcomes I personally put the most weight on:

1. AIs might really get good enough that none of us write code anymore, in the same way that it's quite rare to write assembly code now.

In this case, I think entrepreneurship or research will be the way to go. We'll be able to do so much more if software is truly easy to create!

2. We're still writing, editing, and debugging code artifacts, but with much better tools.

In this case, I think actually understanding how software works will be a very valuable skill, as knocking out subtly broken software will be a dime a dozen, while getting things working well will be a differentiator.

Honestly I don't put much weight on the version of this where nobody is doing anything because AI is running everything. I recognize that lots of smart people disagree with me about this, but I remain skeptical.

[skydhash]

> AIs might really get good enough that none of us write code anymore, in the same way that it's quite rare to write assembly code now.

I don't have much hope for that, because the move from assembly to higher level programming languages is a result of finding patterns that are highly deterministic. It's the same as metaprogramming currently. It's not much about writing the code to solve a problem, but to find the hidden mechanism behind a common class of problems and then solve that instead. Then it becomes easier to solve each problem inside the class. LLMs are not reliable for that.

> 2. We're still writing, editing, and debugging code artifacts, but with much better tools.

I'd put a lot more weight on that, but we've already have a lot of tooling that we don't even use (or replicate across software ecosystems). I'd care much more about a nice debugger for go than LLMs tooling. Or a modern smalltalk.

But as you point out, the issue is not tooling. It's understanding. And LLMs can't help with anything if you're not improving that.

[0]: https://lisp-docs.github.io/cl-language-reference/chap-6/g-c...

[sanderjd]

I probably should have specified: I didn't list those in the order of what I put most weight on. I agree with you that I more heavily weight the one I wrote as #2.

I think you and I probably mostly agree on where things are heading, except that just inferring from your comment, I might be more bullish than you on how much AIs will help us develop those "much better tools".

[Izkata]

> It's an imaginary world which is very hard to depict to other people. It's not purely abstract like mathematics, nor it's fully physical like mechanics.

This is one of the reasons I like the movie Hackers - the visualizations are terrible if you take it at face value, but if you think of it as a representation of what's going on inside their minds it works a whole lot better, especially compared to the lines-of-code-scrolling-past version usually shown in other movies/tv.

For anyone who doesn't know what I'm talking about, just the hacking scenes: https://youtu.be/IESEcsjDcmM?t=135