| ▲ | jvanderbot 9 hours ago | |||||||
The thought experiment I like to have is imagining my company running without engineers and just LLMs. The thought of my CEO or sales guys sitting down and reading/redirecting LLMs all day is just hilarious. My CEO is highly technical but he has other shit to do. The first thing they'd do is hire someone to do that for them, and the best person for that task is someone who knows how things _should_ be. Now they'll probably get someone on discount, because our salaries are going to tank due to evaporating demand, but I sincerely doubt it'll be zero-d demand. What I expect is a 3D printer moment - tons and tons of homebrew / shareware style software coming out, an explosion of boutique code. I also expect a CNC machine moment - vastly reduced demand for hands-on specialists, and more babysitting of automted processes. But it's those machinists who got those jobs. We could be looking at a long term suppression (~80% reduction?) in demand though until economic growth produces enough demand to employ ~50M software engineers again, if ever. The cliff is unlikely, I'd guess the unregretted loss will be replaced by AI productivity every year, and some portion of growth will, too. I also guess that all the AI companies can become massively successful without causing much unemployment just by following Claude's model - charge a certain tangible % of a salary for assisting the worker. https://jodavaho.io/posts/ai-jobpocolypse.html | ||||||||
| ▲ | mikeocool 7 hours ago | parent [-] | |||||||
I am currently making a fair amount of my living helping out CEOs like this. The quick-sand that LLMs let non-engineers build overtime is pretty remarkable. A project usually starts with a list of basic looking cosmetic bugs that the stakeholder is having a hard time getting Claude to fix. Literally every bug unearths a heap of other bugs or architectural problems. As an example yesterday I was looking at a basic, “record XYZ not appearing on list view” bug. Turned out that Claude had built the list view (which should have been backed by thousands of records) to only ever load the first 100, and then do all organization, counts, sorting and filtering on the frontend on that dataset. Also found a query that was taking ~18 seconds to query 1 record from a set of ~60. | ||||||||
| ||||||||