[nrmitchi]

> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.

I'm right there with you, but this last sentence concerned me a bit.

In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can still get art and paintings that someone poured weeks of work into, but most people buy their wall-art and chachkas at HomeGoods.

The main difference is the disposability assumption, and software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are. This mindset doesn't align well with software that must continue to operate in order to support some process. A disposable countdown app, sure, throw it away, but anything built around long running business processes should not be treated in that way.

I have concerns that focusing on software craftsmenship frames the issue as "boutique and bougie and unneccessarily expensive" vs "what I need for my usage", instead of "maintable and trustworthy" vs "disposable".

[0] Is that an initiative that benefits large model providers like OpenAI/Anthropic? maybe, but that's not my point here.

[gizmo686]

Craftsmanship is not dead in other industries in the same way it is being talked about for software.

Sure, that cheap desk that arrived in a flat box and got assembled by me and a screwdriver was mass produced in a factory. But it's design had way more expert craftsmanship put into it than would ever be feasible for a bespoke product. High upfront design cost, then mass produced at a low marginal cost.

That had been the state of art for software from the beginning. When you download Firefox, there is no expert programmer carefully building you an artisinal web browser. There is a CDN server sitting in a data center somewhere copying bytes out of its cache for you.

One of the things AI us threatening to do is replace the CAPEX craftsmanship, which has not happened at scale in other industries.

What AI has had more success at it replacing low end "artisinal" software; which is a category that has thus far been so uneconomical is essentially doesn't exist.

[beezlewax]

Do you honestly think an ikea desk has "more expert craftsmanship" than a hand crafted by a woodworker desk?

[bryanlarsen]

Definitely. Expert craftsmanship in cost optimization, in shipping optimization, in production/factory design and optimization, in material sourcing, in durability testing, in design for mass market appeal, in marketing material, in documentation, et cetera.

[dale_glass]

In some ways, sure.

The LACK (https://www.ikea.com/us/en/p/lack-side-table-white-30449908/) is probably one of the most optimized pieces of furniture you can buy. There's no hand crafted desk that can be this cheap. A wood worker won't even get out of bed for $17.

Now is it an amazingly beautiful, rock solid, heirloom quality piece of furniture? No, but it's not trying to be that.

[jon_adler]

They also double as a nice and cheap server rack!

https://wiki.eth0.nl/index.php/LackRack

[Jensson]

Don't you think IKEA has expert engineers designing their furniture that will sell millions?

Programming is the equivalent to designing a factory, not carving out wood pieces.

[abahgat]

Some programming is the equivalent to designing a factory, some programming is the equivalent to carving out wood pieces.

I've worked in large organizations where a small number of staff+ engineers were approaching programming as factory, while many more engineers were obsessing about the details of their own narrowly-focused work and liked it that way.

It feels like the scale is tipping more towards the factory model and, understandably, not everyone is excited about that.

[iceflinger]

I'm not sure why this even needs to be the comparison?

Yes there is expert craftsmanship in the industrial scale design of ikea products, and yes there is expert craftsmanship in a bespoke, handmade wooden desk, but AI results in neither of these. It's cheap and disposable and tuned for putting up the appearance of something high quality without any of the actual intent that would be put behind either of the other two examples.

[toobulkeh]

This is a great argument for software factories. Writing the systems that build the system.

[tripleee]

Physical industries are very different than software. Leather shoes are made many times, 1x per customer. Code is created once, using the same product for all customers. This gives a lot more leverage on investing in a quality product.

I also don't agree that software is disposable for the same problem. If it's a temporary problem sure, the code is thrown away and we create something new when another, different problem comes up that can be solves with software.

But if it's an enduring problem? The code sticks around.

[roncesvalles]

That's wholly the wrong perspective. The equivalent of "craftsmanship" in software would be how the shoe is designed, not its manufacturing. Software developers produce unique intellectual property. They don't manufacture units of software. Similar to book authors or musicians (not on tour).

There is no equivalent of unit manufacturing in software since it's just copying around bits.

"Craftsmanship", then, in the context of software just means how much you give a shit about designing something good. That's not going anywhere unless we get to a point where even the quality of the software that we use ceases to matter, and there is nothing to indicate we're moving in that direction.

[vitally3643]

There's a really interesting angle here from machining.

A screw used to be a bespoke and precious object. It took a ton of time and effort to make a good screw. What we would today consider a 'machine screw' could only be made by extreme labor from someone very, very skiled.

But the thing about machines is that a machine can transfer craftsmanship. You can make a single really, really good screw and then a machine can transfer the quality of that screw into countless new screws.

In the modern era, screws of all types and qualities are more or less equally disposable. We produce in the billions today screws that would take days or weeks to cut by hand.

I sort of view AI the same way I'd look at a lathe without a leadscrew. You have to make your own screw by hand the first time, and then you can transfer whatever quality you can muster to any number of new screws. If you get better at making new screws, you can load that into the lathe and start making more and better screws. But you are fundamentally limited by the quality of screw you can make yourself. If all you can manage is a crooked lumpy mess, then that's all you'll be able to get out of the machine.

[bjt]

Slightly agree. :)

I don't think handmade shoes are the right comparison, unless you're talking about software that's meant to be used by just one person.

The more apt comparison might be to the engineers building and maintaining the manufacturing equipment in the shoe factory. It's a degree removed from the consumer, but there's definitely still craftsmanship involved there.

[lelandfe]

Going to be awfully hard to market rote machine maintenance as craftsmanship, but there are some suckers out there

[bjt]

If you've ever watched an episode of "How It's Made" and seen how incredibly customized these machines are, it won't be surprising that the people who build them are proud of their work.

[lelandfe]

My skepticism of the marketability of this idea deepens

[prodigycorp]

Thought experiment: would a junior developer armed with a modern day gpt-5.5 or opus 4.8 in 2015 would have been considered a 10x developer (assuming nobody knew they were using AI)?

[MadxX79]

If you want to play games like that, you could also flip it around and ask if the AI would have been eventually fired (assuming no one knew they were talking to a computer).

Not sure what that proves.

[godelski]

  > considered a 10x developer

The 10x developer never existed. You're telling me these people are doing a year's worth of work in 1.2 months? Seriously?! 10x?! In a year you can probably learn to program from scratch and participle if you're working 8hrs per day 5 days a week

We need to stop exaggerating so much. A 2x dev would be insane! A 1.5x dev does a year's work in 8. A 1.1x dev does it in 11. Saving a whole month itself is a massive amount of money saving. Our "10x" devs are really 1.1x and I'm not sure why we see that as anything less than wildly impressive.

Can we stop exaggerating so much?

[Veserv]

Of course they do. Have you literally never run into a problem that the average developer can not solve, but a expert can solve? That is infinity times more productive.

Even assuming that maybe the average developer could come to learn how to solve the problem you can easily see the gap between taking months to learn how to solve a problem versus already knowing how to solve it on short notice being over 10x.

Large productivity differences are mostly a function of differences in capability than differences of speed in solving rote problems easily within their capabilitys.

[godelski]

  > Have you literally never run into a problem that the average developer can not solve, but a expert can solve?

In what time frame?

  > Even assuming that maybe the average developer could come to learn ... already knowing how to solve it on short notice being over 10x.

10x? I'm not convinced. 10x is a pretty big increase, as illustrated above.

Clearly I understand the gap, I explicitly mentioned it. I mentioned a month's work is quite valuable. I'm not the one diminishing that value, you are.

I can totally buy instances of 10x improvement, but that's not what we're talking about and not how anyone is using the term. Everyone is talking about sustained output. No one gives a shit if you're 100x for five minutes but 0.5x the rest of the time.

Your critique isn't wrong, per say, but it is a non sequitur to the conversation.

I doubt even a staff level engineer is even a 10x above the junior. Will the staff level engineer write better code and faster? Hell yeah they will! But will it take a junior 10 years to write the same software a staff level does in a year? Maybe. But if it does I'm not convinced they're even trying, so not a fair comparison. 10 years is a lot of time. A lot of time to learn, refactor, or even build the damn thing from scratch a few dozen times.

Seriously, 10x improvements are actually wild.

But why dismiss a 10% gain as if it's nothing? Why is the smaller number bad?

Is the need for the number to go up so strong that we don't care how divorced from reality it is?

[johnsmith1840]

I believe in a 10x because it's everywhere.

It doesn't mean more work it often means creativity.

For example when I was an EE I worked at a company that had spent nearly 8 months, 50k on consultants, and easily 3 peoples full time for a lot of effort plus the testing side.

I swapped that 800$ board out for essentially a lightbulb. Did identical work <50$ and was more reliable. That simple change was easily a 10x improvement if not more because the logistics of that one board was absurd.

I'm proud of that EE work but code is identical. I would never call myself a 10x developer but I've wiped entire code bases more than once.

Maybe I have "10x" moments? But to say this isn't a real phenomenon means you're in a super structured and political enviroment.

[pmontra]

I probably had that kind of 10x moment yesterday. I spent 2.5 hours analysing a feature request and I eventually advised my customer to think very carefully about it: it might solve a problem but the implementation time is going to be long, even with an AI, because of actual development and the time we will spend in testing it. Furthermore the new infrastructure will have recurring costs higher than what it saves. My advice is not to proceed. 2.5 hours vs 25 or more. 10x.

[Jensson]

> I doubt even a staff level engineer is even a 10x above the junior

Its not about staff vs junior, its about smart vs dumb programmers. You don't get smarter with time, you just gain more experience.

[jghn]

> a problem that the average developer can not solve, but a expert can solve?

Yes these exist. The rate at which they exist is grossly exaggerated. Every company likes to think that their problems are special snowflakes. Nothing could be further from the truth.

In these discussions we try to solve for a 0.00001% problem by claiming it's common to encounter.

[yallpendantools]

I think the myth/claim of a 10x developer is true but only relative to said rockstar engineer's immediate environment.

Put simply, the 10x developer is a 10x because they've spent ~10x more time immersed in the problem domain than the average developer.

What they do is more sleight-of-hand than Tony Stark engineering his way out of a terrorist cell. If 10x engineer takes a weekend to solve a problem that has stumped the team for a month, it's because he's collected the necessary context to solve the problem over the course of their long career; doesn't mean the answer didn't need to be synthesized, but they already had the raw materials in their cupboard. They have a giants' shoulder to stand on because they bothered climbing. They didn't derive anything from first principles; no one prototyped an Iron Man suit from scrap contraband.

The implication being anyone can be a 10x engineer in the right environment.

---

Allow me to carry my own throne with an anecdote, believe what you will: once upon a time, Engineering Manager had the brilliant idea to create a modular system for our main product, the pitch being that we can outsource feature development to contractors while keeping team costs down as we only need to maintain a lean modular system. They tested the idea on a couple of easy scope projects which were successful.

Then came the big test. Three projects outsourced to a team of four contractors. These projects were far more complex than the first two: lots of state management and integration with other systems. In due time deadline neared and the contractors had a very pretty UI that just needed to be wired in. I got pulled in to see the projects home. It was supposed to be easy if not for the Pareto Principle. Relationship with the contractors soon soured as they bailed, showing us that they've technically already accomplished the project on their billable hours spreadsheet. We, the regular team, just needed to deploy the code they turned in but the deployment is none of their concern apparently.

That's when I had to roll-up my sleeves, got dirty with their spaghetti code. The way I see it, the contractors fell on the part where they had to integrate with other systems because said systems were legacy, i.e., created before the idea of the Lean Modular Main System. Honestly, even I didn't know exactly how to work with them but, crucially, I knew how to get answers when the going got tough. I knew how to quickly figure out what I didn't know because as a regular employee I knew things beyond first principles.

In the end, two out of the three projects deployed. They were only a couple weeks late. IIRC the third one only failed because it really ran out of time budget. Upper Management was not happy but Engineering Manager stuck out his neck for me, for which I am genuinely grateful. I didn't get exactly the coveted 10x wording out of him but he pointed out that I released 2/3 whereas a team of four couldn't even release one.

That's not entirely accurate of course. I could code you up a decent web frontend but I could not, for the life of me, get all those pretty UI animations to work even if it's my only way out of a terrorist cell.

[godelski]

  > the 10x developer is a 10x because they've spent ~10x more time immersed in the problem domain than the average developer.

Your ratio is off. This doesn't grow linearly, it grows exponentially. It probably takes more than 10x the experience/time to get to 2x in performance.

  > If 10x engineer takes a weekend to solve a problem that has stumped the team for a month

This is very rare in the real world. There are also alternative explanations you're ignoring:

  1. Luck. Seriously, do not underestimate luck, it plays a major role in your life[0]
  2. Fresh eyes: You're not burdened with all the noise of the past engineering[1]
  3. Getting to leverage the existing work. You have a new prior, you know to not think through the problem like the rest of the team has been.

Those are two obvious explanations but there are more. The reality is that it is going to be some combination along with the experience that you suggested.

  > I didn't get exactly the coveted 10x wording out of him

I do not want to imply in the least that you shouldn't be proud of your accomplishments. You absolutely should! But is this "10x" or actually smaller? A few weeks late you said, so how long do you think it would have taken had you not been so skilled? 20 weeks? More? If it really would have taken 20 weeks then yes, you are a 10xer and call me wildly impressed.

But mind you, I'm also saying that being a "2xer" is wildly impressive. I'm even saying that being a 1.1xer is impressive (because it is!). So I'm really not trying to diminish your accomplishments. The feeling of pride you should have for your accomplishments shouldn't be diminished because you aren't calling yourself a "10xer". That's not what's being said here.

Plus, my whole point is about sustained output. 10x and even 100x certainly exist in short tasks. I mean I can certainly produce a hello world program in python 100x faster than someone that doesn't know how to program. But over longer periods of time this gets to be much harder. Again, I don't want to diminish your pride, the story you explained is not a short task.

[0] That isn't to say that skill doesn't matter, it very much does. But luck is pretty far up there. It is behind skill in importance, but there's not a single (or even 2) factor that controls your life.

[1] This isn't luck, you can control this too. Stuck on a problem? Walk away. Go for a walk. But come back.

[datadrivenangel]

The research referenced in Fred Brook's The Mythical Man Month found that there was a 10x difference in programming task completion time between the FASTEST and the SLOWEST developers, but only a ~2.5x increase from the median to the fastest.

[mustardo]

This! I've worked with a few developers I would consider net negative to their team and product, in that their removal would have increased 3-4 other team members productivity by say 20% each. Coincidently these developers were almost exclusively Indian immigrants. In organisation with poor corporate culture and the ZIRP (Zero Interest Rate Policy) days of hiring to signal growth and managers hiring to increase the number of reports (to signal importance) compounded the problem

[xigoi]

Depends on whether they have one of the bosses that judge employees’ quality by the number of lines written.

[cyberge99]

No. I experienced this firsthand. Brought on a on level dev who was using Ai. Created slop, when asked how it works, he just said “it’s all in the documentation” Lots of good documentation, but that’s bot what I needed. I needed an engineer that understood and knew what he created. I’m no longer at that org.

[tracker1]

I'm not sure that I completely agree... my longest lived apps are the ones that were built with a KISS to the extreme mindset... make it as simple as possible and easy to replace as can be. Then it just lives forever.

My issues with using agents is actually kind of similar... pushing for simpler solutions over excess complexity... I want an image zoom control, and the AI goes down a rabbit hole of complex math, JS and CSS... Why not just wrap in a div with overflow properties set and scale the actual image size? (then it does that and uses 1/10th the code, and surprise it actually works).

The more I use AI, the more I hear about overspend and rework, the more I'm absolutely convinced that the right way to use AI in coding is as a gatekeeper... babysit it, review what it does and steer it in the right direction.

[sdeframond]

Software engineers are not artists nor shoemakers. They are factory makers.

A good analyst makes a hand-crafted, custom report in a day. A programmer makes a factory that makes thousands of reports per second for a thousand clients.

I am yet to find a factory at HomeGoods.

Now the kind of factories we make might change, but isn't it the fun part?

[xpct]

> Now the kind of factories we make might change, but isn't it the fun part?

No, I don't think it's the fun part. Judging by the number of people glooming over LLMs, not many people seem excited about it.

[brandensilva]

It is definitely the fun part to me and scaling a factory is the challenge we all decide every day we write code.

I think of AI agents as a factory unlock too.

Anything of quality needs inspection, review, and so on before you ship it. The human in the loop step is critical for value delivery.

Many software companies don't think of themselves as factories but they ship a product to a million customers and it solves a work unit of value for each customer.

Now AI agents may eventually reach a similar potential where many kinds of work can be manufactured by an agent.

The difference I think we are saying as engineers is shipping code isn't the unit of value if you want to turn a code agent into a code factory. It's just a byproduct of the value. Code is the liability, tool, or contract to delivering the value. Poor engineering results in poor output that cannot scale or poor quality that no one wants.

Without us inspecting and reviewing the output you risk the value not being delivered. Also without us, in the past you don't have a factory to begin (although vibe coding has collapsed how soon people can setup a software factory now), scaling it takes engineering effort. We build the factory and also ensure it is operating well to deliver that value to customers.

The ability for a program for loop to do a million iterations is foundational to our knowledge. AI agents just scale that up and is one of the tools we use to get there.

I'm not scared of agents making code cheap. I just see them as another tool in the arsenal to build scalable systems now. Yes some people don't need to scale and some don't need anything of quality. That's fine and is welcomed to improving people's lives. If they want to scale or need a quality factory line they come to us to deliver that still.

I think it's myopic to think this isn't coming. But it's also short sighted to assume our value is gone at building, shipping, and operating factories.

[Joel_Mckay]

Great programmers learn all documents are high latency state-machines.

A "Report" is just a document feature projection.

People may initially think this is in err, then think again... =3

[WalterBright]

I remember when the Mac made everyone a publisher.

[jorvi]

What really sucks about mass production is that it inevitably kills the middle tier of craftsmanship, whilst doing nothing to offer something of similar quality.

So before, you had 3-5 levels or craftsmanship to choose from, with an exponential cost increase. Now you either get to choose the dirt-cheap mass-produced stuff, the middle tier mass-produced stuff (still relative cheap), or like you stated, you're gonna have to drop $1000 on a pair of leather shoes. Full hockeystick-graph.

And sometimes the craftsmen just disappear. These days for example, it is hideously difficult to find high quality linnen.

[KronisLV]

> In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives.

What if for a lot of software projects out there you don't need craftsmanship but you need something closer to real engineering: "This is what a sane PostgreSQL setup and transaction management for your app looks like, this is how you do validations and the ORM layer and logging and interaction with APIs and request queueing, this is how a good front-end page looks like, here's the off-the-shelf component library you use, here's how your process errors and show toast messages and handle redirects without messing around with browser history, here's all the accessibility and mean things you DON'T do (like hijacking scroll, not having contrast, having too many animations etc.)."

You don't have a rockstar building a bridge, nor do you usually have craftsmen taking risks on innovative materials and new approaches: most of the time, you just build the damn bridge in ways that have worked for decades and have been proven. Software industry doesn't seem to know what is proven or works, cause it's a moving target. Outside of maybe niches like writing code for airplanes, completely different standards there, not sure if most devs would personally want to work in those conditions, though.

Instead on one hand you have orgs and devs that are moving too fast and create a lot of churn without nailing down what works and doesn't, on the other hand you have a lot of people (myself included) that often have to push out slop because tech stacks are a mess and you still have deadlines which don't care about any of that, and largely the state of software development seems like a comparison between Windows 9X, the UI/UX of which was at least partially based on usability studies, and the modern version which... well, you can see for yourself.

[edukite]

I still remember times when my work was mostly cleaning and refactoring old code written just to have higher LOC by devs from India paid in cents per line.

They were creating fast like AI and so mich like AI. But they were merely humans. Cleaning this slow and buggy mess took years killed many companies.

Today we have AI and industrial quantity of code without any engineering skill involved in the process

[elictronic]

"software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are"

Software has been the most disposable object in our lives since you could push a new build over the web. Builds change overnight, new versions every month with small updates. You have it backwards. Software has very little to no regulation compared to physical products and requires little to no effort to change. It has been disposable for decades at this point.

The change is large numbers of developers feel they are becoming disposable.

We will see if that is actually true if any of the AI companies can actually monetize their government cash infusions.

[nrmitchi]

> Builds change overnight, new versions every month with small updates.

Small updates are in no way throwing away the entire thing. A monthly update is not a start-from-scratch redevelopment. The old version was not disposed of in the way you are trying to imply.

[imtringued]

You're confusing binaries with source code.

The vast majority of software development is based around an incremental process over time.

Disposable source code would mean you prompt the AI for every new release and throw the old code away.

[godelski]

I don't think craftsmanship is dead, but I do think we've built a lemon economy.

The thing that creates the lemon markets is that you can't really distinguish quality until after purchase. This is extra hard with software because the average population is tech illiterate. It's even hard to distinguish when people are tech literate (and not all of HN is). Same thing with cars, most people can't tell the difference, so they buy based on price.

We kinda did this to ourselves. We pushed everything online and killed all the stores. Remember when no one would buy anything online because how risky it was? Then they created "free returns, no questions asked" and people would buy a few things and then send it back? That gave a store like feel with the convenience of home. So everyone moved online, the stores struggled to keep up, the Internet retailers kept running in the red (just like physical stores), the physical stores died, then the online sites needed to get a profit, so free returns stopped or diminished (or drove up the cost of goods. Yay arbitrage! It's like paying for credit card fees when you pay with cash \o/). So now everything is just worse.

We do similar things everywhere. We've started running the whole economy this way. By looking at it through a spreadsheet. Data is great, don't get me wrong, I'm an incredibly mathy person myself, but these are just proxies. To do good data analysis you also need to see beyond the math. To see where the proxy measurement isn't perfectly aligned with the desired measurement. How the measurement[0] can mislead you.

  > "what I need for my usage"

I hate how prolific this saying is. You can't know that you have all you need for your use case without first knowing more than you need. It's not something you asymptotically approach, you *have* to surpass it[1]. Without going beyond you, with no doubt, are just setting yourself up to live with unknown unknowns. It's absolute insanity that we say this bullshit with a smug look like we've discovered something profoundly intelligent.

[0] all measurements are proxies. You can't measure anything directly. No, you can't measure a meter. You can measure a comparison to a meter stick. You can measure the time of flight of a laser. You can do all sorts of things like that but everything is always a proxy. If you think this just matters for high precision, well... just look at any house.

[1] an incredibly talented third party could get you exactly to where you need but now you've just doubled the people working

[layer8]

More like a lemon tree economy. We can still talk about which trees to pick in order to not get lemons.

[tpdly]

Yeah, even though I like 'craftsmanship' here, stakeholders don't. I think "durability" is pretty good. 'Engineering standards' perhaps. I think we'll start to see the groundwork laid for software engineering as a proper engineering field, where specific performance characteristics are required for certain stakes.

Code can be like "heavy machinery", maybe needs license to operate. If an app has sensitive data in it, it becomes like a residential structure subject to building codes and inspections. I shudder to think of how this would play out it our oligarchic, anti-competitive environment though.

[godelski]

  > stakeholders don't

Because why would they? Most stakeholders don't have long term incentives, only short term. So the incentive is to buy low, cut corners, sell high. What's more incredible[0] is that the aggregation of this somehow makes long term growth.

[0] It's not incredibly, it's monopolies

[NichoPaolucci]

Hah. What a dream. Instead they’ll hire a team of what is essentially interns and have them deploy mass amounts of minuscule features with 0 guidance because, “hey - it’s cheap as hell and does 75% of what it’s supposed to do.”

A license to operate the code, what a trip.

To be frank, most other business units that are not tech or tech adjacent do not care about the code in the slightest, or the maintenance / security / durability of said code. It’s a tough world to live in. We understand the value of good code, maintainable systems, and proper design across the board. Relaying that to leadership who does not see the value is time wasted.

“What do you mean we need to rewrite it to adhere to engineering spec? It already works. Just deploy it to production”.

I don’t think we’ll ever be treated as engineers. We just had a non-technical person spin up a vibe-app that is now in production, real (measured, methodical, secure, spec driven, efficient) development is actively being devalued at my company and probably across the board…

Rant over. You propose a good solution I just can’t envision a future like this, there’s too much value in “barely good enough”, but perhaps the ramifications of that will eventually bring about your proposed future!

[bjertoref]

This is Indian Jugaad mentality being imported into Software Development. English equivalent is Kludge.

https://en.wikipedia.org/wiki/Jugaad

[hintymad]

Craftsmanship does not have to die to have millions of software-engineering jobs displaced, right? I assume when people worry about the craftsmanship, they worry about that enough number of people would lose their jobs because AI coding has becomes sufficiently good.

[MattGaiser]

> but anything built around long running business processes should not be treated in that way.

Arguably they are even more willing to cut corners though. Nothing by IBM or SAP should be considered "crafted", yet those companies have a strong place in the world of business today.

[dyauspitr]

Yeah someone should train these LLMs on straight compiled machine code/binaries and the output so they can start writing directly in binary.

[bjertoref]

That is like running Photoshop reliably on an encrypted image.

[dyauspitr]

Not necessarily. There is going to be a direct deterministic mapping to functionality in unencrypted raw binary.