The more disposable code becomes, the less disposable intent can be. If AI makes implementation disposable enterprise intent must become durable, explicit, and verifiable.
This take misses the cognitive load involved with building and learning a new system. If you have a lot of people (for instance accountants) who need access to the same data in a way that handles it consistently across a diverse user base, it would be insane to vibe code a new app for every individual user. For certain categories of users, consistency and accuracy are more important than flexibility and novelty.
Rather than `building for the project, not for forever` , i'd reframe `build a costco, target, walmart that lets one sell papercups` ie the harness toolchain becomes the substrate of creation
I have to disagree. The paper plates versus fine china analogy isn't bad, but I think it significantly underestimates some parts of human psyche, object permanence.
I'll give two other analogies that might be apt.
First, buying cars versus leasing them.
Second, owning or long-term renting a home versus being nomadic.
Only about 20% of the car market are leases, the rest are either own outright or financed. The allure of leasing a car (aside from the tax benefits if you do it for a business), are that you have no long term attachment to the car. You drive it, you have the dealer maintain it, and after 2-3 years, you hand it back in and will likely lease another car.
Learning and adjusting to new cars takes some time, that's why nearly 80% opt for longer term ownership.
On the housing side, perhaps less than 1% of people in the US are nomadic these days (for sake of this argument, lets define that as moving around more than 4 times per year). Sure, some people have second and third homes, but generally speaking, we prefer the object permanence of known addresses by a large ratio.
Now back to software. Will some people get used to their software constantly changing? Yes.
Is it a good idea to wholesale build and tear down key systems, used broadly, every few months or even weeks? Absolutely not.
You can do that much more easily in startups, less people, less switching costs, etc.
However, in conversations I've been having with companies over 500 employees, the theme is pretty clear though: the change management required to support this kind of approach is simply not possible at those scales today, and it may well never quite get there.
The thing I think about the most is the institutional part within the organization. While enterprise software is often a bloated mess, it is true that there is a value in imposing some structure on the workflows and data that make up the actual value of what the organization does for its customers. If you onboard new employees, there is a benefit to having a shared software systems that helps them learn about the business, customers, etc. They need a source of information that they can rely upon. If everyone has their own apps that they are throwing away all the time, how do you communicate those enterprise norms of what the data 'means'?
Software covers such an extreme range. The writers of leading operating systems or AIrcraft control software writing in Haskell are very different from the coders of a SAAS CRM. Where I would agree is that for the vast majority of commercial software is rapidly being assaulted. And unless the progress in coding either stops or is stopped we can see a clear trajectory. What therefore matters is knowing what you are trying to create and how, the role of forward deployed software engineer or of technologically deployed subject matter expert becomes more important. But was it not always thus, the most important technical products are always written at the interface between need and technology. All AI Coding does is shift the interface.
No dis to the people doing the work, who are mostly excellent at their craft, but the word “engineering” has no business ever being in close proximity to the word “software”.
Keyword for me: “…we are building sandcastles, on purpose, knowing the tide comes in” - instant dopamine hit to gain ‘I built and shipped it overnight’ - It is insanity waiting for bloody (literally) consequences…
The more disposable code becomes, the less disposable intent can be. If AI makes implementation disposable enterprise intent must become durable, explicit, and verifiable.
I still worry about maintenance and technical debt but this is a fascinating take.
This take misses the cognitive load involved with building and learning a new system. If you have a lot of people (for instance accountants) who need access to the same data in a way that handles it consistently across a diverse user base, it would be insane to vibe code a new app for every individual user. For certain categories of users, consistency and accuracy are more important than flexibility and novelty.
Does the author know about APL?
Somewhat agree on this hypothesis ..
Rather than `building for the project, not for forever` , i'd reframe `build a costco, target, walmart that lets one sell papercups` ie the harness toolchain becomes the substrate of creation
I have to disagree. The paper plates versus fine china analogy isn't bad, but I think it significantly underestimates some parts of human psyche, object permanence.
I'll give two other analogies that might be apt.
First, buying cars versus leasing them.
Second, owning or long-term renting a home versus being nomadic.
Only about 20% of the car market are leases, the rest are either own outright or financed. The allure of leasing a car (aside from the tax benefits if you do it for a business), are that you have no long term attachment to the car. You drive it, you have the dealer maintain it, and after 2-3 years, you hand it back in and will likely lease another car.
Learning and adjusting to new cars takes some time, that's why nearly 80% opt for longer term ownership.
On the housing side, perhaps less than 1% of people in the US are nomadic these days (for sake of this argument, lets define that as moving around more than 4 times per year). Sure, some people have second and third homes, but generally speaking, we prefer the object permanence of known addresses by a large ratio.
Now back to software. Will some people get used to their software constantly changing? Yes.
Is it a good idea to wholesale build and tear down key systems, used broadly, every few months or even weeks? Absolutely not.
You can do that much more easily in startups, less people, less switching costs, etc.
However, in conversations I've been having with companies over 500 employees, the theme is pretty clear though: the change management required to support this kind of approach is simply not possible at those scales today, and it may well never quite get there.
The thing I think about the most is the institutional part within the organization. While enterprise software is often a bloated mess, it is true that there is a value in imposing some structure on the workflows and data that make up the actual value of what the organization does for its customers. If you onboard new employees, there is a benefit to having a shared software systems that helps them learn about the business, customers, etc. They need a source of information that they can rely upon. If everyone has their own apps that they are throwing away all the time, how do you communicate those enterprise norms of what the data 'means'?
Software covers such an extreme range. The writers of leading operating systems or AIrcraft control software writing in Haskell are very different from the coders of a SAAS CRM. Where I would agree is that for the vast majority of commercial software is rapidly being assaulted. And unless the progress in coding either stops or is stopped we can see a clear trajectory. What therefore matters is knowing what you are trying to create and how, the role of forward deployed software engineer or of technologically deployed subject matter expert becomes more important. But was it not always thus, the most important technical products are always written at the interface between need and technology. All AI Coding does is shift the interface.
No dis to the people doing the work, who are mostly excellent at their craft, but the word “engineering” has no business ever being in close proximity to the word “software”.
Which software are we talking about? Compilers? Firmware? Databases? Operating systems?
Keyword for me: “…we are building sandcastles, on purpose, knowing the tide comes in” - instant dopamine hit to gain ‘I built and shipped it overnight’ - It is insanity waiting for bloody (literally) consequences…