[rafterydj]

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.

[hellisothers]

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.

[al_borland]

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.

[rafterydj]

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.

[skydhash]

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.

[treetalker]

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

[rafterydj]

Thanks for adding the link!

[smogcutter]

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.

[skydhash]

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.

[prmph]

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.

[rafterydj]

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.