Before LLMs came, there used to be the technical debt to deal with in a project, now there is also the added cognitive debt which is way more subtle and impactful long-term. If your source of truth isn't source code but a prompt (or even a series of prompts with branches) and the executor of prompts is a non-deterministic agent, I think you've already lost the battle there.

This is cope. There are multiple open models that are already good enough and cheap enough at API rates to sustain this.

Two years ago, SOTA was gpt-o1, and it was much more expensive than Fable. Now, for $4,699, you can easily run a much smarter Qwen3.6-35B locally with DGX Spark.

Think about where we are. This is an era where a new SOTA arrives every two months. It took LLMs only about 18 months to go from chain-of-thought reasoning to disproving the unit-distance conjecture. chatGPT itself is only three and a half years old.

DeepSeek V4, released two months ago, is almost as cheap as the electricity costed, has the ability to being absolutely a top-tier model in 2025 standards.

... by default.

You're standing on the shore, and your clients are having fun in the water. The tide is going up, and you're screaming at your clients "come back! it's not safe". And so, they show you the face. You appear to them like the boring guy who's not fun to hang out with. Eventually the tide is high, there is strong current, and they are being swept away further and further from the shore and they are panicking : "pyeri! help us! please!"

People (the non tech people, the MBA people) don't want to hear what you, the tech guy has to say. You're the not fun guy. Stay in touch until they do need you and say : you were right. That's the day you charge them a dear price for the service.

AI is still at the bait stage of rollout. They subsidize it, they want you to get hooked onto it to the point where you cannot do without it. Then only, they start to charge. I used google code assist for around 9 months. It was free. I would ask it questions from time to time, to help to fix bugs, and to avoid to spend an hour browsing SO. Now, it's around $30 per month. They are losing too much too fast atm, they have reached the stage where they have to start to charge. Another one of their strategies is : IPO. Once they (openai/anthropic) are listed on the nasdaq, you will pay whether you want it or not (via your exposure to the nasdaq/S&p500 with your etfs).

That assumes OP will still be in business if that day even happens. Odds are that cheap AI access will be around for longer than freelancers can remain solvent.

This, to me, is the biggest differentiator. In terms of results, there's a huge yawning chasm between the person who says "Claude make me a $thing" versus the person who puts in the effort to lay down the overall architecture, gives some thoughts to libraries and dependencies, performance trade-offs etc, and only then begins prompting.

Knowing how to implement Djikstra or a linked list by heart is no longer important. Actual software engineering skills are more important than ever.

This was never important. The important part was always knowing when to use them.

Two things can be true simultaneously. I think there was a time when deep familiarity with implementing algorithms was important.

I only ever bothered remembering enough of any algorithm to know my options and a few rules of thumb. If I ever actually need to consider the details of the algorithm, I certainly need to spend a lot more time thinking through the problem and its solution. Knowing a specific algorithm well enough to pump out in 15 minutes is a party trick that is as useful as being able to change a tire in 3 minutes flat. A great time saver that will be functionally useful maybe 3 times in your life...

Unfortunately despite being impressive for solo stuff, such results don’t scale to software you’d give to others.

It definitely can scale.

So we're not actually much faster at the core code, because reviews still take time. Ultimately, we're on the finance markets and we have regulatory pressures and I, as the human, am responsible for putting the code out there.

But we're freeing up a lot of time to get other things correct. We have n x more metrics now because plumbing in basic stuff is now trivial. We now have dozens more tools and skills to help analyse issues (e.g. why this price and not x), answer questions, etc.

I now have skills to scrape logs, download unpack and scape our bus persistence, link to kdb, and so on, all in my claude prompt, joining it all together and the AI is figuring things out. I can diagnose things, I don't know, maybe 100 times faster?

It is revolutionary, and I am highly sceptical of the motivations of people who keep saying otherwise.

I don't disagree that it's revolutionary in many ways, but I am seeing lots of companies make very costly mistakes by relying too heavily on AI without fully understanding the code it writes and without fact checking its outputs by a human.

My hunch however is that in a few years we're not going to be reviewing as heavily as we improve guardrails and can trust the AI code and review cycle more. I'm not sure what to expect for my career at that point.

Now we have machines that, when asked to produce a paperclip, may instead produce a butter knife, or a banana, or maybe just a "try again later".

These modern "tools" are quite a different animal. They're more akin to roulette wheels that generate massive amounts of heat and CO2.

This works, until it doesn’t. I’m continuously shocked by these stories, where so many people put the future of their job/company in the hands of these agents after only a few months of existing.

I still constantly run into bad output from LLMs, from code to basic questions. I don’t understand how anyone can hand things over to something that is laughably wrong on a pretty regular basis, often in subtle ways that won’t be noticed by someone who isn’t reading closely and thinking critically.

They’ve gotten better, but I still regularly give them the old Nick Burns treatment, push it out of the way, and do it myself.

I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.

I remember seeing this maybe 6+ months ago, but using paid plans, RAG, and a high thinking mode has eliminated a ton (almost all) of those kinds of hallucinations. Open models and free tiers are not there yet though.

> I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.

LLMs don't co-sign the quality of PRs though — your coworkers do. It's not unusual for docs to get oudated and not be maintained enough in small codebases, but that's not an LLM specific problem.

To the extent that it gets fixed or works at all, it's not because of competent developers doing rigorous analysis of the software, it's because either someone testing it or using it gets annoyed, reports an issue, and then that specific issue gets patched out.

If using LLMs to perform a similar function shocks you, then you should have been shocked already by the proliferation of pretty bad software for the better part of the last couple of decades.

So many criticisms of LLMs assume that people have been writing software very diligently, applying a high standard of engineering, subjecting the code to a battery of rigorous tests, passing it through a strict review process... and that does happen for some software, especially software that is commonly used, but it's not true for the vast majority of software developed.

I think for small tools that people want to make for themselves, that’s great. Where I see a problems are when other people and money get involved. If something goes wrong, who is accountable? Claude wrote it, Claude reviewed it, Claude submitted the PR… yet Claude can’t have any real accountability.

Therefore a computer must never make a management decision"

-- Internal IBM training manual, 1979

There is just such a tremendous amount of waste at every company, in that the headcount and software expands to fill the budget. I’m not defending Elon, but look at how much he slashed from X (80% or so?) and the company still has its core product functioning and an active user base.

There is a ton of software (especially internal) at essentially every company that also is low accountability before Claude. “Oh Ted built that but he’s working on a new important project. I understand it’s broken and that’s impacting you but we won’t be able to prioritize this until next quarter at least. Can you set up a meeting next month to discuss?”

Honestly the outcome for all of these LLMs is indeed is likely a higher amount of software with no accountability, but it’s also an improved ability to juggle more of that software to the same (realistically low) standard.

I'm still amazed people don't achieve extremely high test quality, since you get tests "for free" now.

One of the limitations of testing were always that people "design" things so they're hard to test.

And then they argue "This can't be tested", or "Refactoring this for testing is not worth it."

It is now. Yet, I work on codebases with no tests and lots of yolo co-authoring.

Yes, I’ve experienced that those tests succeed, and the app still breaks trivially on first run.

What I mean is: you design the tests. You analyse patterns. You insist on making testable code (average code by humans isn’t, so neither is average code by LLMs unless you specify testability as a design constraint.

One way to get testable code is to mock all interfaces. This is usually expensive, but not difficult for an AI, because you can set the success criterion to be interface exactness of your mock for a series of plausible and somewhat extensive interactions.

The tests you can make with AI are as good as you can make them otherwise, you just save time doing them, which should justify making more extensive testing.

LLMs just made it more convenient for the same people to take the lazy route.

You'd be shocked how often I see the meat-space equivalent of vibe coding!

"I trust the developers."

"You really shouldn't!"

The thing to realise is that there is no fundamental difference between outsourcing a development task to other human developers versus outsourcing[1] it to LLMs.

Either way, total and complete understanding is being sacrificed in the name of productivity and scalability.

It's just there's one extra layer of work assignment now, with ICs handing off tasks to agents.

What this has revealed to ICs is the BIG issue that has plagued all software development for decades, especially since outsourcing became so popular: Oversight is critical, and more importantly: authority can be delegated, but responsibility cannot.

LLM output is fine, as long as you review everything it does.

This is the same as any competent dev team manager reviewing PRs for quality, paying attention to critical matters such as security, adherence to high level design and low-level style standards, etc.

Some do.

Many never did.

[1] This doesn't have to be a contract with an overseas provider, by "outsourcing" I mean any variant of not-your-own-hands-on-keyboard. Any scenario where a customer or manager assigns tasks to developers other than themselves.

But it sounds like you're really asking about the state of the world today. If so, I don't think that ideal state is like your friend's company (or at least, as it appeared to be to you). It might be possible that you can make that "dark factory" pattern work (StrongDM seems to be doing it), but it would require infrastructure and discipline that I doubt they're mustering. Think about how CD didn't involve taking a sloppy build process with no testing or observability and just going straight to prod -- it required building up a lot of infra and discipline first.

But on the other hand, I don't think the ideal present involves artisan hand-crafting code either. I haven't written a line of code by hand in enough months that it would genuinely feel weird if I were to try to program that way despite decades of having done just that. That era's done with, and moderate normie practices right now today are more about supervising and guiding agents than about chiseling code into clay tablets.

Basically, in a decade or so, we'll be completely out of the loop in software development; even this title won't exist anymore (like the 2000's webmaster). We'll still be around, but with different roles.

I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.

I haven't worked at a startup in over a decade, but the stories I hear now sound the same as back then. There's lots of wasted effort for mediocre to poor code destined to be rewritten or thrown away until there's enough investment to justify more work. At which point, "more work" just means more sprawling slop instead of fixing the technical debt rotting at the foundation.

AI just put a spotlight on the futility of trying to run before you can walk. Whether so many founders are going to stay in denial about it is yet to be seen. Statistics about any line of business says yes. This is how most businesses fail and most of them have to fail.

Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.

Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]

0: https://www.simplethread.com/20-things-ive-learned-in-my-20-...

Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.

I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.

As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.

What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).

The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part.

If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved from dev to BA.

> Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load.

I've found that the act of physically writing refines my understanding a lot more than simply reading.

We don't typically expect a person to read a trigonometry textbook and then perform well on an exam. They have to drill problems to surface their misunderstandings to themselves.

My fear is that, with developers adopting your approach, they're "designing" systems in much the same way that a read-the-book-only trigonometry student solves trigonometry problems.

That’s the source of my “easy” framing. It has always had the lower cognitive load in my experience. Now that I can offload the mechanical part to AI, I spend more time on the hard parts.

I still read plenty of code along the way, maybe less of it now because it’s easier to surface which parts of the code I need to read.

They're called Business Analysts, sometimes simply Analysts, and that's effectively their job - come up with a spec and give it to the software engineers.

to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians

In my view, "programmer" merged with "analyst" to become "software engineer".

That's exactly why I don't have AI writing my code. It is doing the easiest part of the job (making symbols appear in the text), which isn't actually valuable to me. A good tool should help me to do hard things, not easy things.

This is why I don’t understand why folks around here (that are employed) feel so enthusiastic about AI. We are going to be working more in a rush to produce stuff that we won’t be feeling as proud of as we did before AI. Unless you were in the profession for the money, the delights of crafting software simply go away and AI is pushing us closer to be just… well, I don’t know, but I don’t like it. Sure thing, if you are a CEO, this new state of things must be wonderful

From my experience, a typical software engineer needs to understand the business (e.g., knowing who your users are), design a solution (e.g., we probably need an event-driven arch right here) and write the code (e.g., we should use select for update skip locked to avoid over claiming). They all are equally challenging imho

- Humans still own the code

- All code reviewed by humans

- LLM adoption varies across the org. Some are heavy users and some less. Some suspicious some less.

Where are we heading? Depends on model/harness capabilities. Likely some sort of mix where some projects will still require expert humans and others will just be vibe coded. How much we lean in that direction - we'll see.

i think that is a more important question that you shouldn't ignore.

do they have growing revenue?

> it's probably an issue with your usage of if

> I've rarely seen a repo and a problem that claude can't chew through with the right prompt

> a skill/PEBKAC issue

But then I remember how Anthropic couldn't fix the flickering issue for many months. It just does not compute.

Is it that people working at Anthropic can't prompt and it's a "skill issue" too? I mean, the terminal does not flicker in a lot of other complex TUI apps that I use every day - Midnight Commander, Emacs, tmux, etc. These are open source, Claude could be prompted to "just do what Midnight Commander does". So what is it?

> Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash.

Is a skill/PEBKAC issue. You still need to exercise engineering best-practices like decomposing work to the smallest unit before taking a task on, brainstorming design first and implementation last, clearly defining your success criteria and requirements before beginning any work, etc.

I'm on a >10yr old codebase and have been able to get my org to orchestrate entire features, fully unit tested, e2e tested, storybooked, from scratch without touching an IDE. Refactorings and the endless mountain of 80% completed migrations from one pattern to another are now trivially able to offload.

Point your SOTA de jeur at the original docs, a few of the original examples/PRs and have it draft a skill describing the work, the scope, and the success metrics. Iterate on the skill with the main agent by subagenting to test the skill until you are happy with the result and it mostly gets it right with the guardrails you've defined. Again - keep the scope extremely small. It gives much less rope for the agents to hang themselves with and it is less cognitive load when you have to review/test the PR.

Then set up a reasonable cadence for it to execute an autonomous thread on and review when you get comfortable.

----

The issue I've been running into lately is simply that we've got so many PRs coming in that actually doing thorough human reviews on them is not sustainable relative to the rate the team is creating agents to open them and people (especially juniors and mid level) are getting burned out by essentially having entire days where they are just doing code reviews.

For the current state of frontier models, you need to break the steps down so that the LLM understands a process like what you might go through as you expect it (which is often different for everyone).

i.e., get it to agree to a spec, then get it to agree to a build plan, agree on unit test signatures, UI etc as needed, then let it build, ...

"Prompt engineering"

I can take all of those steps, turn them into separate skills, then give them to a product manager or business analyst who makes half your salary, but has far more knowledge about the customers needs than you do.

Why does that require an engineer? I think a business analyst or product manager could do that just fine.

The business analyst use to hand off details to another person who would define detail technical specs like database fields names, type and size. Then the programmer would implement it.

It’s really not. Opus 4.8 can’t produce good software design and it still makes straightforward implementation mistakes. Two errors it made in one day for me recently: it built the Cookie class I asked for without a name field—cookies have a name and a value—and it neglected to handle a case where a database could have multiple rows with the same id, just returning whatever came back first.

The “best human programmers” absolutely would not have made those mistakes. At worst, they would have asked if I really meant what they thought I meant.

The statement was that AI is as good as the “best human programmer” and it’s quite obvious that it’s not. It makes inhuman mistakes on a regular basis because it’s not using human thinking. Blaming those mistakes on poor management is just sweeping the problems under the rug.

I don’t know the best way to work with AI, but I do know that we’ll only discover the best way if we’re honest about its capabilities. That includes not pretending it’s as good as the best human programmers.

My experience shows that AI can program like the best programmers; its code is very good when given precise instructions, just like a human. I've encountered problems elsewhere, such as anti-patterns in unwired modules, which are "large-scale" implementation errors. I'm resolving these thanks to an open source tool I'm building for AI cognitive governance, and it's yielded excellent results for me. The code produced at both small and large scales is high quality.

In my experience, people experiencing gross AI errors are doing so because they aren't giving it precise instructions. And by precise instructions, I don't mean a highly refined prompt or "vibe-coding"; I'm talking about instructions thousands of lines long, just like the ones we create when developing with human teams.

If two people are using the same model, and one reports that the AI "neglected to handle a case where a database could have multiple rows with the same ID", while the other says they can develop a huge microservices system with multiple databases without any major issues, perhaps one of them isn't using the tool optimally, based on my experience.

For example, the project we were working on was to add support for reading a session cookie to a codebase that, up until now, had used a different kind of auth. Fairly straightforward, everybody knows what a session cookie is and how it works. In about 10 minutes, we decided on the big picture design elements (how it was going to fit into our existing system, what we needed to add/modify, etc.) and the corresponding tasks.

One of the things we wanted was an “UntrustedCookie” class to represent the cookie. It was meant to follow a pattern we had already established for other user-controlled input. Our HttpServerRequest object was going have a new getCookie() method that returned it.

This would have been about 30 min of work for a pair to implement, including tests. It’s pretty trivial. No further documentation is needed.

Anyway, I’m glad AI is working for you. My experience is that it often fails, and does so in ways that experienced humans don’t.

The interesting thing is what you mentioned, that "no further documentation is needed." In the industries I work in, it's mandatory (with or without AI, and it's been that way for many years) to have everything fully documented from the design process onward. For me, it hasn't been difficult to work this way with AI because I know and have practiced the discipline of documenting decisions for a long time. For my clients, it's an essential accountability requirement.

These documents now have a dual purpose because they now serve to manage cognitive discipline too, so that agents do a better job than they would with vibe coding. Because without that discipline, what you say is absolutely true: AI agents do a terrible job and only hinder the good workflows already adopted by professional teams.

https://www.reddit.com/r/technology/comments/1ueidyv/softwar...

> I had an interview where I was asked the obligatory “what’s your Al workflow” and I said I use it for searching documentation and writing small functions or boilerplate that are tedious. Then I was asked whether I use Cursor. I said no, and immediately was told that “I’d be a better programmer if I used Cursor”. I have 13 years of software engineering experience, and was talked down by an Al startup with no minimal viable prototype. Then I was told I did not have the experience for the role. I love this timeline so much

I don't think the future is massive data centers running at a staggering loss to generate questionable code.

The future is rethinking IDEs to have local models work in partnership with the developer to ease tedium and catch mistakes.

A model that maintains a visual, zoomable mind-map of the entire project, with two way binding. Code can be created visually or textually, same with data flows.

Project structure and architecture are presented in high-level ways, that can be easily altered and refactored with almost zero tedium.

I think we start using AI for what it's good for: pattern matching and transformation, and stop trying to make it reason and pretend like it's a human.

Once we, as an industry, figure this out we'll unlock a massive boost in quality and productivity, but it looks like there will be some painful times ahead before everyone realizes that the token extrusion machines are only increasing the total cost of ownership, and they are being used incorrectly when we try to outsource our thinking to them.

I think there's an enormous opportunity to build these tools right now, and that whoever nails it will win.

Especially with prototyping-style work, LLMs are clearly good enough for a ton of business-oriented proof-of-concepts, and that line of work is essentially dead. Unfortunately a lot of mid-tier art falls into this category as well, particularly because execs very clearly can't tell good art from bad (on a "customers like this" scale, with functionality being the judge, which is fairly objective. not a subjective "this is good art").

High-skill work is still necessary, but it's hard to tell if it's actually going to be more important (because skill is obviously still needed for actually-good results, and I honestly see no evidence that this will change with current tech) or less (primarily due to less demand, and it being significantly harder for non-skilled to judge skill when everyone can prototype something seemingly-impressive in a weekend). Some will very obviously continue to exist though.

Whether this means "high-skill people are going to be fine, stay the course" or "<10% of high-skill people will be fine, you had better be scrambling right now or looking for a new line of work" is... much less clear.

Sure, but a carpenter who is unable to use a screwdriver without hurting themselves is unlikely to produce robust furniture with a a powered driver.

It may seem hopeless as a programmer, but imo you'd be much better off reframing your situation re: the above sentence.

Among peers, I feel like I am top 20%? 30%? maybe, by being a good programmer who is adept at agents. A year ago was the 0.1% point, this stuff is spreading like wildfire. A year from now I think it's going to just be de rigeur that these are our tools now.

Worse, any edge I have from working with this stuff for years is quickly dulled. The tools are evolving fast. My tricks from 3 months ago have been eclipsed.

"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"

Is this the world you're excited to be living in?

in the olden days (pre-LLMs) we would write high-level code.

the entire layer was high-level code and rarely would we ever need to peak into the assembly:

writing, debugging, architecting, reviewing, testing - all were done in the high-level language layer.

---

welcome to present day:

since we don't write code - we write intents, we also shouldn't review code either - we should review intents.

I don't review my code anymore. I ask the agent to generate markdown docs, graphviz diagrams, changelogs, audit reports, etc. I only review that.

I also ask it to write test and evaluate by whether the tests passed or not. I don't need to peak into the tests code - I can also ask plain english, pseudocode, control flow graph, whatever it is I want.

I can ask it to find errors or missing tests and improve that too!

code is like assembly now.

rare are the cases you would need to peak into that level.

From an alternative perspective, that is the code.

Consider some software that was written by AI purely using markdown files. The spec was sufficient enough to classify all of the business logic, conditionals, etc... You might even end up creating "loops" that tell AI to do something over and over again. Some markdown files become standard, repeatable "functions" that are to be followed EXACTLY (determinism). Some markdown files become assertion tests. Heck, the markdown file might eventually invent some kind of "typing system" so that you know when you're working with the person "class", it's always going to have the same facets.

I love the concept of it going in this direction - we already had plenty of languages to tell a computer what to do, we've just generated MORE text at a higher level and made it less deterministic.

Just to clarify, I don't think it's likely that this is the end result, but it sure is funny to think about.

I'm in a slow-moving, much bigger company. Lot's of talk about "AI" here and we can use copilot if we want to, but there is 0 pressure. I'm in a small team and one colleague uses copilot often. In the beginning there was a minor conflict between him and me, because I found the quality of the LLM code unacceptable and had to ask him to review it more carefully. I think that's settled now, but it makes me sad how a once motivated colleague now seems to try to cheat his way out of work.

I personally find it incredibly boring to write copilot prompts or read its answers full of boiler plate and sycophancy. I don't understand how anyone would want to replace the cognitive work of programming, that I find enjoyable for the most part, with the cognitive work of "talking" to an LLM.

Anyway, I think it will be like this at least for a little while longer: only vibe coding allowed in small companies and less vibe coding the bigger the company is.

But before vibe coding can take over the slow-moving big companies, all the accumulated technical debt will come back to haunt us and vibe-free software will be the new fad. That's what I hope at least.

One possibility is that software starts to look more like traditional manufacturing.

The machine is the company’s core asset. The engineer only needs to know how to operate the machine well. Once that happens, the barrier gets much lower, need much less people, and the job naturally become much less valuable. Some parts will still need to be done by hand, of course. But only a very small part. It is like old factories. They used to need lots of fitters, at all levels of skill. Now you only need a few of the elite ones.

AI is the CNC machine of the software industry.

The more pessimistic future is that, maybe five years from now, the best programmers will look at AI the same way the best Go or chess players look at AI today: Like KeJie said, "I don't even know what I am trying so hard against." We now have a new SOTA every two months. It just took 18 months for LLMs from reasoning models to disproving the unit distance conjecture. ChatGPT itself has not even existed for as long as a college student spends in university.

In any case, we have already passed the point where this can be rolled back.

Maybe ten years from now I will be leaving a comment saying that "programmer" used to be a job too :-/

Programming is the low-hanging fruit for AI. Open source and knowledge sharing have given it huge amount of public, high-quality training data at a level other industries can hardly imagine. And almost everything in programming can be tested and verified inside the computer quickly in a closed loop. No robot arm is needed.

The main weakness of current LLMs is still that they are static: They do not really change themselves through use. Harness tools are just elaborate ornamentation on top of prompts. LLMs are frozen at the moment training stops. Once we get models that can change their own weights through self-feedback, then maybe AGI really is on the horizon.

Thinking optimistically: I may be lucky enough to see it in my lifetime. Maybe by then, people will be able to live more like human beings, instead of organizing their whole lives around work :-)

Your analogon is a bit leaky abstraction in the sense that it misses out on the broad stastical nature of LLMs. However, I find it is a good way to illustrate the potential industrial transformation.

It is hard to say what the future will bring. The original AsK HN post is definitly an omen for things to come.

I'm not sure the comparison works if individuals can afford these machines themselves and don't have to commute to a factory to use them; I doubt employers will serve as either gatekeepers or sole providers of access to AI.