Counterpoint: a cabinet has always been a cabinet and nobody expects it to be anything but a cabinet. Rarely are software projects as repeatable and alike to each other as cabinets are.

Software is codified rules and complexity, which is entirely aribtrary, and builds off of itself in an infinite number of ways. That makes it much more difficult to turn into factory output cabinetry.

I think more people should read "No Silver Bullet" because I hear this argument a lot and I'm not sure it holds. There _are_ niches in software that are artisanal craft, that have been majorly replaced (like custom website designers and stock WordPress templates), but the vast majority of the industry relies on cases where turning software into templates isn't possible, or isn't as efficient, or conflicts with business logic.

Counterpoint: I forget where I originally read this thought but consider compilers. At one point coding was writing assembly and now it’s generally not, sometimes some people still do it but it is far from the norm. Now, usually, you “write code” in an abstraction (possibly of an abstraction) and magic takes care of the rest.

While I imagine “make an app that does X” won’t be as useful as “if … else” there is a middle ground where you’re relinquishing much of the control you currently are trying to retain.

As complexity in a program increases, getting to the level of detail of defining the if...else becomes important. Using plain English to define the business logic, and allowing AI to fill in the gaps, will likely lead to a lot of logic errors that go uncaught until there is a big problem.

For the AI to avoid this, I'd imagine it would need to be directed not to assume anything, and instead ask for clarification on each and every thing, until there is no more ambiguity about what is required. This would be a very long and tedious back and forth, where someone will want to delegate the task to someone else, and at that point, the person might as well write their own logic in certain areas. I've found myself effectively giving sudocode to the LLM to try to properly explain the logic that is needed.

I mean that's basically all high level programming languages are, right?

I would argue that as an industry we love high level programming languages, because they allow you to understand what you are writing, much easier than looking at assembly code. Excellent for the vast majority of needs.

But then people go right on and build complicated frameworks and libraries with those languages, and very quickly the complexity (albeit presented much better for reading) comes back into a project.

Sometines you need the complexity because they make the problem simpler to solve. Especially if you have a bunch of them. Take something like a task runner, or a crude framework, or numpy… just be aware of the lower abstraction level to detect when it conflicts with the main problem.

No Silver Bullet — Essence and Accident in Software Engineering: https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...

Thanks for adding the link!

But we’re way beyond templates here.

There will be niches in research, high performance computing & graphics, security, etc. But we’re in the last generation or two that’s going to hand write their own CRUD apps. That’s the livelihood of a lot of software developers around the world.

Do people handwrite those? If you take something like Laravel and Rails. You get like 90% of the basics done by executing a few commands. The rest of it is the actual business logic and integration with obscure platforms.

I hear this denigration of CRUD apps all the time, but people forget that CRUD apps can be as complex or simple as they need to be. A CRUD app is identified as such by its purpose, not the sophistication of it.

Right now I'm wring a web app that basically manages data in a db, but guess the kinds of things I have to deal with. Here a a few (there are many much more), in no particular order:

- Caching and load balancing infrastructure.

- Crafting an ORM that handles caching, transactions, and, well, CRUD, but in a consistent, well-typed, and IO-provider-agnostic manner (IO providers could be: DBs like Postgres, S3-compatible object stores, Redis, Sqlite, Localstorage, Filesystems, etc. Yes, I need all those).

- Concurrent user access in manner that is performant and avoids conflicts.

- Db performance for huge datasets (so consideration of indexes, execution plans, performant queries, performant app architecture, etc, etc)

- Defining fluent types for defining the abstract API methods that form the core of the system

- Defining types to provide strong typing for routes that fulfill each abstract API method.

- Defining types to provide strongly-typed client wrappers for each abstract API method

- How to choose the best option for application- and API security (Cookies?, JWT?, API keys? Oauth?)

- Choosing the best UI framework for the requirements of the app. I actually had to write a custom react-like library for this.

- Media storage strategy (what variants of each media to generate on the server, how to generate good storage keys, etc.

- Writing tooling scripts that are sophisticated enough to help me type-check, build, text, and deploy the app just in the way I want

- Figuring out effective UI designs for CRUD pages, with sorting, filtering, paging, etc built in . This is far from simple. For just one example, naive paging is not performant, I need to use keyset pagination.

- Doing all the above with robust, maintainable, and performant code

- Writing effective specs and docs for all my decisions and design for the the above

- And many many more! I've been working on this "CRUD" app for years as a greenfield project that will be the flagship product of my startup.

I don't really disagree with you about handwriting CRUD apps. But I'm not sure that having an off-the-shelf solution, from AI output or not, that would spin up CRUD interfaces would _actually_ erase software as an industry.

To me it's similar to saying that there's no need for lawmakers after we get the basics covered. Clearly it's absurd, because humans will always want to expand on (or subtract from) what's already there.

I understand the analogy, but code is so much more fungible. It is the stuff of thought. Rather than a physical thing with hard limits.

I think software will remain much more artisan because, in some sense, software is a more crystallized form of thinking, yet still incredibly fungible and nebulous.

Anything adversarial is going to be the best people using the best assist: military drones, trading, anything performance hot pathed (AI inference itself), thats all too competitive to be anything but hybrid.

But by a similar argument, most anything with healthy competition and a discerning market can only lag that standard by some amount.

It's easy to conflate a once-in-a-generation orgy of monopolistic consolidation with the emergence of useful coding LLMs, but monopolies always get flabby and slack, and eventually the host organism evicts the parasite. It's when, not if.

And we'll still have the neat tools.

> For every masterpiece made by a Japanese cabinet maker, imagine how many Ikea cabinets there are out there

Minimalist design isn’t the result of minimal effort. It actually takes quite a lot of time and skill to design a cabinet that can flat pack AND be assembled easily AND fit cost constraints AND fit manufacturing and shipping and storage constraints AND have mass market appeal.

IKEA stuff exists because of hundreds or thousands of people with expertise in their roles, not in spite of them.

Those CNC-made cabinets are driven by software written by a human being. And I'm not talking about the CNC software itself: CNC machine operators _code_, even if it's not obvious to those who don't know somebody who works with CNC machines. They provide descriptions to the machine in the form of M-Code and G-Code.

Your analogy doesn't work at all.

(I know this because my previous landlady's husband was a CNC machine operator.)

C'mon, this is not hard.

What takes more time to master: Learning how to be a competent woodworker, so that you can build a piece of complex furniture from scratch, by hand. Or learning how to punch in instructions, following templates.

The first can take years to master, the latter is done in mere months. You don't need to be a master woodworker to operate a CNC machine.

With LLMs, we're now at the point where non-programmers can get working CRUD apps. Nearly impossible only 2 years ago. LLMs are encroaching what is the bread and butter to thousands of webdevs out in the world.

You can still be a rock star dev that writes world class code, but you better be working for employers that value it - because AI will force prices down. When customers discover that a $20 subscription, or service can create them things that would previously cost thousands of dollars in dev money, there's no way back. Once that cat is out of the bag, you won't get it back in.

Oh, I know exactly what you were trying to say, but it's in no way analogous. Your analogy is bogus.

And sure, you don't need a master woodworker to operate a CNC machine, but the that person is still highly skilled, it's just that the set of skills is different: they need to be able to program on some level, and they also need to have an understanding of the materials they're working with. Go away for a bit and so some research on what somebody who operates a CNC machine actually does.

i used to make 'leaflet websites' in the 90s, then shopping carts. it was an era where everybody wanted an online presence to make themselves seem legitimiate. i expect this is the normal progression of anybody born in the 80s who could do software dev.

it got to a point where people would say they needed a website and i'd say to them that a facebook page would meet their needs better or eventually that a shopify site met their needs better. my business obviously folded.

People do love Ikea, Wal-Mart, McDonalds, and The Gap.

It is an analogy that only passes the initial glance. Especially since the CNC made cabinets are not full of design flaws. Your analogy would only make sense if these CNC cabinets were generated by CNC AI that may or may not follow the sensibilities of a human designer. Or if the inexperienced carpenters using CNC machines just described the design verbally to the CNC machine instead of carefully encoding their design into gcode.

Clearly you don't value the process of coding if you think it is analogous to a carpenter manually carving the details of a design that's above the process of building it. It is not a good analogy, at all.

Surely you can see the point though - that there are numerous of trades that previously involved mastery of tools, a process of designing custom products for customers, and were made to last for decades, centuries even.

But many of those have long since been automated away, because customers are more than happy to purchase cheaper products, made almost entirely by machines.

"AI-free" development will be a tiny niche in the coming years and decades. And those developers will not get paid any extra for doing it the old way. Just like artisanal workers today.

What’s the saying, software projects are never finished, only abandoned.

Cabinets are finished.

There's plenty of cheap furniture that was designed only in CAD or something that is flimsy, doesn't fit human proportions well, and looks ugly in real life, because it was quicker to just throw it together on the computer, CNC it out, and mail the parts to people for them to build themselves than to actually carefully test it and work out the kinks. That's basically what half of IKEA is. So I think this is a decent analogy.