There are also those for whom that percentage is higher, let’s say 6-50%.

> I understand things and then apply my ability to formulate solutions

The AI is coming for that too.

You might just be lucky to be in circumstances that value your contributions or an industry or domain that isn’t well represented in the training data, or problem spaces too complex for AI. Not everyone is, not even the majority of devs.

People knocking out Jira tickets and writing CRUD webapps will end up with their livelihood often taken away. Or bosses will just expect more output for same/less pay, with them having to use AI to keep up.

> The AI is coming for that too.

In that case all [1] non manual work is doomed, until robotics has an LLM moment.

[1] With the exception of all fields protected by politics or nepotism.

All work in general. Knowledge workers can still do manual work, and will compete to do so when there is no option to continue what they do today.

However, even out of that 80% of my time, what fraction is actually spent "writing code"?

AI can be an enormous accelerator for the time I'd normally spend writing lines of code by hand, but it doesn't really help with the rest of the work:

- Understanding the problem - Waiting for the build system and tests to run - Manually testing the app to make sure it behaves as I'd like - Reviewing the diff to make sure it's clear - Uploading the PR and writing a description - Responding to reviewer feedback

There are times when AI can do the "write the code" portion 10x faster than I could, but if it's production code that actually matters, by the time I actually review the code, I doubt it's more than 2x.

- Understanding the problem - Waiting for the build system and tests to run - Manually testing the app to make sure it behaves as I'd like - Reviewing the diff to make sure it's clear - Uploading the PR and writing a description - Responding to reviewer feedback

What part of those you think it doesn't help with?

Consider hash tables. Nobody implements a hash table by hand any more. I've written some, but not in this century. Optimal hash table design is a specialist subject. Do you know about robin hood algorithms? Changing the random number generator's seed to discourage collision attacks? A basic hash table starts to slow down around 70% full. Modern hash tables can get above 90% full before they have to expand.

Who keeps Knuth's Fundamental Algorithms handy any more? I own both the original edition and the revised edition. They're boxed up in the garage. I once read that book cover to cover. That was a long time ago.

That's not AI. That's solving the problem and putting it in a black box. That's how technology progresses.

And that's what people use AI everyday to help with, so?

The key word is solving. Meaning someone, after coming up with the solution, has taken times to prove that it works well in all usual and most extreme cases. With their reputation on the line.

That’s why you trust curl, ffmpeg, Knuth’s books,… but you don’t trust random cat on the internet. We don’t trust AI and the cost to review its output is not a great tradeoffs compared to just think and solve the problem.

To some degree yes, in practice, not so much. In practice you have to be in the world, talk to people, know how to talk to people, know how to listen, and be able to understand the difference between what people say and what they actually need. Not want. Need.

This was something I learnt in my very first job in the 1980s. I worked for someone who did industrial automation beyond PLCs and suchlike. He spent 6 months working in the company. On the factory floor, in the logistics department, in procurement, in accounting and even shadowing the board. Then he delivered a proposal for how to restructure the parts of the company, change manufacturing processes, and show how logistics and procurement could be optimized if you saw them as two parts in a bigger dance.

He redesigned the company so that it could a) be automated, and b) leverage automation to increase the efficiency of several parts of the business. THEN, he started planning how to write the software (this was the 80s after all), and then we started implementing it.

Now think about what went into this. For instance we changed a lot of what happened on the factory floor. Because my boss had actually worked it. So he knew what pain points existed. Pain points even the factory workers didn't know how to address because they didn't know that they could be addressed.

I was naive. I thought this was how everyone approached "software projects". People generally don't. But it did teach me that the job isn't writing code. It is reasoning about complex systems that often are not even known to those who are parts of it.

And this is for _boring_ software that requires very little creativity and mostly zero novelty. Now imagine how you do novel things.

> People knocking out Jira tickets and writing CRUD webapps will end up with their livelihood often taken away. Or bosses will just expect more output for same/less pay, with them having to use AI to keep up.

You make it sound like it is a bad thing that certain tasks become easier.

I spent a lot of time writing CRUD stuff. Because the things i really want to work on depend on them. I don't enjoy what is essentially boilerplate. Who does? If you can do the same job in 1/20 the time, then how is this a bad thing?

It is only a bad thing if writing CRUD webapps is the limit of your ability. We don't argue for banning excavators because it puts people with shovels out of work. We find more meaningful things for them to do and become more productive. New classes of work becomes low-skilled jobs.

If you have been doing software for a while, you are probably doing some subset of this. But these things are hard to articulate. It is hard to articulate because it is not something we think about. Like walking: easy for us to do, hard to program a robot to do it.

1 person needs to do that. The other 100 not doing that currently to begin with, but doing the AI-automatable work?

We used to say that (not long ago, even) about the code-writing part. Why do we believe that LLMs are going to stop there? Why do we think they won't soon be able to talk to people, listen, and determine what they need? I think it's mostly a cope.

We have robots walking just fine now, by the way.

Imagine 45% of higher than average paying jobs gone.

If that happens we’ll either figure out a new economic system, or society will collapse.

Also saying robots are walking just fine is misleading for any definition of just fine that is anywhere near as good as a human.

As harsh it may sound, it seems rather likely to me. It is not like s/w engineers have helped struggling workers in other sectors other than sanctimonious "Learn to code" advice. So software folks can't expect any solidarity or help from others.

It should be something for us to celebrate, because it means greater freedom for humans to pursue something else rather than spending time doing drudgery.

Or they're planning to build an Elysium-like colony in the ocean or space, to keep the billionaire class far from danger.

More likely they figure out what to do with a bunch of idle talent. Or the coming generation of trillionaires will.

"Automating half the jobs" is the same as "double productivity per worker".

When the doubling happens in 5 years rather than 50, it might be more disruptive, but I'm convinced we're on the verge of huge improvements in human standard of living!

If we double productivity per worker, we have twice as much wealth on average.

I know there are angry people convinced that this will all be consumed by billionaires and jews, but historically that is not at all the track record of the last 250 years, and I expect that to continue.

That's not true. There are other factors at play such as demand.

If we make the average IT worker twice as productive, that doesn't mean now every IT worker is being paid twice as much, because most users aren't going to care if there are twice as many options on the app store, or twice as many bug fixes per release.

There are differences due to import/export balance, investments, government borrowing etc, but as a first approximation, if GDP increases by 10%, consumption will rise by a similar amount.

About your IT worker example: Let's say s/he produces $150k/year in value and is paid $140k. If AI makes them produce $300k of value, they may not automatically get a raise. But it becomes very attractive for another employer to hire them for $200k or $250k, or even $280k.

In the medium/long term, I don't see why wages would keep proportional to produced value.

The fact that oligarchy now has more resources than ever in the history of humankind, a means to mass surveillance and generating mass propaganda, those wealth redistributions are looking much MUCH harder to accomplish.

Yea, historically it will inevitably happen. Realistically it will be after the new version of fuedalism and dark ages. So strap in for the next 400 years aren’t looking too good

Heck, even long before LLMs about 10% to 30% of my code was already automatically generated. By tooling, by IDLs and by my editor just being able to infer what my most likely input would be.

> We have robots walking just fine now, by the way.

I don't think you got the point I was trying to make.

Because they are currently "generative AI" meaning... autocomplete. They generate stuff but fall down at thinking and problem solving. There is talk of "reasoning models" but I think that's just clever meta-programming with LLMs. I can't say AI won't take that next step, but I think it will take another breakthrough on the order of transformers or attention. Companies are currently too busy exploiting the local maxima of LLMs.

I get the feeling we can already spot the next AI Winter. Which is okay, we need a breather, and the current technology is useful enough on its own.

Why do you believe they wont? I think it's reasonable to assume that we will hit a ceiling that current models will not be able to break.

> We have robots walking just fine now, by the way.

Walking and reasoning are unrelated abilities.

What evidence is there that LLMs have hit a ceiling at being able to do things like talk to users or stakeholders to elicit requirements? Using LLMs to help with design and architecture decisions is already a pretty common example that people give.

Current AI tech giants prove over and over and over again that this is not the case

I am very optimistic. I just wish I was younger to take advantage like Junior high, high school age with my current resources damn… The oldest lament in the books.

I've been told for three years that it's the early days, and everything completely changes every few months, and these are the worst the tools will ever be. Meanwhile, I see very little technical progress, zero return on investment anywhere, negative infinity profitability on the side of the providers, and a fast growing realisation among the masses on all the myriad tasks they are systemically unsuitable for.

There are people and companies out there releasing entire vibe coded projects and for some upwards of 80% of the code they develop is AI-assisted/generated. Since around the end of 2025 and models like Opus 4.6, the SOTA has gotten good enough to work agentically on all sorts of dev tasks with pretty good degrees of success (harnesses and how you use them still matters, ofc).

And how much revenue do they generate?

Long term its bleak, but short/medium term - not so much, if I get fired it won't be llm replacing me but rather company politics, budget changes etc. Which was the only real (very real) risk for past 15 years too, consistently. But it helps to not work for US company.

I still have a job so AI hasn't taken that yet. But the suggestion it's "no closer" is ridiculous. At least in my life/career/office this last 12 months seems to have been a real inflection point in how AI is being used for software development.

5+ years in the software world is like 30 years in others...So...given lacking use-cases and humongous amounts of capital already wasted on chatbots...It's more like "we" are closer to closing curtains than to "just started"...

This is definitely an agent problem instead of an LLM problem. Anybody got something explorative like this working?

That may be true I’m not gonna say one way or the other, but if AI comes for that then almost all knowledge work is effectively dead, so all that’s left would be sales or physical labor.

Developer community: Wow, we truly have become obsolete now!

My bet is something _like_ assembly, but not assembly.

That being said, I think humans will still program for fun. Just like we paint portraiture in a world with cameras.

I expect that to continue.

(And in all of those transitions millions where left behind without work or with very worse prospects. The people that took the new jobs were often a different group, not people who knew the old jobs and were already in their 30s and 40s).

And what would be the new professions that uniquely require humans, when even thinking and creative jobs are eaten by AI? Would there be a boom of demand for dancers and chefs, especially as millions lose their service jobs?

Even if this still holds true ("past performance is no guarantee of future results") the part about it that people handwave away without thinking about or addressing is how awful the transitional period can be.

The industrial revolution worked out well for the human labor force in the long term, but there were multiple generations of people who suffered through a horrendous transition (one that was only alleviated by the rise of a strong labor movement that may not be replicable in the age of AI, given how it is likely to shift the leverage of labor vs. capital).

If you want to lean on history as an indication that massive sudden productivity changes will make things better for humanity in the long run, then fine, but then you have to acknowledge that (based on that same history) the transition could still be absolutely chaotic and awful for the lifespan of anyone who is currently alive.

My parents say a lot of stuff like this. They tend to gloss over the untold suffering, great depressions and world wars that took us to get here.

The planets resources were also not in risk of running out. As the world is min maxed by billionaires, it nice the lower classes are drained of all capital, they will soon move to fighting each other for resources. the future is looking pretty grim for even the most optimistic of scenarios

spot on. you gotta wear shades to survive, future so bright.

Are you going to have the time and money in 2035 to spend 5 years retraining though? Will you be as cheap and fast as the young ones that will learn with you and ask for half your salary?

New professions will likely come no doubt. Whether existing professionals will be able to transition to those easily is another matter.

The AI is coming for those too.

One very tiny slice of speciality/ rare industries where code is critical but overall small part of project costs. I can see if code / software is 5% of overall cost even heavy use of AI for code part is not moving the needle. So people in this group can feel confident in their indispensability.

Second group is much larger and peddling CRUD / JS Frontends and other copy/paste junk. But as per industry classification they are just part of same Coder/Developer/IT Engineer group. And their bleak prospects is not some future scenario, it is playing out right now with tons of them getting laid off. And whole lot of people with IT degrees, certifications are not finding any jobs in this field.

So far it appears that LLMs still require constant hand-holding, even for a small educational CRUD app.

I don't mean this as a snarky jab. It's coming for anything software. I've used AI to accomplish front end development and reverse engineer proprietary USB hardware dongles in C, then rewriting the C into Rust to get easy desktop GUIs around it. Backend APIs, systems programming, embedded programming, they all seem equally threatened it's just a matter of time. Front end is easy to see in the AI web front ends but everything else is still easy pickings.

That is not hard. It’s just tedious and very slow to do manually. The hard part would be about designing a usb dongle and ensuring that the associated software has good UX. The reason you don’t see kernel devs REing devices is not because it’s impossible or that it requires expert knowledge. It’s because it’s like counting sands on the beach.

You may also find re-ing stuff not tedious, due to what may be motivating you.

In any case, any work will have some things you just know how to do, or what to do, but previously (before LLM agents) no easy way to plow through them without pressing a lot of keyboard keys over long period of time.

I think it will be far fewer to have any positive impact on IT engineers' overall job prospects.

The thrust was overall job prospects for people in software field. It is not that frontend is easy but it is definitely easy to get into. Considering there are far more frontend developers then say C++ system engineers or database designers so in sheer numbers they will be affect more.

I am sure AI bros are same people who were convinced consumer grade fully automated driving was going happen "by end of the year" for last 7 years.

Is it a handy tool? Yep! I use it every day. But it is laughable to think this is the path to AGI. The most common counterargument on HN is some variation of "but you can't prove that this isn't just like how a human thinks". A conspiracy theory at best, just reinforcing the fact that we know very little about how even simple non-human brains function.

I am yet to see anyone saying it's just like human, so it looks like you are mostly hallucinating that too.

You didn't address my point on GPT-2 vs 5.5. Your only relevant claim is that 5.5 talks very pretty vs 2 just pretty I assume. Well, you have to be blind to claim this is the main difference.

That's where we fundamentally disagree about.

Yes, AI is coming for solution formulation, absolutely, but not all of it, because it is actually a statistical machine with context limit.

Until the day LLMs are not statistical machine with a context limit, this will hold. Someone need to make something that has intent and purpose, and evidently now not by adding another 10T to the LLM parameter count.

So are humans.

Machines have surpassed humans by magnitudes in many capabilities already (how many billion multiplications can you do per second?)

And I argue that current LLMs have surpassed many of my capabilities already.

For example GPT/Opus can understand and document some ancient legacy project I never saw before in minutes. I would take a week+ to do the same and my report would probably have more mistakes and oversights than the one generated by the LLM.

AI advocates are _way_ too confident about the nature human cognition. Questions that have been debated by philosophers and cognitive scientists for decades are now "obvious" according to you people, though you never provide any argument to support your statements.

We are much more limited, but we fundamentally work differently. Hence adding more parameter like certain companies are doing isn't necessarily going to help. We need to rethink how LLM work, or how it work in tandem with something that's completely different.

I think it's doable, I just don't believe it's LLM, and I don't think anyone now knows what it is.

But we are? That's our education system.

The only reason school doesn't try to shove more information in our brains is because we hit bandwidth limits.

That is not what the education system does. That's an obvious distortion of reality. People train over billions of documents to statistically predict the next word to gain and understanding of language. LLMs do this statistical processing in order to mimic humans natural language learning ability. And there has been continued evidence of the limitations of this approach to accurately mimic the totality of human cognition.

Do you have any idea how many calculations it takes for a human to put a ball through a hoop while running across a court?

It could be millions or billions in a second. Manifesting consciousness, coordinating body movements, and everything else all at the same time takes calculations.

You may not be aware that your brain is doing multiplication, or any other kinds of math, constantly, but it is.

https://www.youtube.com/watch?v=VVEzgYxDdrc

The human condition is nothing but a massive amount of calculations under the hood. You don't feel it, or understand it, but it's there. Everything in nature is math, every physical phenomena has a cause and effect rooted in mathematics, and it's no surprise that humans are great at subconsciously calculating myriad things on-the-fly, as life is happening around us.

And the human mind is not?

Is it similar, even if much simpler, of the sort of process that goes on there too? That's the important question.

> The AI is coming for that too.

If this is true, then you'd have to conclude that AI is coming for everything. I'm still not convinced by that. But I am convinced that the part of software development that involves typing code manually into an IDE all day is likely gone forever.

Now you’re getting it

So of 10% of lawyers get AI-d away, let’s say, the remaining 90% are 1.1x+ efficient and also up against other lawyers enjoying the same… work might go up. And on the customer side there is sooooo much BS with lawyers, but if both lawyer and customer can communicate faster or better with the LLMs, we should see more better cases with better dialog and case handling. Again, the total amount of lawyering could go up a lot. And then we have the cases prohibitive without the LLMs, now possible for big money. Better LLM empowered lawyers should be able to create new and more lawyer work.

As it stands I see people selling services that are subsidized by VC, template jobs we’d be doing faster with copy paste but it’s not copyright infringement when OpenAI does it, and a rush for valuations to soak up VC because the business model isn’t there. I’m seeing a huge uptick in visual bugs on large commercial platforms and customer facing apps, and don’t feel OpenAI is gonna kill Office anytime soon… or Chromium… or Steam… or emacs…

Call me an optimist, but I think those LLM pump and dumpers are creating a wave of fear that would be quite different if they weren’t lying and trying to boost an IPO. Chat GPT 2 was too dangerous to release, lul, and the class action suits are just getting started.

An actual lawyer replacing tech company should sell lawyering for infini-money, not pens that’ll totally 10x your lawyering (bro).

So.... they just starve in the streets?

Even if some other, arguably better job comes along, would they retrain for it? (You can say yes, but take a look at the long history of people choosing to join a cult and vote for an orange moron instead of learning a new skill).

Either you're convinced you won't be too badly affected and will gladly watch huge swaths of people suffer, or you're deluded enough to think that it will really, truly be different this time. In any case, I hope you get the worst results of what you preach.

I don't know if it makes sense to call that person an SWE, and some people currently employed as SWEs either won't be good at this or aren't interested in doing it. But the existing pool of SWEs is probably the largest concentration of people who'll end up doing this job, because it's the largest concentration of people who've thought a lot about, and developed taste with respect to, how software should work.

Anecdotal evidence to support this.

I work with both dev and design teams. Upper management has already gone through several layoffs and offshoring of the two dev teams I work with. The devs they did keep were exactly what you said. The capable ones who reliably closed their Jira tickets. Never missed a deadline for building their features or components. And now? Their work has tripled and now the only help they get from management? "Start to figure out how to leverage AI, we're going to be a in hiring freeze for the next 10 months."

The double whammy of losing onshore team members and not getting any help from management to fix the problem they just created and essentially just telling them to figure out how to use AI to keep up is pretty staggering.

I would echo what one of the devs told me, "If this is the new "AI era" than you can count me right the fuck out of it."

Yes, but if/when that happens, it won't just affect software engineers. An AI that can do that can replace any white collar worker.

> People knocking out Jira tickets and writing CRUD webapps will end up with their livelihood often taken away.

I'm not sure anyone is actually working on those. People talk about spending all day writing CRUD apps here, but if you suggest there are already low code tools to build those, they will promptly tell you it's too complex for that to work.

Yes. Yes, that's exactly what we're going to see, and more swiftly than people are generally comfortable with. What are we going to do with all those cubicle dwellers?

But beyond that, I don't think most people want a three day work week. They would rather work five days and get the extra money. I worked at a company that did government contracting. We had a couple quarters without much in the way of orders, so instead of laying people off like you'd normally see in that situation, the company decided to go to a four day week, with a commensurate cut in pay.

I was thrilled, as a young single guy, to get Fridays off. I rented a room in someone's house and hit my monthly nut in about two weeks. But most of the people I worked with hated it. Some of them quit. A lot of them both needed the money and also had no idea what to do with themselves on that extra day.

Only in tech I see people hating and not taking any pride in their work. Ask a lawyer or a doctor and they'll fight you to the death if you threaten their status. But here it is not only acceptable, but also for some reason encouraged to feel inferior. You're earning shitton of money? Well, you're just a lucky insect who taps on a keyboard while X does real job, about time AI has put you on the street. Disgusting. If some AI reckoning does come, I hope it will hit you first.

The first is that AI is achieving human-level expertise and capability, but since they're now being increasingly trained on their own output they are fighting an uphill battle against model collapse. In that case, perhaps AI is going to just sort of max out at "knowing everything" and maybe agentic coding is just another massive paradigm shift in a long line of technological paradigm shifts and the tooling has changed but total job market collapse is unlikely.

The other possibility is that we're going to continue to see escalating AI capability with regard to context, information retrieval, and most importantly "cognition" (whatever that means). Maybe we overcome the challenges of model collapse. Maybe we figure out better methodologies for training that don't end up just producing a chatbot version of Stack Overflow + Wikipedia + Reddit. Maybe we actually start seeing AI create and not just recreate.

If it's the latter, then I think engineers who think they are going to stay ahead of AI sound an awful lot like saddle makers who said "pffft, these new cars can only go 5 miles per hour."

I'll also add another factor: it's become increasingly clear at our company that AI-enabled humans are getting to the bottom of the backlog of feature ideas much quicker. This makes the 'good ideas' part of the business the rate limiting step. And those are definitely not increasing with AI, beyond that generated by the AI churn itself ("let's bolt on a chat experience or an MCP!")

So maybe the coding assistants don't get a 10x improvement any time soon, but we see engineering job market contraction because there aren't really enough good ideas to turn into code.

Simple marginal thinking: When you lower the price of something, it gets more use cases. A rich person might not take even more flights because they are cheaper, but more people will consider flying when they wouldn't have at old prices

LLMs know nothing but are great at giving the illusion that they know stuff. (It's "mansplaining as a service"; it is easier to give confident answers every time, even if they are wrong, than to program actual knowledge.) Even your first case seems wildly optimistic. The second case is a lot of "maybes" and "we don't know how but we might figure it out" that seems like a lot to bet an entire farm on, much less an entire industry of farms.

We sure are looking at a shift in the job market, but I don't think it is a fork in the road so much as a Slow/Yield sign. Companies are signalling they are willing to take promises/hope to cut labor costs whether or not the results are real. I don't think anything about current AI can kill the software development industry, but I sure do think it can do a lot to make it a lot more miserable, lower wages, and artificially reduce job demand. I don't think this has anything to do with the real capabilities of today's AI and everything to do with the perception is enough of an excuse and companies were always looking for that excuse. (Just as ageism has always existed. AI is also just a fresh excuse for companies to carry on aging out experience from their staff, especially people with long enough memories/well schooled enough memories to remember previous AI booms and busts.)

But also, yeah if some magic breakthrough makes this a real "buggy whip manufacturer moment" and not just an illusion of one, I don't mind being the engineer on that side of it. There's nothing wrong about lamenting the coming death of an industry that employs a lot of good people and tries to make good products. This is HN, you celebrate the failures, learn from them, and then you pivot or you try something new. If evidence tells me to pivot then I will pivot, I'm already debating trying something entirely new, but learning from the failures can also mean respecting "what went right?" and acknowledging how many people did a lot of good, hard work despite the outcome.

It has no "semantic understanding" as we would define it. It's just increasingly good at winning cluster lotteries because we've increased the amount of training data to incredible heights.

Grouping vectors in concept space is exactly how you create semantic understanding. The proof is in how good they are at creating semantically valid text. The fact that it took massive amounts of data is irrelevant. That just shows how much knowledge is encoded in all our language. It takes humans a ton of training to know things too.

We don't know that. It seems like great hubris to declare we know how the human brain works. You are asking me to explain how we know things and then telling me we've already figured it out in the same breath, and that's hilarious.

It doesn't take massive amounts of language data to train a baby human. It is almost entirely just: "Look. Here's a cat. Can you say cat? Cats go meow." "Over here, your aunt has a dog. Dogs go woof."

There's generally a flood of non-lingual contextual data in such moments such as sights, smells, sounds, movements, touch but that also only further underscores how different LLM training is from anything we'd consider human learning. Our memories aren't just "conceptual spaces of linguistic topics", they are complex sensory maps where a smell can remind you of the first dog you ever met. There is so much of our human knowledge that is not and never been encoded in most of our languages.

The fact that LLMs take massive amounts of linguistic data is relevant, because it shows how far we still have to go in barely scratching the surface of how the human brain seems to work. (Which again, we know only the barest details. Anyone who tells you they know 100% of how the human brain operates so far tends to be a snake oil salesman.)

"Neural Networks" are the Omegaverse of Computing and we are all poorer for it. I could elaborate, but I'm exhausted and depressed right now. The map is not the territory. The broken analogy is almost never the real thing. A stopped clock is right thousands of times per year if you just keep collecting as much data as you can.

I'd say they are quite adroit at using their knowledge.

I mean, is Mythos finding all these vulnerabilities not evidence enough? Does AI Studio not clearly understand React and use it artfully?

So they surely know a lot, but you are never sure if the info is correct or not.

But yes, it gets tricky.

I'm sure we'll reach AGI at some point, but looking at AI history, I don't see that coming any time soon.

It's ability to write code is alright. Sometimes it impresses me, sometimes it leaves me underwhelmed. It certainly can't be left to do things autonomously if you are responsible for its output.

Moderately useful tool, but hellishly expensive when not being subsidized by imbeciles that dream of it undrrmining labor. A fool and his money should be separated anyway.

What I am really concerned about the incoming economic disaster being brewed. I suspect things will get very ugly pretty soon.

Then you won’t have this just world of the deserving workers at all. Just formerly deserving workers and idiot billionaires like Musk (while the robots do all of the work).

Seeing him type really reinforced this idea.

If I gave them a task and they immediately started typing it out, I would tell them to stop typing and ask them to explain to me what they were doing; they'd often just spit out what they thought the code should do, and I'd often point out edge cases they missed and would have missed had they just spit out code and a PR, wasting everyone's time. I would also insulate them from upper management to give them time to actually think (e.g. I wouldn't be coding so they could think then code).

To your point and to the GP's point, and one point I keep raising with LLM's: "typing is not where my time sinks are"

The reason I just remembered that is that the other day they proudly announced that everyone in their company would now be vibe-coding exclusively.

Junior developers spend most of their time writing code (when they're not forced to attend pointless standups, because Agile/blah/blah)

> The developers who still think their job is about writing code will perhaps not have a job in the future.

So you're saying the same thing everyone else is saying. SWEs won't go away, but they will be greatly reduced, because those whose job is about writing code -- junior devs -- will be replaced.

(How will Sr Devs in the future be created? That's the question, isn't it.)

As an extreme example, maybe we’ll see long-running internships and trainings like doctors experience. Doctors don’t start their career until ~12+ years of prep and training.

Pragmatically, software development has a lot of examples of teenagers making apps and college students building software companies. In the 12 years it takes for training, low-knowledge workers could be vibe coding continuously replacements of most commercial software products they’d be hired to build. So I doubt we’ll treat software development as a rarified high skill job.

May I ask if you could estimate how you spend the other 95% of the time?

    - Meetings
    - Reading papers
    - Understanding legacy code
    - Reading internal news
    - Ad hoc chats with coworkers
    - Writing docs
    - Editing configs
    - Thinking about solutions
    - Slacking off
    - Analyzing results
    - Testing code
    - Reviewing PRs
    - Understanding others' ongoing projects

I just don't think you've utilized the most recent versions of codex or claude.

    > Slacking off

I never got that argument. Compilers are formally proven, deterministic algorithms . If you understand what compiler does, you can have pretty good idea what it will produce. If it doesn't do that, its a bug. Definition of correctness is well defined by semantic equivalence.

LLMs are none of that. Its a fuzzy system that approximates your intent and does its best. I can make my intent more and more specific to get closer to what I want, but given all that is just regular spoken language its still open to interpretation. And all that is still quite useful, but I don't get the assembly language comparison here.

Introduce dynamic compilation, profiling data, optimization passes, multiple implementations, ML driven heuristics, and getting deterministic Assembly output from a compiler starts to get harder to achieve.

I just don't think comparing with compilers is a good argument.

I did some contracting work for a severely dysfunctional meeting heavy organization and it was about 2 hours of meetings for every hour of real technical work!

But i guess if we mean actual time tapping your keyboard making code, then it's true some days for senior+ devs, but definitely not technical work overall.

And that would be where we disagree. I don’t read code to look at code. When I’m reading code, I’m looking for the contracts to follow when interacting with a system. It would be nice if it were documented, but more often than not you have to rely on code.

It’s very rare that I plan with a technical mindset. Yes I use the jargon, but it’s all about the business needs. Which again create contracts.

Same with writing code. Code is like English for me. If I don’t have a clear idea on what to write, I stop and do research (or ask someone). But when I do, it’s as straightforward as writing a sentence.

We all do the same stuff, the disagreement would just be what you feel coding is and if you think technical work is the same thing or a superset. If you as software dev aren't hands on with planning or working more than 5% of your time, you are basically a PO with a programing hobby

I believe 99% of requests are not about what’s technically feasible. And the rare time I encountered one of those, my answer has mostly been “you don’t have enough resources to try solving that problem”.

If you know your fundamentals well, very often you will find the same common blocks everywhere. People much more smarter than me has solved a lot of fundamental issues and it’s rare that I see a business request that doesn’t reuse the same familiar stuff.

That’s why coding is mostly boring. You follow the same pattern again and again. But what dictates the flows are the business parameters. And that’s why most senior spend so much time gathering good requirements. Because the code is straightforward after that.

Yeah technically drawing lines on canvases may be an very important part of being a painter, but it is hardly the core of what makes or breaks great art.

I recognize, in some capacity, that this isn't the norm and in the US "professional engineer" is protected and not simply "engineer", but it feels akin to stolen valor to me.

If you are a licensed engineer of some kind, you’d state that outright.

The equivalent of stolen valor would be claiming to be a licensed software engineer; except there is no such license so it would also be fraud, misrepresentation, etc.

(I know this is different elsewhere)

Yeah, that is basically the thing in my country. You can't call yourself an engineer without passing a test, but I can't take it because there isn't one for software engineering.

Same thing for freelancing. Freelance jobs are defined in a list, and other jobs cannot benefit from the simplified tax rules that freelancers enjoy, but that list was written before software development was a thing.

I agree. Engineers have to clear a much higher bar. Even though my career was spent in medical diagnostic software where we had to get 510k clearance, I was still keenly aware that this was a fundamentally different activity from actual engineering.

On the other hand, with the modern division of labour in a lot of companies and with the rhetoric I see here in HN and in other places: a lot of developers are indeed not even close to being engineers.

But yeah, the term is mostly misused

OP's formulation makes SWE sound like a purely noble enterprise like mathematics. It's more like an oil rig worker banging on pieces of metal with large hammers to get the drill string put together. They went in with a plan, but the reality didn't agree and they are on a tight schedule.

It's never been easier to replace chunks of code with sane software patterns, but you have to have a feel for those patterns. And also understand what's under the hood.

You folks speak like the only function of the agent is to spit code and features. Get a grip and treat your deliverables with care, otherwise you only have yourself to blame, not the AI.

[0]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

You'll end with spaghetti if you'll play a bad manager and only ever allocate time for new features and never for cleanups.

You can go through code, add REFACTOR comments based on your tastes and thoughts, and get your result and iterate to your heart's wishes. You just don't need to do the direct code typing.

More broadly, it's well understood that experiments are not a replacement for design and UX. Google is famously great at the former and terrible at the latter. Sure the AI maxxers will say the machines are coming for all creative endeavours as well, but I'm going to need more evidence. So far, everything good I've seen come from AI still had a human at the wheel, and I don't see that changing any time soon.

“Play” is what produced at least two (likely more) generations of attentive (and therefore competent) programmers. The hype around LLMs is painful, yes, but attentive human minds will ultimately bust through it.

And then there's the times when the quick sloppy poc you planned to throw away gets forced into production and is still impossible to change ten years down the road.

AI makes all these problems so much less painful.

I worked at a company which had a huge monolithic ERP system (their product, to be clear) with no good separation between the GUI layer and presentation layer. The GUI was also dependent on an ancient version of the Borland C++ compiler. They put in a humongous effort to move to a slightly more modern UI library, and a client server architecture.

However, someone had decided that messages in xml or json were too inefficient, they already had performance issues. So they went with a binary message protocol of their own design - with no features for protocol update. Everything communicating with the server had to be on exactly the same version, or it would throw an error. So of course they very, very rarely updated the protocol.

I think the best help of AI will be to clean up such real life messes of soul-crushing architectural regrets. Will it do it perfectly, certainly not, but I wouldn't do it perfectly myself either if I was forced to do it - and I'd take a hell of a lot more time to do it.

No, because no amount of experimentation can solve many of the problems that have been solved by thinking. Even your claim about "experiments are cheap" requires thinking to decide what experiments to do. No one is generating all possible solutions that fit in X megabytes; you have to think to constrain the solution space.

We saw a similar philosophy in TDD advocacy many years ago. Search for something like "Sudoku Jeffries" to see how that went. Then search for "Sudoku Norvig" to see what it looks like when you actually understand the problem.

The idea that you can somehow iterate your way to a solution when you have no idea where you're trying to go or even which direction your next step should be in has always seemed absurd to some of us but in the era of LLMs there's no longer any doubt. In the agentic era (can we call a few months an "era"?) I estimate that 90% or more of the writing I've read about how to use agents most effectively came down to making sure there is a clear specification for what they need to implement first and then imposing extensive guard rails to make sure their output does in fact follow that specification. It's all about doing enough design work up front to remove any ambiguity before coding the next part of the implementation and almost everyone claiming any sort of real world success with coding agents seems to have reached a similar conclusion.

If you care about maintainability and quality (and I include maintaining using LLM based tools) then you need to understand what it does (in doing so you will find lots of things for it to fix - you'll probably find that the architecture it's chosen is not right for what you want too).

Tell a coding agent what your new thing needs to do, give it the absolute constraints, max response times, max failover times, and so on, tell it which technologies it has access to or could use, and then tell it to spend a lot of time going over and over the design, coming up with an initial X number of designs (I use 5), and then it must self criticise each one of them and weigh them up, narrow down to three, before finally presenting those three options to the user.

Now you read the options, understand them, realise that the AI has either converged on something very sensible, or it has missed something, so you tell it what it missed and iterate. Or it nailed something good, you pick the option you prefer, and tell it to come up with a more fleshed out high level design, describing the flow and behaviour deeply (NO CODE REFERENCES!). Then once you're happy, tell it to use that and write a comprehensive coding plan. Tell it specifically what coding patterns you prefer (you should have these in your AGENTS.md file already), what patterns to avoid (single threaded? multi-threaded? Avoid gc? How you typically deal with error conditions, etc etc).

Then have it start iteratively working on the coding plan, and it *MUST* have a strong feedback loop. If there is no feedback loop initially, I tell it to build one. It must be able to write very fluent integration tests (not just unit tests). It must be able to run the app and read the logs.

Do all this and I bet you get a better result that 80% of developers out there. Coding agents are extremely good when used well.

https://www.youtube.com/shorts/xBilK3gT5e0

LLMs evaporated 90% of the "moments of despair" when you have an error and googling it isn't helping, or googling it made you realize you have to read 30min of documentation.

Coding is a joy now. LLMs shaved off all the rough edges.

I am terrified of allowing these things to complete tasks end-to-end with nothing intervening. Maybe that's why I don't run into many of these issues. I mostly delegate grunt work and manual tedium, not reasoning or design choices to the LLM. I may consult the LLM and ask for criticism, but there is no way I'm going to allow it to quietly make design decisions that I don't know about.

I use LLMs in the following ways:

1. Copy-pasting code into the web chat UI and asking for something (bugfix, add a feature, refactor, explain, review it etc), including entire source code files. A $20/mo Gemini subscription goes a long way (never been rate-limited). I only use the highest model. I often just copy-paste the entire source file between 3 backticks.

2. Cursor Tab. I do have hotkeys to enable and disable it; it's disabled most of the time otherwise it gets annoying.

3. Single-file changes directly from Cursor's AI sidebar. I only do this for simple, predictable stuff because even their auto-routing "Premium" setting is not as good as pasting stuff into Gemini 3.1 Pro.

That means I have only two $20/mo subscriptions: Gemini and Cursor.

I don't use Claude Code, it's really for people who don't know how to code. I don't use Plan Mode; I make and track the plan myself (if at all). I only tell the LLM granular tasks to execute. I don't use `claude.md` or `agents.md` or anything like that. If I don't like a particular output, I reset everything, modify my prompt and try again.

I believe this is the only way to fully leverage LLMs without losing any product quality. If you're trading off quality for "speed" (in quotes because over the long term, a low quality codebase is a massive drag on productivity) then there's no point.

Is that accurate?

What counts as “works” is the important bit, I think.

The LLM will do what you tell it to do. Manage it.

And then condensed an equal quantity of despair out of the ether via confident confabulations.

It's getting hard to keep up with trying to teach new devs what bad code looks like. And I swear sometimes they just copy my PR comments into their AI tool to fix the mistakes without any of the learning.

How have you set yours up that works well for you?

Take the bad result that you're getting, and pretend it's coming from an enthusiastic junior. What would you tell them to make them do this task better? Add that explanation to the agent (or explain that to the LLM and get it to add that to the agent, I have found this to work as well).

When you create a task for the LLM, get it to create a requirements document that lists all the requirements. Feed that into the review agent so it understands what the code agent was trying to do.

The LLM will do what you tell it to do. It doesn't magically understand what you want it to do. You have to tell it what to do.

A year ago I would've told my boss “can't be done” about my work today. I'd tell him to get me the right person to talk to (our partner, not an alien) who could give me some insight into what the hell I'm supposed to be doing to consume their API. Or to at least explain why it is that this can't be done.

Nowadays, I spent a couple of weeks reverse engineering their terrible ideas. Yeah, it worked. But it's a complete waste of my time, and tokens, energy, chips and RAM. And worst of all, it will lead to a terrible design.

That will work, but will eventually colapse under its own weight, as we use our increased power to increase our sloppiness and take it a little further. Because we can manage it. For now.

It writes the code for you. Then it runs the tests. Then it runs the linter. Then it runs the static analysis tool. If any of those fail, then it rewrites the code and runs them all again.

You only look at the code once it has done all of that.

If AI is ignoring the rest of the document and doing whatever it wants then you need to improve your document-writing skills. You can ask it why it did something, that helps discover how to improve. It's a process of refinement and discovery, just like learning how to use any new tool.

I use AI in two ways. In the way you describe, and also in the text editor as AI autocomplete. It works great until it doesn't. It inserts typos all the fucking time.

Also, don't assume you know it all.

I don't miss wasting an hour on a problem in a technology I'm not familiar with, where it's not like a big conceptual thing but something I could clear up in 5 seconds if I just had an expert in the room.

These LLMs can already incorporate our entire cultural corpus yet your "professional experience" is the threshold they won't cross?

Regarding such formal reasoning we have already seen marked improvement in the last year or two alone. The question is how this weighs on your prediction re their capabilities in the next two, five, ten, etc years.

The present notions of harnesses, structured output or looping in the LLM to some external state or sandbox be it debugger output or embedding into a runtime already show early promising results along these lines. I see no reason to believe these gains will not continue over the next five years.

If you have some theories in the converse in that regard I am all ears.

If you think the potential of LLMs is overblown feel free to short the market. I don't pretend to know the future. But if I may, I don't think you are framing the debate in the correct terms. Evidence is an important facet of human affairs. So is risk. Best of luck with your predictions.

I agree with you both - undoubtedly there are still massive gains to be made with the frontier models we have today with tooling and iteration, yet I do not believe there's sufficient evidence to claim we are rolling towards AG/SI on an exponential curve, without some additional breakthroughs given the jagged edges and data used to train models being fundamentally linear

You just need AI to be just good enough to win the tradeoff over a human employee. Just take your average office. Then ask yourself if the bar is really that high. AGI strikes me as an extremely nebulous concept. Better to just list everyone at your office and bucket them with a guess of how soon you think AI will replace them. Or weaken their market power. This is what every corporate boss in America is already doing. I'm merely suggesting rather than hope a graph curves in our individual favor we try to act more collectively as a species. Of course, I don't hold my breath.

I also don't find myself compelled by the notion that the danger to humanity is "AGI". The true danger is as it always has been - each other.

How many years away do you think we are from a “concierge” AI that can do the menial tasks handled by most personal assistants / program managers? Booking flights and hotels and coordinating employee availability?

“Unlimited progress” is not a statement on the rate of progress, it’s a statement on the limits of progress. It’s a much weaker claim than you’re framing it as. Your claim very much is that we have not yet reached the limits of LLMs potential. My claim, conversely, is that we’re already reaching diminishing returns, which are being masked by a massive influx of compute and energy. My short: LLMs are not the path to AGI.

Most likely because you haven't constrained their behavior in your prompt. You're making the assumption that they "understand" that using best practices is what you want. You have to tell them that, and tell them which practices they should use.

If incorrect LLM output is a prompt issue then demand for experienced developers will remain, and demand may actually increase as time passes.

If LLMs get good enough, one might be tempted to ask so what if most humans can't understand the output? Human civilization has by and large been a constant exercise in us collectively accomplishing more and more while individually comprehending less and less.

Our ancestors likely understood more about hunting live game or murdering each other than we do. Most of us do not consider that a great loss. Most of us living in the modern world depend on things we don't fully comprehend. I'm just not sure how this would lead to being reassured re the human as SWE.

The article you shared has little to do with this. Questions of how to divide up gains technology creates are a separate question from that of the technology itself. Tbh I found what you shared so boring I could barely finish it. I already in this thread made an exhortation to support politicans who commit to erasing inequality. The idea that LLMs can only exist with inequality is nonsensical. The only thing grim about what you shared is the lack of political imagination. It's boring.

Software specialization might look very different in 10 years but I doubt that technically specialized humans will be completely removed from their professions. We might not be carrying bows and arrows anymore but we will be carrying the equivalent of a rope and a Stetson.

I appreciate your points. I agree with you that not all "technically specialized humans will be completely removed" but let's not pretend the comparison is going from a caveman with a spear to a cowboy with a lasso. If you concede it is likely to be very different at some point calling it SWE is no longer useful.

I think SWEs would be better off realizing they have enjoyed a relatively extreme level of privilege, and rather than trying to hold onto it, use what time they still have to advocate for a more egalitarian society, even if that means giving up some of their gains. Otherwise speaking of farming, the mass layoffs to come when software has been disrupting blue collar jobs for decades will really be a chickens coming home to roost moment.

Considering that only 1% of the US workforce was a software engineer I expect similar workforce optimization to occur in software engineering specializations over the next 12,000 years. /s But seriously, it's never going to zero.

No need for specialized commercial software, if everyone can just explain to the computer what they want in English.

When working as a SWE, the longer I did it (~30 years) more of my time was spent understanding the problem, the edge cases, how to handle the edge cases, how to do all of it affordable, on time, and within budget.

That's engineering.

What you're describing is "writing code". That's lower value than "solving the problem".

I imagine a response, "But agile development, etc."

Yep. Part of solving the often sometimes involves creating prototypes to determine the essential viability of the solution. But that's only part of it. Which prototypes do you write? How much time do you allocate to same before accepting it's a dead end (at least for now) and punting on it?

That's engineering.

Me probably coming across as a dick today? Well, I was diagnosed autistic a year ago, and I'm on extended sabbatical/unemployment (3 years now) due to autistic burnout. And masking is part of how I got the burnout.**

* Why would someone be paying for that when there is likely someone else already doing it? Unless you're the rare person who hopes to "disrupt" the competition).

** has me begging the question of why I write here at all. SMH. Why do I do what I do? No idea sometimes.

There's the saying "Any idiot can build a bridge; it takes an engineer to build a bridge that barely stands."

To put this another way, any idiotic LLM can write code. It takes a person with domain experience to understand what code to write, rewrite, or not write.

I've seen lots of organizations hollow out their internal competence in favor of outsourcing the skills. LLMs are the ultimate expression of that. There are people who say "you need to have people in your organization who understand how things work because they're the ones who solve problems!" and there are other people who say "focus on your core competencies! These problems you're worried about aren't your core competencies, so get rid of those experts, they're expensive and annoying; we can just sign a contract with an organization that'll know things for us."

At some point we all will identify exactly how much "seed corn" you need for the next season. We'll figure that out because we're starving, but at least we'll all know.

got an email address in my profile if you'd be interested in talking at some point about something, or even talking about nothing in particular. (i don't normally do this sort of HN networking stuff, i find it super cringe. but there we go).

Or are you saying that I'm lying. That I am secretly hammering away at my keyboard while pretending not to?

No, writing code hasn't been how I spend most of my time for many decades now.

Write proper API documentation laying out the assumptions and intent, generate some good API docs, write a design and architecture document (which people find they need for LLMs to work at all anyway). You’ll find that you spend a lot less time reading code.

Everything we have to do for AI to function well, would help humans to function better too.

If you take the things for AI, but do them for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written.

This only works on high-trust teams and organizations. A lot of AI productivity gains are from SWE putting the extra effort because the results will be attributed to them. Being a force-multiplier for others isn't always recognized, instead, your perfomance will likely judged solely on the metrics directly attributed to you. I learned this lesson the hard way by being idealistic, and overestimating the level of trust that had been built after joining a new team. Companies pay lip service to software quality, no one gives a shit if your code has the lowest SEV rates.

Writing code just isn't what takes time.

This is how big corporations look like, not some SV startups.

(*) Well, now claude spends a lot of time writing code, I spend a lot of time designing and steering it. Claude can write remarkably sophisticated code with the correct steering.*

Less capable engineers think in terms of implementing runtime execution and solving runtime errors.

More capable engineers think in terms of designing the most effective architecture and abstractions for maintainability, performance, and robustness.

I have a project I am working on, It has not compiled in months, but that's ok, since the real work, for me, is in the architectural design.

Yes, getting it to actually run takes some time and effort, but for me that is almost mechanical now.

Maybe you will still be needed. That is one question. How well you will be paid and treated when the barrier to entry is now "I can think" is another. As the parent indicates, most people doing software are not doing things akin to pure math. I don't think most SWEs want that lifestyle anyway.

It's ok. You shouldn't fight the coming change. Instead use the time we still have to fight for more equal outcomes (vote for politicians that support UBI, Medicare for all). The longer you delude yourself that you are uniquely needed in an increasingly mechanized world the worse all our outcomes will be.

The progress models have made in the last 5 years aren't convincing me they'll bridge that gap too soon, although I can see how some people are convinced by how decent agentic harnesses make things. I know it's really easy to get very hyped with the current state of the technology, but try to have a bit of skepticism.

Those two formulations represent different developers' approaches to the same task. The former being developers who are much better at planning than the latter.

> Most of the time is spent coding which encompasses typing, retyping, and retyping again. It also includes banging your head against the wall while trying to get one of your rewrites to work against and under-documented API.

I don't think I've experienced this to a large degree. Maybe early in my career. Most of my time now is spent formulating a solution, and time spent coding is mostly spent trying to compose my changes with the existing code in a way that is performant, reliable and meets the specifications.

One wonders why AI hasn't replaced all those non-existent documentation writers yet.

Therein lies a clue to what the future holds.

The actual problem solving was trivial but I would spend days trying to work my way around some Qt work or guess the magic Cmake incantation.

You tried to make it sound like a far more noble and risky thing than it is.

  - Well, and AI can do part of that too, maybe more of it soon.
  - ...
  - Besides, you don't need 10 guys in a team to do that. A couple of them will do, then AI will do the coding. What will happen to the rest?
  - ...

AI really depends on long winters and rare breakthroughs. Deep neural network was the most recent breakthrough.

The iterations you currently see it just adding more storage, but the fundamental neural network structure doesn't change.

I'm confident AGI will not be achieved by the LLM architecture, and when the next AI breakthrough is, is anyones guess. But if you take history into account, it will take a while.

Just like all the preceding AI booms, this one will hit its maximal point, the hype train will fizzle, the best parts will just become "normal", and then a couple of decades later something new will come to push the boundary again.

Perceptions of what knowledge counts as 'low level' are constantly shifting. These days, if you write C, you're a low-level, close to the metal programmer. In the 70s, a lot of people made fun of Unix for being implemented in a high-level programming language (i.e. C) rather than assembly.

  - Compilers will make developers irrelevant
  ...
  - Compilers can write assembly language code

  - Compilers have -O3 now

Maybe we should rejoice. I remember dreading writing documentation, and now I would happily hand that off to AI.

So those ex-developers are free to do most interesting things in the world with little change of not relying on nice, steady paychecks every month.

By removing all the junior engineers, you've fundamentally changed the market forces longer term and most people expect that to negatively impact you in the supply demand curve regardless of whether or not the statements you've made above are true, which they most likely are for senior engineers.

Theres another, different loop I keep seeing which is:

  - Company A lays off engineers citing AI efficiencies
  - People say its because of over hiring during 2020
  - Company B lays off engineers citing AI efficiencies
  - People say its because it was never a good business
  - Company C lays off engineers citing AI efficiencies
  - People say its because theres a recession

> I understand things and then apply my ability to formulate solutions

AI is coming for that too. Don't be naive

So while AI will change the industry I don't see any reputable company firing the smartest ones in the room for junior level intelligence.

Even with it advancing someone has to be responsible for when it screws up which we know it will.

As someone 35 years into my career I agree this is the most exciting part of my career. I love programming and I do it all the time but I do it by reading code and course correction and explaining how to think about the problems and herding cats - just like working with a team of 100 engineers. But the engineers I’m working with now by and large listen, don’t snipe me on perf reviews, aren’t hallucinating intent based on hallway conversations with someone else, etc. This team of AI engineers I have can explain to me their work, mistakes, drift, etc without ego and it’s if not always 100% correct it’s at least not maliciously so. It understands me no matter how complex the domain I reach into, in fact it understands the domain better than I do, so instead of spending a few months convincing people with little knowledge or experience that X is a good idea, I can actually discuss X and explore if it’s a good idea or not and make a better informed decision. I’ve learned more in these discussions than I’ve learned in decades of convincing overly egoistic juniors and managers to listen to me about something I’m an industry authority on.

However I see very clearly we will need very few of the team of 100 human engineers I can leave behind in my work. Some of will be there in a decade, but maybe less than 1:10. This is going to be a more brutal time than the Dotcom bust for CS grads, and I don’t think it will ever improve. Mostly because we simply won’t need the “my parents told me this makes money” people, just the passionate folks remain. But even then, we face a situation where the value of any software developed is very low because so much software is being developed. It’s going to turn into YouTube where software that is paid for is very small relative to the quantity of software developed. We already see this in the last few months with the rate of GitHub projects created. If the value of any software created is low, the compensation of the creator will be low unless they’re very rare talents.

Example, university versus polytechnic.

Thing is, natural selection will take care of you at the same time. Because you'll also come to rely on products they make, or services they offer, either directly or indirectly. So eventually, you too, will suffer the consequences of the enshloppification.

Saying otherwise is sort of like reducing the task of writing a novel to typing.

Dude - look what happened in the last 2 years on software.

Now project out another 10.

I totally agree with you 'as of now, in the current paradigm'.

But that could very well change.

I spent 2nd half of my 30y career fixing organizations and process where this was the case. so many things are wrong in places where this is the case (or alternatively you need a different job title :) )

Really? I mean, good on you if it's true and you like the attention but that's sounds like an implausible amount of interest in someone and their relatively mundane profession.

Being able to produce code is a huge unlock for many non-programmers. So in a way, it doesn't matter how much time existing developers spend on coding. It's about helping anyone become a developer.

I think, much sooner than that, you'll have AI pumping out practically complete implementations that meet the requirements of function, set by the people who desire that function. THOSE people will be the developers, and will be more akin to technical "creatives", more on the product side, than the developer side.

I'm imagining some "AI Native Intermediate Representation" where the prompt says "Give me a function that takes an array of strings and returns that array sorted", the real code that runs in the end is the actual C code, and the representation might be something low complexity but still human readable:

func sortArray(<String> input) -> input.order.asc;

Not quite a prompt, certainly not runnable code but a higher level hybrid that is human readable AND can be compiled into actual C code. At some point someone is going to have to debug something and nobody will be able to read assembly/real code anymore.

It just seems to me in the whole "AI WRITES MY CODE" world that nobody is really thinking about debugging and maintenance. What do we just commit the prompt we built the program with to Git and call it a day? What about when we need to modify the system? Do we make a prompt to modify? Do we modify the original prompt?

AI so far is probabilistic, and that can certainly be dealt with via various workarounds, and theres currently no reason to think todays stuff would even generate the same code twice. I can't shake the idea theres a step missing in everyone saying "AI will write all our code now".

Its all a hack until a PHD writes a paper, then it becomes a technique.

Edit: Funny story - this morning Im up early to write a program of low complexity but still somewhat rigorous. Let me see if I can think up a prompt that I might use:

I need a program invoked with a main. We'll use this as a scaffolding to extend as the requirements materialize and constraints emerge. It will generate valid trading days for ES index futures where contract months are HMUZ. For each contract it will start with the last day of trading as defined by the contract specification located at (www.cmegroup.com/contracts/ES) and build and build an array consisting of 4 calendar months of those dates starting back from the last day of the contract. This collection will be sorted in ascending order by date where by the 0 element in the array is the earliest trading date.

^^ So this here is just my intermediate step. Im not even sure this is how I want to go forward with it but this approach is just the first way I can conceive of to get the job started. From here I'll read the output and figure how to add in the useful things I need to make it actually perform the intended function beyond what this prompt tells it to do. I cant even imagine how I might specify the final product I need in English. Id be writing a giant prompt for everything I need built and code would be so much faster to write and think in. Describing my stated intent in all this in English sounds like ... murder. And we all know that prompt I just made up sitting here is both a decent start at a prompt AND wholly inadequate and will produce absolutely useless garbage.

- Meetings

- Code reviews

- Manual testing

- Deployments and more testing

- Triaging issues

- WTF how did this bug happen?

- JIRA in general

- Whiteboarding sessions / Design docs

- Interviews

- 1:1s (mandatory ones)

- 1:1s (networking / problem solving / political alignment)

- Whatever your company's version of corporate extracurriculars is

- Understanding code without writing it is as viable as understanding code that you've worked with directly or indirectly

- Businesses care that you understand code

I really doubt the first one. Traditionally, understanding a code base in large part came from working with it intimately and building that muscle memory. The idea that understanding code by reading it is as good as understanding it from writing it, in my opinion, is not realistic.

Whether businesses care that their engineers (which they are increasingly viewing as monkeys at LLM typewriters) to understand the code remains to be seen. I don't think they particularly care whether their code runs slow and is buggy so long as it works just enough to churn out features and continue to pull income.

As one of those developers who has written almost no significant code by hand since November 2025, but has produced a great deal of working software, I still understand the majority of the code I've produced just as well as if I'd typed it myself.

I may not be typing it myself, but I'm manipulating it constantly. It's not as simple as "reading" it - I'm reading it, executing it, figuring out refactorings for it, having tests built for it, having documentation built for it, sometimes writing that documentation myself, spinning up example scripts that use it, then building new code that depends on that previous code.

It's that act of exercising the code that gives me confidence that I understand it.

On the surface it sounds weird - why would this be?

Possibly because building a system is not a one-shot step, but a process of many iterations, each of which involves experiments in production, and gaining more learnings. So at the end of the process, you don't just have N lines of working code, but also N lessons learned along the way. So presumably with the AI process we miss out on half the value.

Now the going thesis is that this extra value is unnecessary if we take the plunge and don't look back. My gut says the answer is somewhere halfway, I guess we'll see.

The general progression of a Hollywood writing career is from PA (production assistant), which often starts off as a volunteer "intern" position, to writer's assistant. Assistant here usually means doing any meanial task anyone wants from fetching drycleaning to taking a dog for a grooming appointment. When you're a writer's assistant, you will oten spend time in a writer's room. You will see how the process works. You probably won't contribute anything but you may get feedback on tehings you've written from whomever you're working for.

The next step is as a staff writer. You will be paid to produce scripts and stories for a TV show, for example. That writer's room will have a head writer. On a TV show the head writer is almost always the showrunner. The showrunner is effectively the leader of the entire project and is responsible for breaking up a season intoo storylines and making sure those scripts make sense as a collective. They might one or more of those scripts or maybe not. The showrunner will hire directors for each episode.

The path from staff writer to showrunner often goes through being a producer. Producers are responsible for a lot of the logistics of filming a show. Hiring extras, finding locations, coordinating stunts and costumes and making sure the director has everything they need.

As part of all this, in the 22 episode TV era, writers would often end up spending time on set while the show is being filmed. They'd learn from the process.

Every part of this was necessary. Those writers on set are your future producers and showrunners.

So what's happened in the streaming era is that writer's rooms got smaller (so-called "mini writer's rooms"), maybe only the showrunner is ever on set, the writers have stopped working by the time filming even begins and you might only be doing 8-12 episodes. On a 22 eipside season, that one job could support you. 8-12 episodes can't.

But you see how this all breaks down when writers can no longer support themselves, they're no longer being trained to be future producers and showrunners, there's no feedback from set back to the writer's room and you end up with 3 year gaps between seasons. The only reason for all of this is because it's cheaper.

So, you may be a staff engineer who tech leads dozens of other engineers. You're not formally a manager or director but you have a lot of influence about the entire project. But how did you get there? You started as a junior engineer being told what to do. You got to see how other leaders operated. You became responsible for more and more things. You might start fixing bugs under supervision to managing a feature then an entire project and so on.

So what's going to happen here is (IMHO) we will have years of the software engineer space shrinking. There'll be very little entry-level hiring. Layoffs will reduce the entire workforce and there'll be a few tech leaders who hang on because they still produce value. Some of them will probably discover they don't produce enough value and they'll go too.

But where do the future tech leaders come from in this scenario? AI is being used as an excuse to kill the entry-level pipeline and if you go around and say "git gud" [sic] then I'm sorry but you just don't understand the impact of what's happening or you don't care because, at least for now, you're simply not affected.

You see the same thing with people who espouse the myth of meritocracy. Well, if a given workforce shrinks by 50%, half those people are, by definition, not going to survive. An individual may be about to reskill or skill up to survive but not everyone can. And that's how people end up in Amazon warehouses. At least until they're no longer needed there ether.

Eventually the market finds a new equilibrium of staff to demand ratio. You prefer that happen sooner so people don't make bad investments of their time (e.g. studying the wrong course based on inaccurate market signals).

You mean stopping CS grads, who spend money and years on their degree from pursuing a career in their field? A better move would be to stop allowing people to graduate in CS.

Not that I think that any of the above should actually be done though.

Its a free market if you are the one paying for it solely. If you are willing to pay for the degree then the demand is there for them to sell you the product. Buyer beware sadly. Its a question of what you see the purpose of the course is - to prep people for the job market or to teach knowledge? If it is the former to you then yes they should at least warn people of the competition and the contraction of the industry they may face - they can decide if it is worth it for them.

For many on this forum if they are honest with themselves given the pace of AI and the future risk/uncertainty they may not have taken this risk on. They've misallocated their own funds which is always not ideal - and sadly expected when there is rapid change; not all investments pay off. The only thing I can say is if you are young the time horizon is there to invest in something else and get back on your feet. There is more to life then work IMV especially as you get older; and an investment in your career needs enough time horizon to pay off. For many a job is a means to an end - they may enjoy it but being able to earn a long term living is the primary goal.

In other countries where the education is subsidized for the purposes of skill building for the economy then yes I actually think it might be pragmatic for them to offer less places. Otherwise its tax money going to waste with a misallocation of public resources without the associated society wide economic benefits.

I interviewed a ton of people in my career and when I ask "how much time writing code on your last job?". The more junior the person the more they would overestimate the time writing code (Some would say 90%!). Once they joined I was able to see how much time they really wrote code and it is almost never more than 30%.

Mostly because the code is only the final output. You spend most of your time doing research, talking to people. Working on Quarterly OKRs, going to meetings etc.

If you just write code you are either an extremely junior person that works on things trivial enough to not have to research or your are disillusioned and you don't realize you spend most of your time doing other things

If you're reading this and that matches your experience as an IC SWE whose job is ostensibly developing software.. you're either trapped in a very atypical org, or you're heading for a PIP.

But we would like to convince ourselves we don't.

Now those juniors whose job is to implement those solutions, they will have a hard time.

On my 50s, I also don't write as much code as I used to, even less nowadays with serverless, managed services, low code/no code tools, agent orchestration workflows, and with it I keep seeing development teams getting smaller.

I doubt this is what the OP does, but there’s tons of developers like what I described and they seem actively proud at not actually building anything and playing politics all day.

It's an interesting sentiment. I, too, am getting old and value my remaining time on the planet, and so I code by hand every chance I get. :) Luckily I'm in a position to be able to do that.

At some point you stop developing and start weighing up the requirement against your understanding of the system and the environment it works in.

A New Engineer (NE) shows up on their first day on the job, notebook in hand ready to learn. They get assigned to shadow an Experienced Engineer (EE) for their first day.

EE: Now, the thing is, for any project on our team, you only need to change about 3 lines of code. NE, preparing to write down notes: Which 3? EE: Well, it depends.

(Originally about Material Safety Data Sheets, and there only being 3 relevant lines on them).

I think this is what people miss about Software Development.

On like my fourth day he said “now I’m going to teach you the thing that helped me the most in my career…” I waited, ready for the received wisdom. And he said “always number your punch cards so if you drop them they will be easy to put back into order”. I was upset. We were long past the point where punch cards were in use. And then he said “I said what would help _me_ the most, not what would help _you_. Software is always changing”.

I’ve thought about that a lot lately.

Of course developers could just move up the “next level of abstraction” and become managers of agents who write the code, but eventually AI becomes a better manager of agents than even the best humans, at which point there is no contribution a human can make that an AI model or system of models couldn’t do better.

Resources is one. Energy, water, cost. There seems to be diminishing returns in intelligence at the moment, whilst power and memory usage continues to go up.

The open question is not “can next-token prediction produce impressive behavior?” Clearly it can. The question is whether scaling that mechanism is enough to produce stable world models, grounded understanding, long-horizon agency, self-correction, and reliable reasoning across novel situations.

That has not been demonstrated.

In the past few years I've repeated the same thing: I'm not afraid of AIs that are hallucinating. They do that by design. It is expected. What scares me is people who hallucinate something into existence which isn't there.

Wonderful articulation. There's a plethora of prognostication about how AI will change everything in software and beyond and the thing I keep thinking is, well, when will the talk stop and the demonstration of results commence. It doesn't seem to have as yet.

If it works, it'll work. The methods will spread and quickly be accessible to everyone, and progress will go on. That's great.

If it doesn't work, we'll also see that in the absence of real results. And simply stating you are seeing it doesn't qualify. It must be something we can all see and use that is unavoidably, undeniably real.

or you.

Judging by how many day to day tech products in my life are buggy, slow or user-hostile there can't be more than 50-100 tech companies actually innovating, right?

While you are seemingly not at the moment, some day you might be at the receiving end of that "natural selection" in ways that seriously impact your remainint time on the planet.

In that case you might reconsider your stance, and especially question how natural is the selection of a few powerful rich people depriving others of their way to earn a living and their way to draw meaning from their lives.

The AI revolution keeps getting compared to the industrial revolution, but people keep forgetting the consequences of that one.

And if the apocalypse comes, I'm actually not that bad at a handful of skilled blue collar jobs.

The people who should be worried are the ones with narrow skill-sets and no capacity for dealing with rapid change. Especially if those skills are shallow too.

But I wasn't talking about people. I was talking about companies. And the reason I'm not worried about companies going under is that they have gone all the time since the start of the industrial revolution. Yes, it happens faster and more violently today than before but neither the churn nor the reasons are all that new. They just need to be understood so you can deal with change rationally and without panicking.

It is a good idea to read up on historic innovation/disruption cycles and realize that they are nothing new. The only reason people think this is a new problem is that 50-100 years ago they used to take about as much time as your productive career. So people wouldn't need to understand how to deal with it. And every generation would be convinced that this is some unexpected and unique upheaval that only their generation has to deal with.

My stance is the only one that works well during disruption: you make sure you have more legs to stand on and you don't waste time fretting over things you can't change. If you find yourself out of options, you can only blame yourself.

It’s weird that people always seem to argue the extremes when reality is jumbled mess in the middle. Will developers lose jobs to AI? Without question. Will many “developer” jobs be eliminated because of that? Without question. Is it probably a really bad time to think you can go from your retail job to fixing people’s website as a lifetime career move? Yeah, probably not the best idea. Would it be smarter to focus on becoming a “Software Engineer” instead of a “Developer”? Yes usually. Does that mean it is a bad idea for EVERYONE to choose to become of developer? No, and that would be a dumb thing to argue.

We’re still going to need developers and definitely engineers, we are just going to need less of them in their current form, just like we needed less saddle makers, farriers and blacksmiths. We didn’t stop needing Horse Mechanics, we just needed less of them because we needed Car Mechanics. Some of those skills transferred, some didn’t.

The Jira ticket munchers represent a good chunk (if not, most) of the workforce in case you haven't noticed.

Also, just because you will still have a job somewhere not too far from a codebase, it doesn't mean that it will be a worth job having. Think how awful human made legacy codebases can be. Now imagine a codebase 100x bigger without the human friction of generating code (think of all the execution paths that will never be hit but will neverthless be there in big quantities increasing the time you need to understand the codebase). Now imagine that most jobs involve dealing with such codebases.

Good look, keeping your dev job and spending the rest of your career trying to understand AI generated codebases.