This article is really only useful if LLMs are actually able to close the gap from where they are now to where they want to be in a reasonable amount of time. There are plenty of historical examples of technologies where the last few milestones are nearly impossible to achieve: hypersonic/supersonic travel, nuclear waste disposal, curing cancer, error-free language translation, etc. All of which have had periods of great immediate success, but development/research always gets stuck in the mud (sometimes for decades) because the level complexity to complete the race is exponentially higher than it was at the start.

Not saying you should disregard today's AI advancements, I think some level of preparedness is a necessity, but to go all in on the idea that deep learning will power us to true AGI is a gamble. We've dumped billions of dollars and countless hours of research into developing a cancer cure for decades but we still don't have a cure.

In software we are always 90% there. Is that 10% the part that gives us jobs. I don’t see LLMs that different from, let’s say, the time compilers or high level languages appeared.

Until LLMs become as reliable as compilers, this isn't a meaningful comparison IMO.

To put it in your words, I don't think LLMs get us 90% of the way there because they get us almost 100% of the way there sometimes, and other times less than 0%.

Compilers reliably solves 90% of your problems, LLM unreliably solves 100% of your problems.

So yeah, very different.

I disagree with this take. LLMs reliably solve 20% of my problem and are a gamble for a few percent more. There are problems that LLM is reliably not solving.

You have a point, but people would just say "you use it wrong, just prompt better" and so on.

The selling point is that it unreliably solves all your problems, "this model is PHD level intelligence!", compilers we know solves some problems and can't solve others, for LLM what they can actually do is very poorly understood by most since marketing oversells it so hard.

If it's not reliable then the problem is not solved

You've just moved the problem from "I can't solve this" to "I can't trust if the LLM solved this properly"

There is a level of reliability that is sufficient, as proven by us humans, the existence of issue trackers, and the entire industry that is software QA.

And, further, the existence of offshore, low quality, contractors that are in such frequent use.

Precisely. The code I would get from that type of contractor had a similar reliability as what I generate today with nothing but the $20 a month level of AI stuff. Of course, we have the option of making the AI rewrite it in 2 minutes or so to fix its mistakes without waiting for it to be day there again.

AI replacing outsourcing and (sadly) junior SWEs is more likely than it just eliminating coding jobs across the board. Lord help them when our generation of senior SWEs retires, though!

> AI replacing outsourcing and (sadly) junior SWEs is more likely than it just eliminating coding jobs across the board. Lord help them when our generation of senior SWEs retires, though

Not them

It's on current software devs to make sure this doesn't happen! People in senior positions need to be loud and aggressive about telling the money people that we cannot rely on AI to do this work!

Every time you shrug and say "yeah the LLM does ok junior level work" you are part of the goddamn problem

What problem? It's not my problem if my employer is screwed after my generation retires. That's the shareholders or owners' problem. The people making 2-10x my salary upstream of me in the org chart are being paid that presumably because they have such greater wisdom and foresight than I do. If I'm the CTO or have very significant equity, maybe I'll talk about restarting hiring of juniors. Otherwise I'll just sit and wait for the desperate consulting offers. It'll be like the COBOL boom in the late 90s.

Note: That isn't my retirement plan, but it'll just be a fun source of extra money if I'm right.

Why on earth would I not let the "money people" dig their own grave? There's no downside for me and lots of upside.

That’s not my problem. My incentive is that I have an open req and my job depends on my ability to get projects done on time, on budget and meets requirements. Why would I use my budget to hire a junior dev? They do negative work. Why would I when especially with remote work, I can hire a mid level developer or “senior” [sic] developer who lives in MiddleOfNowhere Nebraska who is willing to work cheaply?

Even before remote work, you could easily pull a mid level developer with 3-5 years of experience who is probably underpaid for only 20% more than a junior dev.

I will be living in Costa Rica somewhere retired by the time that is an industry problem best case or be able to command a higher salary best case.

Ya, we tried an offshore agency first for QA and didn’t work for us.

Then we explored AI tools and recently we adopted BotGauge. Does a pretty good job in terms of regression suite and much better decision than offshore low quality teams

If it makes money, the problem is solved. At least from the perspective of the people with the money.

Less cynically, it doesn't matter whether some code was written by a human or an LLM -- it still has to be tested and accepted. That responsibility ultimately must end up on a human's desk.

[deleted]
[deleted]

I would argue that "augmented programming" (as the article terms it) both is and isn't analogous to the other things you mentioned.

"Augmented programming" can be used to refer to a fully-general-purpose tool that one always programs with/through, akin in its ubiquity to the choice to use an IDE or a high-level language. And in that sense, I think your analogies make sense.

But "augmented programming" can also be used to refer to use of LLMs under constrained problem domains, where the problem already can be 100% solved with current technology. Your analogies fall apart here.

A better analogy that covers both of these cases, might be something like grid-scale power storage. We don't have any fully-general grid-scale power storage technologies that we could e.g. stick in front of every individual windmill or solar farm, regardless of context. But we do have domain-constrained grid-scale power storage technologies that work today to buffer power in specific contexts. Pumped hydroelectric storage is slow and huge and only really reasonable in terms of CapEx in places you're free to convert an existing hilltop into a reservoir, but provides tons of capacity where it can be deployed; battery-storage power stations are far too high-OpEx to scale to meet full grid needs, but work great for demand smoothing to loosen the design ramp-rate tolerances for upstream power stations built after the battery-storage station is in place; etc. Each thing has trade-offs that make it inapplicable to general use, but perfect for certain uses.

I would argue that "augmented programming" is in exactly that position: not something you expect to be using 100% of the time you're programming; but something where there are already very specific problems that are constrained-enough that we can design agentive systems that have been empirically observed to solve those problems 100% of the time.

We're 90%... we're almost half way there!

It costs 10% to get 90% of the way there. Nobody ever wants to spend the remaking 90% to get us all the way there.

I think parent was making an (apt) reference to Old School RuneScape, where level 92 represent half of the total XP needed to reach the max level of 99.

I had to double take on that one before I got it lol

Exactly this.

100%; Exactly as you've pointed out, some technologies - or their "last" milestones - might never arrive or could be way further into the future than people initially anticipated.

There are no technical hurdles remaining with respect to nuclear waste disposal. The only obstacle is social opposition

> There are no technical hurdles remaining with respect to nuclear waste disposal.

That is very inaccurate. There are still a million problems to solve. nuclear waste is extremely dangerous. Even "normal" trash has been proven dangerous and difficult to get rid of with landfills leaking dangerous materials into ground water.

Accumulating nuclear waste for millennia hopping that nothing goes wrong is far from a proven solution. People cannot trust a solution when all concerns for people safety are disregarded.

..and regulation. The same with supersonic.

I'm already not going back to the way things were before LLMs. This is fortunately not a technology where you have to go all-in. Having it generate tests and classes, solve painful typing errors and help me brainstorm interfaces is already life-changing.

I am in a similar place, I think, to you. Caveat: I don't spend a lot of my day-to-day coding anyway, so that helps, but I've never even tried Cursor or Windsurf. I just poke copilot to write whole functions, or ask ChatGPT for things that seem like they'd be tedious or error-prone for me. Then I spend 3-5 minutes tying those things together and test. It saves about 80% of the time, but I still end up knowing exactly how the code works because I wrote most of the function signatures and reviewed all the code.

I know in the very right circumstances the "all-in" way could be faster, but it's already significant that I can do 5x as many coding tasks or do one in a fifth the time. Even if it never ever improves at all.

LLMs are noisy channels. There's some P(correct|context). You can increase the reliability of noisy channels to an arbitrary epsilon using codes. The simplest example of this in action is the majority decoding logic, which maps 1:1 to parallel LLM implementation and solution debate among parallel implementers. You can implement more advanced codes but it requires being able to decompose structured LLM output and have some sort of correctness oracle in most cases.