Software Engineering fundamentals matter more
rhonabwy.com275 points by ingve 20 hours ago
275 points by ingve 20 hours ago
AI generated code is like IKEA furniture.
IKEA furniture embodies many elements of good cabinet making but skips many nonessential elements. And does this more consistently than cabinet makers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day.
In the future AI code inevitably will embody most good software engineering practices. And will do this more consistently than software engineers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day.
Just look at the messages on HN or around you at your colleagues to see how mediocre the average software engineer is..
Today's IKEA is good enough for most people.
Tomorrow's AI coding will be good enough for most corporations.
Good enough to vastly reduce the need for fine craftsmen and women / software engineers.
Good enough to deskill those who call themselves cabinet makers / senior software engineers. These days the cabinet makers I personally know just do contract kitchens for project builders.
But IKEA is and AI will be, bad enough that at the high end with special requirements / taste / money / an inflated sense of self worth, some furniture makers still exist and thrive.
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.......
And as usual it will mainly be the mediocrities that remain ( so there is hope for you too ), with occasional islands of excellence.
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.
I think the issue with your rebuttal is that companies think they have a very specific problem that needs solving, so they need bespoke software. Just read on the various HN posts where people complain about PMs moving things around for no reason other than justifying their jobs.
Yep. And it's not just PMs.
Everyone with any responsibility for picking any software in a company will work very hard to make things harder and more expensive, rather than easier.
People will ask for a 100k-year app, or whatever is the Ferrari of their business. If they don't get it, they will ask for the complex features they saw in that 100k-year software package, even if they won't use it.
If it internal software, they will ask you to develop it. If it's another vendor, they will complain until they get what they want, increasing the cost. If it's vibe-coded, they will try to prompt that until it becomes a mess.
I had this with all sorts of people: HR, Sales, translators, artists, marketers, data analysts, testers. Even software engineers are obsessed with having the "most complete" in the shape of Amazon AWS and things like that.
The only situation where I didn't see this happening was in startups where people are actually busy.
Depends on the business. I can easily see Generic Local Späti being fine to replace a mediocre hand-made spreadsheet of what products they've got in stock with a vibe-coded database that can OCR all the business copy of receipts from the till, while also vibe-coding a website and logo that's far less bad than the thing they got by asking their kid's schoolfriend to make both of them on the cheap in the 2015 summer holiday.
Most businesses are small. Most of the employment isn't in small businesses.
> OCR all the business copy of receipts from the till,
I would not do this at all. OCR is still very bad. If you want incorrect dollar figures be my guest.
Sure, but I'm not suggesting it's good-good, I'm drawing a comparison with "a mediocre hand-made spreadsheet".
We live in a world where some genes had to be renamed because Excel evaluated their original names as dates, and genetics researchers used Excel anyway. Isn't there at least a reasonable risk of this happening with a random SKU, too?
> it will need at least some level of supervision from an actual expert.
An expert? An expert or two? Maybe a few experts? Sure, even that is a lot less than how many we use today. Therein lies the issue.
Yeah, the analogy is more applicable to reusable software that used to be hand-crafted. For example many enterprise systems like ERPs, CRMs, CMSs, etc.
Even in that space there is still plenty of hand-crafted solutions or customization to the enterprise-system that might as well be hand-crafted solutions.
Not to overtax the original metaphor but /r/ikeahackers exists for a reason. Giving people fittings and hardware that all more or less work together and a bunch of reasonably high quality fiber boards is often enough to build quite a lot of bespoke stuff. Add a bit of paint and you can (and people have) build gorgeous interiors while saving a considerable amount of money.
I'm not a Luddite or a drooling evangelist; my take on AI coding is basically that it's a good accelerator if you already know the shape of what you want, and have the software engineering fundamentals to build it yourself. I find myself building a lot more stuff these days because I don't have to wrangle HTML and CSS; it's one of those things I know I can do myself but I absolutely hate, and translating designs from my brain to the browser is a horrible pain. But I know, for example, what flexbox is, so I can tell my coding agent that I want something in a certain shape, laid out with flexbox, and it handles the particulars.
I think we have to acknowledge that most software engineering is just putting mostly compatible fittings together to join mostly standard sized boards. That's okay, and unless you're doing something extremely specialized most of the time the standard solution is more than good enough. I've been loving Supabase recently as my backend for AI built things because it turns out that PostgREST is a great shape for >90% of the APIs I would normally build, and RLS handles auth modeling way more concisely than domain code, and it's very easily scriptable to do all the complicated business logic bits in a contained, testable way. It's not optimal, it's not elegant sometimes, but it's fine. Every other engineering discipline coalesced on standard operating procedures decades ago, maybe we software engineers have to swallow our pride a bit and start accepting them in our discipline too.
> If you want software that is literally identical ... If it's a throwaway script, that's fine (and I don't mean to undersell this - this is a huge application).
That is the application. AppleScript, VB script, IFTT - and how many drag and drop dev tools has the industry built that were supposed to be for average office workers?
Programers are like master carpenters, and the debates we keep having sum up to joinery and how a chair leg gets turned. Meanwhile there are lots of people slapping up 2x4 and plywood shelves in their garage and bootstrapping their businesses with that.
AI is changing the "is it worth your time" calculation (https://xkcd.com/1205/ ) it's delivering on the promise of all those scripting languages that were supposed to help office drones.
most people can make do with a cabinet that is literally identical to everyone else's
If you want software that is literally identical to what someone else is using then you don't need AI.
Hey GLM 4.6 – spot the load-bearing sleight of hand.
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)
I disagree with this sentiment, IKEA furniture is much more sustainable than artisanal furniture. Most of the "back in the day" furniture came from tearing down virgin woods. Sorting + shredding-recycling + making new "cheap particle board crap" furniture takes a lot of energy, but not a lot of non-renewable resources. With increased electrification this problem is being drastically reduced and the wood is sourced from re-grown tree farms (which also have their environment problems, but it is nowhere near as bad)
I am from Brazil and before the recent soy-growing deforestation of the amazon the #1 cause of deforestation was furniture-making. My parents have a really old dinner table made from high grade wood, is it is a pain in the ass to move and it has a ton of scuffs we can't be bothered to fix. Once my parents move we will probably throw it away. It lasted 40 years (with a big varnish rework around 25 years in) but the trees used to make it will never come back, my ikea table has been with us for around 8 years and still works fine.
Particle board tech has come a long way and it is much better than it used to be, IKEA particle board is consistently "okay" to "great", but other manufacturers it is not guaranteed. The only thing it lacks (by design) is the weight, particle board will be much lighter than "normal wood" furniture, which is both good and bad depending on the situation (some types of furniture you want to be heavy).
> Most of the "back in the day" furniture came from tearing down virgin woods. Sorting + shredding-recycling + making new "cheap particle board crap" furniture takes a lot of energy, but not a lot of non-renewable resources.
It also lasted a lot longer. I have inherited furniture that must be around a 100 years old now and a lot that is over 50 years old and doing fine. A lot of my friends have older (even hundreds of years old in a fe cases). A lot of IKEA furniture will go in a decade or less, and they are far from the worst - I have chucked out furniture after three or four years. My IKEA wardrobe has deteriorated after five years.
You do not have to make better furniture by chopping down virgin woods. You can get timber from well managed forests. It is also an incentive to grow trees to maturity. You can upcycle things (the largest bit of old furniture I have got rid of went to someone who did just that). You can make better furniture by better use of recycled materials.
> particle board will be much lighter than "normal wood" furniture
It slowly buckles under load which is bad for things like bookshelves.
You've never seen ikea furniture if you think it lasts less than a decade.
There are definitely different tiers. I've bought simple shelving that began to fall apart within years (Billy maybe?). I have 10 years old bedroom furniture still going strong (Kallax/Malm).
Did you read my whole comment?
I said some lasts less than a decade, and I have quite a lot of IKEA furniture. I also said its better than most cheap furniture.
I even mentioned a specific piece of IKEA furniture I own that is clearly not going to last a decade.
I moved a lot, and in different countries. I bought different IKEA furniture pieces. There's no one size fits all. IKEA is different by country, by price, by product line... For example, I have a bed I bought from IKEA made of pine wood. Just a few years old, but it shows no signs of wear, and there's no reason for it. On the other hand, I've inherited kitchen countertops and cabinets from the previous owner, and judging by the tags, they've started their second decade sometime this year. It's particle board all the way. The hinges have completely destroyed the nesting in the doors. The doors, literally, fell off. The countertop bent because of weight, temperature, humidity... it's the kitchen after all.
I've been trying to fix these things as the problems appeared, but, really, most people in this situation would probably tear the kitchen down and put the new one up. It's ironic, because we live in a "historic" neighborhood, where the houses have been built in the 18 hundreds and some, perhaps, even 17 hundreds. But absolutely nothing in these houses is more than a decade or two old. They also use materials that superficially resemble the old stuff: plastic panels with wood-like texture, unnecessarily thick aluminum window frames that resemble the old wooden ones (and open in the wrong direction!), plastic shingles that look like ceramics... And everything is made of crap. So much so that the whole neighborhood is perpetually under construction. It's like the Winchester Mystery House that its owners keep building in hopes to stay alive.
The sustainability has to be weighed against the fact that cheap furniture doesn’t last. I know people who had to throw away furniture within just a couple years, because it was breaking down.
Meanwhile, I also know people who own pieces that are 50 years old. They look incredible and function great. Of course, we have a culture of consumerism. Most people have no desire to own or maintain something so old, they want new.
Damn, you think Ikea furniture is great?
Useful, or passable, sure. Great though?
"The only thing it lacks is weight." You must be being a bit hyperbolic no? Have you ever looked at artisanal/quality goods in comparison to IKEA? You can't see any quality difference?
This seems delusional to me, being older and more experienced with how long IKEA stuff actually lasts.
8 years is long for IKEA furniture, usually something has irreplaceablely broken by then.
IKEA also refuse to sell you spare parts.
Give me real furniture anyday.
> IKEA also refuse to sell you spare parts.
Sorry to call bullshit but I think that’s exactly what this statement is.
Just looking at our wardrobe and thinking about how it’s actually not one thing at all, but made up of dozens of different SKUs, and how I could reorder any of them individually if I needed. There are also third party sellers of parts such as runners, door rails, and the like (not that you need them since these can all be purchased from IKEA anyway).
The challenge with IKEA is colours: they used to offer more colours, but now lots of stuff is black white, grey, or beige with no other options (and sometimes white is the only option). If you need to replace a part in a colour other than that nowadays, you’ll perhaps find it difficult to impossible.
Depends on the specific piece of furniture, and how well you treat it. I have had quite mixed experience. Its not going to last like expensive stuff, but its generally far from the worst.
What a sad retelling of reality.
A large amount of ikea furniture is not cheap particle board crap. they have a range of materials for all of their products, and even some of the medium end products look nice and hold well.
Additionally, many middle-class families have "back in the day" stories where their houses were filled with bare essentials for which i'm sure an ikea bed frame would feel like an upgrade.
I think the real IKEA problem is global homogeneity (there seems to be a MALM dresser whatever home i'm in around the world), but that doesnt mean we are collectively living with a low standard.
Survivorship bias, you see only old tables or chairs that lasted, you don't see all the crap that didn't make it to present times.
False dichotomy "if it is not IKEA it is 'artisanal' great quality" — well — no our forefathers would be able to afford whatever quality had local woodworking shop and imagine that a lot of places didn't have best of te best... So IKEA made average quality much better.
> What a sad analogy. IKEA furniture is mostly cheap particle board crap
The first time I saw GenAI compared to IKEA, it was for this reason, ~"particle board is fine for furniture, but you really don't want it to be a load-bearing part of your house".
> 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.
Shakespeare's will gave to his wife his "second best bed"; if a relative of yours wrote in their will that you'd get a fancy antique bed, would you want it?: https://en.wikipedia.org/wiki/Shakespeare's_will
> (Hint, distribution of wealth matters a lot)
This was true in the past, too. The historical artefacts we mostly see are the exceptions that survived, not what average people owned.
The tightly-packed wooden homes of London before the Great Fire just aren't there any more, and even fancy places in the same category as now-iconic British country houses were not immune, "around 4,000 were demolished between 1875 and 1975" according to https://www.english-heritage.org.uk/visit/inspire-me/the-fal...
Back in the day artisans took care of horses and new have cheapened ourselves to use stinky cars. Back in the day we built computers with relays by hand, now we have cheapened ourselves to use weird semiconductors and use inefficient python code instead of highly optimized hand crafted assembly.
Maybe we should go back to hunting and gathering?
Typical sentiment I see that completely lacks any nuance. For one car vs IKEA are two completely different beasts entirely.
A car opened up new avenues that a human could never do before its invention. This itself makes it a far more worthy invention than most.
IKEA cheapened stuff and gave low quality cookie cutter furniture to everyone. Was this really a great thing, that propelled humanity forward? It’s also not like IKEA brought down the price to dirt cheap, it’s just like half or one third the price. What great thing will society lose if we ban IKEA tomorrow. People will spend a bit more on furniture, but they will have artisanal quality furniture and more artisans in society. That’s a trade I’d take any day.
But..
Most enterprise software written by your colleagues is mostly cheap particle board crap.
At least IKEA furniture is usually reliable and does not fail catastrophicaly unlike the crappy bug ridden enterprise software we all have deal with...Jira, SAP, Salesforce, Oracle, etc...
Mature AI will be better than the average mediocrity that calls himself a software developer.
It's not weird, it's because we define wealth in terms of buying IKEA furniture that we are considered much wealthier than the past. If the affordability of handmade goods or services were the measure of wealth, then perhaps we are much poorer today. I can see how each viewpoint exhibits some contradicting insights.
The industrial goods are what made us all richer and allowed us to specialize even more.
There's probably also a factor of less artisanal goods being made but yes, I agree
I think that is false, there is more artisanal furniture today. In the past people had less furniture and most of it was junk. With power tools people can afford more good furniture, even though it is lost among all the junk. Don't forget that good furniture lasts longer than junk and what the past made is kept for decades.
Also with the much larger population today, a small percentage of craftsmen still dwarfs the output of the past.
Ikea sells quality stuff as well. Also it's good that we can now afford furniture where our ancestors would have a couple of chairs and a half broken table passed down for generations.
Personally I'm quite happy that dropping a plate on the ground isn't a terrible event.
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.
Just what I need, to wake up and read yet another baseless "soon your job will be replaced" prediction.
LLM output is not like IKEA furniture at all. IKEA furniture is mass produced, identical, furniture that can be combined to accomplish some lifestyle goal.
LLM code is different every time. Sometimes it’s better than the finest custom carpentry. Frequently it is much worse than IKEA quality (in the metaphor).
Is IKEA just a drop in for "cheap crap" in this analogy? It's not like all furniture is IKEA by a long shot.
I guess in terms of "IKEA is fine if you're 23" AI is fine for throwaway work.
...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
Having not been formally verified, almost all software today feels cheap. Maybe an AI can change that at some point.
By Dijkstra's standards, we've been vibe coding for an entire century!
I had similar thoughts recently, that now that machines are good at writing proofs, this could help with their reliability in software development.
Then I had a funny incident where an LLM implemented a feature completely backwards. Plenty of tests were supplied which demonstrated that the completely broken feature was correctly implemented.
I realized that formal verification would not have helped here, if I had left the task to the machine. It would simply have written a mathematical proof of the correctness of the incorrect feature!
Apparently this is an issue for humans as well, called the "spec gap" or something like that.
It is the reason why user stories were established, so that the person interpreting the spec knows why. Generally speaking this reduces the likelihood of this gap occuring with humans significantly. At least when they're not incompetent.
Of course, but that doesn't mean formal verification isn't a huge step forward.
Yay let’s lock ourselves into the formal verification toolsets, so that we can never use new language features again.
When you board a plane, don't you love thinking about how the controllers can make use of the hottest new language features? Perhaps JSON in the stdlib?
Would you board a plane designed by AI that no engineer had ever looked at?
Or some engineer did give a cursory glance at and stamped it with LGTM?
OR new languages and frameworks ever again, since they'll slow down code generation due to lack of training, and from LLM generation standpoint this is a terrible thing to trade off.
Both this and the parent takes are exceedingly odd - don’t you think that it’d lead to the language features also just getting the same proofs, as well as better libraries and frameworks? And do you not think that this would also lead to the LLMs both outputting better code since they’d be trained on the verified stuff and also because we’d have tooling to let agent loops autonomously resolve most of the issues with what they output?
I’d rather wait 5-10 years for a stdlib way of handling JSON, XML, YAML, TOML and other formats than using unproven libraries made with unserious practices that have edge cases. The same applies for processing requests, doing any sort of multiprocessing, DB interaction, validations, hell even any and all front end work all they way down to CSS. Don’t even get me started on desktop and server software and OS stuff.
Maybe then software engineering can be treated like real engineering.
I don't think most projects can be as simple as your metaphor points to. Nobody wants to stop at 6 parts single use programs.
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.
Ikea cabinet is pleasant to look at, and its design makes sense.
But how many times can you take a piece of Ikea furniture apart and put it back together again? I have friends who have moved apartments with the same Billy bookshelf 2-3 times and if they tried it one more time the thing would collapse.
Not to belabor the metaphor as heavily as my friend's Billy, but there's a maintenance corellary to be made here. Most Ikea furniture can be put together once, in one place, and left there for a long time. But once you want to change it in place it may just collapse.
Depends on the models and your definitions of words. I've taken my Ikea table apart 3 times now and it is still absolutely rock solid, it has inserts for screws and they looks like can be re-assembled at least a few dozen times without any issue. I've also used an ultra cheap lowest tier possible, small table from Jysk which was absolutely a cardboard inside and weighed a like a feather, it was even cheaper than lowest Ikea tier. It worked for 3 years and I disassembled it's legs mounted on the self-tapping screws twice and gifted it to a neighbor recently so that would be a third time. It was still just fine, I didn't even need to drill new holes for the screws. Kitchen and wardrobes from Ikea will likely last decades without much issue.
Ikea sells cardboard things, they also sell wooden massive furniture too (surprise) and anything in between. The quality is appropriate for all tiers and they don't collapse after a single disassembly.
> But how many times can you take a piece of Ikea furniture apart and put it back together again?
How many times can you take apart regular furniture and put it back together again? Most furniture doesn't come apart at all, just move the ikea furniture like you move any other furniture don't take it apart every time and you are fine, it would be weaker if it was possible to disassemble it without issue.
You also cannot move most Ikea furniture without it falling apart, so taking it apart is actually the least damaging option. (Some of the higher end lines are okay)
While I agree with the sentiment that there are tradeoffs, and I, personally, have a bunch of Ikea furniture that I'm happy with since it does exactly what I need it to, I think "just don't take it apart" doesn't work so well with cheaper pieces.
I had to move an Ikea dresser from one room to the other and back again, and I don't think it particularly enjoyed it. It seemed quite fragile, and I had to pay attention to not twist it too much. Whereas my grandma's furniture, which was much more solidly built, seemed fine during a long-distance move. Ditto for a Besta TV stand, which seems fine if pressure is applied from the top, much less so if I try to lift it or if it's pushed from the side.
You pick cheapest most replaceable item from all there is in IKEA and make it an example?
These are acceptable tradeoffs in many circumstances. It's good that this kind of option is available, while there are other options for people with different priorities.
Its a mistake to take it apart.
The problem is made worse because people are more likely to buy cheap furniture if they are likely to move anytime soon. There is no point investing in good furniture that might not suit the next place.
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!
> “Tomorrow's AI coding will be good enough for most corporations”
Or for small businesses today who have a need to get things done, but not the knowledge to hire or manage a skilled programmer, nor the budget to pay them what they deserve.
I find most of the a16z podcast detestable (ethical & morally), but every now and then an episode is interesting or insightful. Here two founders are giving their time to their dentist’s business needs.
Which is to say, the dentist has needs but not the ability to solve them hisself or hire someone. Nevertheless I see opportunities for in-house staff who are working in parallel roles, to take on LLM coding and offering those owners solutions that they can’t hire, or buy—someone who knows the business and can get things done.
https://podcasts.apple.com/us/podcast/a16z-podcast/id8428187...
The problem with this analogy is responsibility. Same set of problems if you have a self driving car imho. Not?
> Good enough to vastly reduce the need for fine craftsmen and women / software engineers.
By your own description: No. Maybe good enough to replace mediocre-and-worse developers, at best. You have to invest disproportionate work to coax better-than-mediocre work out of an LLM.
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.
Sure, but neither do skyscrapers.
AI is getting better and better at "house" level building, especially with some supervision.
> 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.
> Making software debuggable, maintainable, layered, and composable – that’s still quite a trick. Quite a lot of that work requires extensive, thoughtful reasoning. And that’s where the LLM’s today, even the leading edge of the “capability” from frontier models, fall short.
It’s been my quest during my career to figure out what is maintainable software, what is composable or not, and how the two things, and many other things, are in direct conflict. There is no single answer. 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. Composability may matter for integrators but can be entirely ignored in your CRUD backend. Beyond that, I don’t know of a good way to measure most of these intangible properties. Highly competent software developers disagree in even basic things, like whether OOP is a good idea, should we all be using pure functional programming etc. Hence, how would you expect an LLM to get good at figuring this out for you? If you describe exactly what trade offs you are willing to make, and give it ways to measure how well it’s doing, then I do think LLMs will be able to not fall short. Given the current state of things, it’s just a matter of opinion whether LLMs fall short, or humans fall short for that matter.
> 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.
> 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.
Is it? How long do you expect to keep your momentum after "taking over the market"?
Anecdata time. I once joined a 3 year old project that had ground itself to a near halt with this philosophy. The project's lead seemed almost allergic to the word "refactoring". It had accrued so much tech debt that I was the third "new guy" to join in less than two years, after the previous attempts to hire had successively faltered within 6 months, because my predecessors couldn't deal with the unmaintainable mess. I made it to 9 months.
Maintainability is not tied to OOP or functional, but rather to how much a team cares to manage the cognitive load that comes attached to having to deal with the code base. When that becomes a genuine priority, the code tends to be written with concern for the next human mind's ability to interact with it. And when it makes sense in that one pursuit, functional, OOP, DRY, WET all become valid -- even seductive but toxic affordances like inheritance can sometimes be useful in the right context.
So one of my thoughts is maybe AI makes this more viable. You continually refactor the code base. Often when you start something you do not know the correct abstractions anyway - so vibe-code it.
Then once you have the kinda-sorta prototype, do a full rewrite, try to do component modules with interfaces.
(maybe do multiple rewrites depending on architecture complexity)
Then incrementally improve the software quality of each of the components.
---
My thesis in this is that the cost of a refactor has dropped precipitously, LLMs are really good at doing translations, and are pretty good at finding good abstractions if you work them a bit. It is also much faster, becuase in your refactor you try and focus on the big picture and interfaces, and yolo the components... Make sure that they work, but if there is a particular edge case you can fix it later.
I don't know for sure, but I am testing this out and am halfway through a rewrite of a large project into rust from c++ (second step from above) - I am mostly vibe-ing the components, But am paying a lot of attention to the interfaces and layout.
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
With generated code, the directory structure, interface design and general state management is usually a haphazard mess. Even with the best frontier models. But what really gets me is the model often tries to make assumptions for me that I didn't specify in the prompt. Subtle things like which error states are "oh shit we need to bail" vs "this isn't a deal breaker." Sometimes it will ask, but more often than not it will just make a decision and it's often the wrong one. If I don't have a fully kitted out test suit and a good type checker to verify the final product against, the the whole looping thing is just useless to me and I'm back to reviewing every line of code it puts out and having to draw on my years of architecture experience to make sure we don't build a giant pile of trash.
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.
> But what really gets me is the model often tries to make assumptions for me that I didn't specify in the prompt.
When the LLM writes a description of a codebase, you are doing transformation from more semantic meaning to less semantic meaning, and you by definition lose some details.
When you go from requirements to code, transformation is from from less semantic meaning to more semantic meaning. The the missing semantic meaning has to be invented. When inventing the missing semantic meaning, the success depends on what the LLM has trained on.
> 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.
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...
> directory structure, interface design, general state management,
These are currently problematic due to context length. You should have working memory of the whole codebase layout to decide on a sane architecture, identify opportunities for deduplication/consolidation, etc.
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.
wake up, slopinthebag. wake up..
You think LLM’s will be more than a tool?
It's about agentic systems who view humans as their "tool". Much like the companies who created them. Just read the system cards of the new frontier models how those behave without strong guardrails. And remember that we already have only a generation behing capable models in the wild without guardrails
Do you think that you can continuously train LLMs for more and more complex and more and more agentic tasks without them becoming "more than a tool"?
It absolutely hates code that would crash or error in any circumstance. So it adds a ton of dubious fallbacks.
> 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.
I have an open question for software engineers out there:
As someone that has never studied CS but has written basic code most of my life (accelerated now with AI), where is the best place to learn software engineering fundamentals?
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.
There are tons of core principles that can be learned that largely apply across fields.
One prime example, single source of truth for data/concepts. To be violated only when performance is meaningfully improved (denormalized databases). But when you do so, you should definitely recognize you're opening up out of sync issues for that performance gain.
Though for the majority of code, there is no performance benefit to adding multiple sources of truth. Yet it's the most common error I see re: quality.
The sad thing is that software engineering fundamentals and best practices never became widespread or widely taught in school prior to LLMs
I have a bachelors degree in computer science and engineering. I can tell you that throughout my 15 years of career as a software engineer (mostly backend, in fintec and JVM languages) the only things that helped me from what I learned in university were algorithms, data structure, cryptography and database internals.
Apart from that, everything else I learned when I started working (aws, design principles and coding conventions, system design patterns, domain driven design, etc.) I had to read so many books after university (pre-AI era) to learn all those things. That's what I would suggest. There are great books to learn algorithms, and data structures which is fundamental.
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.
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.
But do the same SWE fundamentals apply if the one doing the programming is many times smarter than us?
I think SWE fundamentals matter - because it will be a long time before software is a closed system.
And the problem is that as long as humans are in the loop building software that dynamic will have to be maintained.
We use Loki for logging at work. There’s certain types of queries it just doesn’t support. And so the question becomes -
Do you change logging providers Adapt to Loki’s capabilities Create a third layer / tiered storage.
And each of those decisions have multiple downstream consequences. It’s not that LLMs can’t make those decisions per say, it’s that
What does an LLM do when five different people ask for a system optimized to do five different things.
It could figure it out itself, but like I don’t think that’s how the human software contract works.
I built a harness from scratch prior to trying any of the ones out there, so I knew how it work in a real way. I QUICKLY understood that the biggest issue with getting my shit done is that _my_ inputs are the untrusty ones. How many time do you hit backspace in a day?
It wouldn't make sense to confuse attributes of the software with attributes of the programmer.
Otherwise, one could simply declare one's IQ in a const somewhere, and have all unit tests follow the form: if the programmer's IQ is high enough, then the method under test is likely correct.
LLMs are not smart in any way, but they are a weird kind of effective thats very different.
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
"They’re foundationally incapable of always and consistently preventing prompt injection attacks. “Alignment work”, safety harnesses, and sandboxes all help to add barriers against the worst, but there are fundamental gap" ...
They seem to be very good at a lot of rudimentary best practices, more so than humans, but more accurately - if you run and audit pass with specific instructions ... they're very good at that.
I mean - it's what they're the best at which is applying 'fuzzy heuristics' in a mechanical way. If can describe issues concisely, the patterns, the styles, the rules then LLMs can very mechanistically and methodologically grind through them.
I don't even see how this is controversial - without getting into 'what their reasoning means' - we can all agree that their synthetic reasoning is pretty good at narrow scales, and they've been 'trained by compilers' and are extremely good at spotting common patterns.
If you back that up with a lot of tokens ... they excel.
Designing architecture, that's difficult, but hammering away at all the 'known-knows across a system' especially to identify things ... they're pretty good at that.
> It helps to know that LLMs don’t “reason”. They predict ..
Semantics. Prediction is the training objective. The ability to reason can be, and very arguably is, an emergent property of that.
I've never found these discussions to be all that useful, because it's hard to define what conditions are sufficient to say something is "thinking" or "reasoning". It just ends up being circular and metaphysical arguments.
That being said, it's more productive to look at systematic issues of modern LLM architectures:
- The reversal problem where LLMs can learn `X is the child of Y` but have trouble inferring `Y is the parent of X`.
- No internal long term memory or out-of-context learning. They will keep making the same mistake again and again, unless some rule is persisted in the context window, which doesn't really scale well.
- Context rot, where some outdated information sticking around in context can degrade performance.
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.
Why would "reasoning" be an emergent property of prediction?
How do you predict without reasoning?
Where is the reasoning in linear regression?
Where is the reasoning in synaptic transmission?
There isn't, which is exactly the point: we do not yet understand the fundamentals behind reasoning.
Don’t we? We can build something which has all the output associated with reasoning.
I’d say we’ve figured out the fundamentals behind reasoning.
First of all this isn't true. We cannot yet build something which has all the output associated with reasoning.
But secondary to that, symbols != semantics. If I had a magical machine which could appear from the outside to be reasoning, but upon closer introspection was simply simulating reasoning, by definition it would not be reasoning. And yet that is the criterion you seem to think indicates reasoning ability. So it's not a sufficient criterion.
Claiming we've figured out the fundamentals behind reasoning is hopelessly naive.
You are making two different claims, and then treating them as one.
1. Mimicking a process may not prove that the system is truly preforming the same process. In this case, a "reasoning" process.
2. A system that simulates a process cannot, by definition, be doing the process.
The first claim can be defended, but the second doesn't follow from the first.
Calling it a "simulation" is assuming the conclusion. What makes it a simulation rather than some implementation of reasoning on a different substrate? I.e. transistors rather than neurons.
> We can build something which has all the output associated with reasoning.
Sure. A photocopier fed with a maths paper.
I’m willing to bet it still proved more novel mathematical theorems than you did.
What does this say about your reasoning?