The problem with this analogy (actually one of many) is that most people can make do with a cabinet that is literally identical to everyone else's. IKEA is great for that.

If you want software that is literally identical to what someone else is using then you don't need AI. You need a license to that software! That is just the traditional software model.

AI gives software that is bespoke with hundreds of decisions made, hidden from you, in the background. If it's a throwaway script, that's fine (and I don't mean to undersell this - this is a huge application). If you want a larger program that is going to form part of your business process then it will need at least some level of supervision from an actual expert.

> Perhaps 1% percent of current software engineers of today will be needed in the future when AI code inevitably has the ability to follow good software engineering practice..

So who talks / prompts the agents to do the work - the PM ? he will do his normal job of figma designs, customer strategy , high level requirements etc etc + do all the back and forth and validation with the agent for the actual coding?

Will it be a new type of job or will we still call it a software engineer ? And if its a software engineer why do you determine it is only 1% of current software engineers - and if indeed only 1% then how soon does it happen - will it be in 3 years ? 5 years? 15? Dario said last year that this year maybe 50% of white collar new entries gets decimated. Has it happened? If not why not?

Our predictions currently suck ass. I'm not saying you're wrong - but you could be very early which is almost the same as being wrong. I don't really care if software development as a career collapses in 10 years. I really do care if it happens next year.

What a sad analogy. IKEA furniture is mostly cheap particle board crap and it's a shame that we as a humanity have cheapened our lives to the point where IKEA is some kind of standard (and the only thing) most people can afford. Back in the day furniture was artisanal and hand made yet people were able to afford and have it. Isn't that in fact weird, supposedly our societies are richer than ever before but most people can't afford artisanal goods that our forefathers would be able to afford even though they were supposedly so much poorer.

(Hint, distribution of wealth matters a lot)

Would say it really depends on the area, also don't have historical data how many 'cabinet makers' there were before around here, but I have been trying to get a custom built cabinet (really simple, just exact measurements to make most of a small space) for a year or so. All of the cabinet makers are so overbooked, that they don't even give out quotes anymore. So ymmv, but I think it also fits this analogy.

However, Ikea furniture does not tend to collapse a critical moment 90 days after it's been put together because it was unforeseen that the cup you sat on the table would be green, which it wasn't designed to account for.

Software isn't furniture, in other words.

Having not been formally verified, almost all software today feels cheap. Maybe an AI can change that at some point.

The problem with this analogy is responsibility. Same set of problems if you have a self driving car imho. Not?

...ah the classic middle manager analogy of code is X, where X is nothing like code at all but is being used to drive a point that is just standing on poor grounds.

keep it, we have been through "is like building a house", "like following a recipe", "like a living organism", "like $SOMETHING_WITH_COMPONENTS", etc...

we can handle your IKEA furniture, thanks you for your contribution

WEE WOO WEE WOO Analogy Police!

Ahem

Libraries are more like IKEA furniture.

LLMs are like 3D printed furniture. Looks flawless. But a flawless version control system in Python is about like a plastic kitchen knife or a solar powered microwave!

Ikea cabinet is pleasant to look at, and its design makes sense.

No, coding is more like building.

A garden shed can easily be built by an AI. A house? Maybe with supervision. A skyscraper? Good luck with that!

And no, garden sheds do not represent 99% of software.

> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base.

It's low priority in the sense that people in charge tend not to value it.

That's different from saying it is not impactful, or wouldn't lead to a good business outcome, if the software were built better.

Software that needs to be babysat is an ongoing opportunity cost.

Thoughtfully and coherently factorized, abiding a set of architectural rules (i.e: we compose "this" way here, re-evaluated as we go) and following up-to-date framework conventions. LLMs are terrible at this.

Chosing OOP or FP is irrelevant, fundamentals matter more

Because they are designed to be used by managers who don't know how to answer these questions and don't want to be asked them. Just have the magic answers box pick something.

The generated code is fine at the functional level, the directory structure is usually the standard pattern for the given type of project.

The error types and codes, it will produce to spec.

If you type 'make me that thingy' - yes, it's probably not going to do what you want, but if you give it spec and guidance, it usually will.

The 'interface design' ... not very good though.

Surely this is a solvable problem.

If the average, mediocre software developer can address the issue of directory structure, interface design, general state management, edge cases and subtle assumptions it should be possible to train AI systems to address these issues .

Software development is not some mystical magical activity.

I remember people making similar arguments about autonomous driving...

> But what really gets me is the model often tries to make assumptions for me that I didn't specify in the prompt.

This is a problem with your instructions, your specification. An LLM isn't a mind reader. It will attempt to succeed regardless of missing requirements and ambiguity.

They're RLHF'ed to an inch of their lives to be able to one-shot complete tasks, since requiring human input defeats the purpose of being able to replace the labor force.

But once the insanity ends LLMs will be packaged as tools for developers to use to boost their productivity, and we'll consider them as we do IDE's and debuggers and stuff. But we have to get through this hype cycle first.

> more often than not it will just make a decision and it's often the wrong one.

Let's not forget these chatbots rely on a random number generator to pick output options.

It absolutely hates code that would crash or error in any circumstance. So it adds a ton of dubious fallbacks.

hey that's my line.

I don't think there is such a thing as "software engineering fundamentals", as the fundamentals differ based on the type of software you want to make.

Do you want to make websites, or work on embedded systems?

Do you need to squeeze every OK ounce of performance out of the machine running your code, or is developer velocity more important to you?

Will your code run on a single machine, or does it need to be networked/distributed?

The thing you want to make determines what the fundamentals will look like for that area of study. There isn't enough time to learn the fundamentals of everything needed to make good software across all domains. And even if there was, you would be wasting time learning all the principles that don't apply to 99% of things you would be working on at a given moment.

I recommend Execute Program to all new learners. I like the "learning by writing small snippets of code" approach.

https://www.executeprogram.com/

Covers Python, SQL, Javascript and Typescript.

I would read (and work though the exercises in) "how to design programs", then follow it up with "the pragmatic programmer". that should catch you up with a lot of best practices.

Making lots of things and learning what works. It's good to read and find ideas to grow, but a volume of work is the most important thing. You'll discover a lot of the ideas on your own out of need. Keeping an eye out for tools and ideas related to what you enjoy can help broaden your horizons, but time spent making things is best

This applies to more than just CS, but pick a concept and relentlessly ask why it exists until you hit a physical, mathematical, or logical reality that we cannot change/control.

For example, why do web apps use a cache? Because pulling from the main DB is too slow. Why is it slow? Because storing massive amounts of permanent data requires large, dense physical disks that must be located further away from the CPU. Why does that physical distance matter? Because we cannot rewrite the laws of physics -> (Fundamental: data transmission is constrained by the speed of light) -> an electrical signal traveling across a 5cm motherboard will universally take longer to arrive than a signal traveling 1mm from a temporary local cache.

Once you’ve found the fundamental, ascend back up to the surface concept you descended from, and that may solidify the theory a bit. To reinforce it you’ll need to pair it with practice.

By that standard, human brains don't either. Our externalizations of concepts like language or symbolic structure allow us to do so. In the parlance of our times, we built our own reasoning harnesses because our intuition lead us to do so.

Even if that was true, you'd have to still prove it has emerged.

Maybe it looks like reasoning, and maybe that's enough for some.

No. You're simply wrong.

Why would "reasoning" be an emergent property of prediction?

An interesting question. We (humans) care about maintainability because the codebase will be adapted by teams of us for many years, based on new feature and bug fixes.

Rewriting from scratch is basically never an option after a certain amount of time.

Maybe the machines could just start from scratch each time and come at maintainability from a totally different angle

How do you expect us to take your views on LLM code quality and durability seriously when a) you don’t even look at the code and b) you’ve only been doing this for two months?

Prompt injection. Solved.

But accidentally breaking systems is not an issue either, obviously. Even though the system prompt asks for safety rails, and other prompts wouldn't accidentally violate that.

https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gy...

I tried this recently and the results were total banana cakes. They couldn't even make changes to Pong without breaking it.

Tell it to use red/green TDD and start things off with an already configured test suite, maybe with a single test that asserts 1+1==2.

Make sure it know how to run the tests before it starts writing any additional code.

Then set it a clear goal.

I’ve found some success is small projects, with limited scope, in a greenfield.

I’m terrified to attempt agentic anything in the repo my job actually cares about. I triggered it once by accident, when the agent was first rolled out and enabled by default… it broke everything. Now I just use ask mode, and even that is wrong half the time, and once it goes wrong it just keeps getting worse.

I saw a post from Dave Plumber who vibe coded up a new cross platform task manager. He said his spec document for the AI was 107 pages long. So maybe what I’m doing wrong is not giving the AI a literal novel of spec.

There are two 'camps' with respect to AI.

One camp already knows that Neural Nets don't work and are a dead end.

The other camp hasn't yet figured out that Neural Nets don't work, but are convinced that they do (or eventually will), because they think everything always improves over time in a linear fashion.

You're appealing to ambiguity. All you've said is you have failed—how is anyone supposed to know what went wrong?

I'd be happy to screenshare with you if you like, we can work on something trivial or open source. Half an hour should be more than enough to see whether you're doing anything obviously self-sabotaging.

What is “it” specifically and what languages are you using?