[DanHulton]

> 99% of programming is repetitive plumbing

Even IF that were true (and I'd argue that it is NOT, and it's people who believe that and act that way who produce the tangled messes of spiderweb code that are utterly opaque to public searches and AI analysis -- the supposed "1%"), if even as low as 1% of the code I interacted with was the kind of code that required really deep thought and analysis, it could easily balloon to take up as much time as the other "99%".

Oh, and Ned Ludd was right, by the way. Weavers WERE replaced by the powered loom. It is in the interest of capital to replace you if they are able to, not to complement you, and furthermore, the teeth of capital have gotten sharper over time, and its appetite more voracious.

[sitkack]

Capital is also willing to have vastly lower quality and burden the remaining labor with more toil in exchange for even lower costs. Velocity will rise, quality will fall, toil will increase leading to more burnout but there will be more expendable bodies to cycle through the slop cleanup farm.

[thunky]

> Even IF that were true (and I'd argue that it is NOT)

Can you share what these "hard problems" are that > 1% of developers are working on?

[durumu]

Even if most of the code you write is solving repetitive plumbing tasks, today's models are incredibly bad at API design taste. IMO designing software in a way that minimizes side effects and is easy to change and test is more than 1% of software engineering.

Lately most of the code I write has been through LLMs and I find them an enormous productivity booster overall, but despite the benchmarks they're not expert human level quite yet, and they need a LOT of coaxing to produce production quality code.

As far as things LLMs are bad at, I think it's mainly the long tail. I'm not sure there's one singular thing that >1% of programmers work on that LLMs suck at, but I think there are thousands of different weird sub-specialties that almost no one is working on and very little public code exists for, thus LLMs are not good at them yet.

[h4ch1]

Try using any AI tool to write a working realtime GI (global illumination) implementation. I've been working on a novel implementation for 60fps/1080p GI and everytime I use Copilot or Claude to even try fixing a minor bug/troubleshoot it nukes entire functions and rewrites them using garbled shader code, old syntax/methods.

Puts things into stark perspective for me.

PS. no amount of prompt engineering will save you in this endeavour.

[thunky]

> I've been working on a novel implementation for 60fps/1080p GI

I don't think this is the type of work a "normal" developer is working on though, which is what my question was targeting.

I would think 99%+ are going to use an existing implementation like unreal engine, which AI can certainly help with.