Disposable code is here to stay by Charity Majors.

I like the distinction between disposable and durable code: it’s about whether you try to make the code maintainable or not. Most code when working at a company is durable code, because the outcome when we get it wrong is so high (even if it’s just the risk of losing money or at worst, our job).

And the idea that we can experiment, create POCs, the 10 variations of an idea to see which one works better… that’s great. Work with the genie and figure it out, then spend the proper time and effort making it durable.

Durable code is used when the stakes are high, the losses are material, the ripple effects of failure or performance changes throughout the system are complex and unpredictable. Highly regulated industries require durable software.
[…]
Here’s one (unscientific) rule of thumb: the lower on the stack you go, the closer you get to laying bits down on disk, the more dependable and predictable our software has to be. Databases and operating systems will be durable code til the stars die out.
[…]
The difference between disposable code and durable code is not about whether the code was generated by AI or written by a human, or even how difficult it was to write. The cost is defined by the standards you are building to, and the rest of the software development lifecycle: how well you expect to maintain it, extend it, migrate it, understand its behavior, or fix it when it breaks. This is the expensive part of software development, the type that requires deep expertise and familiarity with your language and environment. Disposable code is cheap because you don’t even try to maintain it.
[…]
This isn’t about “using AI” vs. “not using AI,” or even about generating code vs. not generating code. It’s about understanding the cost model and the risk profile of the type of development you’re engaged in.
[…]
If it’s easy to achieve proficiency with disposable code generation tools, it probably won’t be thought of as software development (and the pay scale will drop accordingly). If I had to guess, I suspect it won’t be a profession at all so much as a skill set, much like typing or spreadsheets, that any tech-literate modern worker is expected to pick up in order to perform the functions of their job in marketing, sales, product, design, etc.
[…]
The coordination tax on large groups is enormous; if AI can help a smaller number of engineers own more product surface and move faster with more confidence, that’s exciting.

As Charity says, I think there likely will be changes in what programming, or rather, software development, is. Just as it did with typing before, a skill every office worker just need to have. Not that all of us are writers, just because of it.

I’m also excited at how working with a genie might open up codebases, so you need fewer people to own and maintain larger codebases (because maintenance is in communication within a team).

For example, I recently contributed to a new codebase in relatively little time and it was done so fast to the genie figuring out where to make changes. Even if I had to change most of it, because the quality wasn’t at the level where I wanted to put my name on it.