All software is path dependent, all code is a liability, and all technical decisions are tradeoffs. These are the immutable truths of software that not changed one iota due to AI or any Moore's Law progress before it.
There are too many product managers and decision makers that are unable or unwilling to do the hard work of actually thinking through what they want, and re-evaluating their priors as new feedback and learnings come in. Similarly, there are too many engineers who are distant from the customer and the problem at hand, and end up chasing their own idea platonic ideal of good software, detached from the hard tradeoffs of what is truly needed right now vs what we anticipate needing in the future. The less software we can write to solve the problem now, while minimizing one way door decisions, and deferring as many "scaling" challenges as long as possible to make decisions with more complete information the better.
This is why AGI won't magically solve software development—because people don't actually know what they want until they try it and then they want something else. Raw intelligence can not solve for purpose or human goals. The better it gets, the more it will become like an evil genie or monkey's paw that never quite does what the feeble-minded human prompters want.
This is a fantastically well observed comment. My org is starting to get obsessed with non engineers vibe coding their own software and I’m starting to see these inabilities to stop and make those key decisions on requirements every single day.
This is all caused because no-one understands the purpose of quality in software
Low quality = cascading bugs, issues, slow to iterate and add or change features
This is just as true for human written as it is for AI
Instead we have everyone giving up on code quality as if it was just "beautiful code" perfectly indented that was only there for people to ooh and aah at
That is the one of the larger issues with poor quality. However even if there are no security issues poor quality can make your customers mad enough to go elsewhere and badmouth you to others looking at your product.
My manager who vibe coded our entire webapp in claude design. Has difficulty understanding why its still not production ready.
My job is to wire to our backend data, and a lot of these wiring require me to be in there and actually think about the features. These take time, and I just haven't figure out a way to speed this process up with Claude.
On the other hand. If his tool does the job why not. If you asked a 90s engineer how javascript triggers millions of cpu instructions for just a few code steps he would call you crazy.
> If you asked a 90s engineer how javascript triggers millions of cpu instructions for just a few code steps he would call you crazy.
I'm not a 90s engineer and that is crazy. The amount of inefficiency that people tolerate from JS and other web stuff is completely unreasonable in my view. It's also why software today is much worse than it was 20-30 years ago.
Why won't smarter and cheaper models in the future be able to automate this part for your manager as well? How novel is the feature set? Is it he has a knowledge gap or the model is incapable of something? What expertise are you bringing to bear that is beyond the scope of a future harness/model? Why wouldn't such a model simply fill in the blanks for your management, perhaps observing a diff of whatever you did? How do you verify the correctness of your thinking? Why could a future model not replicate this process?
I am just very puzzled by these sort of takes as we approach the end of 2026.
I'm not saying Its reassuring, and I think all your points are valid.
The only difference right now between my manager getting this claude design web app to production are the infrastructure and interfacing with it.
To get to prod it has to go through our monorepo pipeline, which currently requires using a cli, using a cli/command prompt requires using terminal, getting claude to use terminal also requires you to even know what a terminal is and spawning claude in there. Steering claude to do all that without knowing what or how to use a terminal is, and setting up your environment still all requires some technical knowledge or the language to tell claude to do that.
That's just getting to production. What about getting the claude design which is in a web environment without any context of all that monorepo with all its backend services. So all the interactivity that are all faked or mocked. Has to be converted to a real react components that's actually wired to the Rest API. How do you get the manager to speak to claude to do all that, with claude only being on the claude design harness?
What if manager designed a new feature that the backend service doesn't support? now your asking to make changes on the backend too.
So I think your points are valid that sure we may get to this at some point. But how exactly without the manager having to learn some technical language of steering claude and the infrastructure to support it.
We can speculate about the capability of AI models in 10 years all we want. Currently; It's not good enough for the task.
Taking a visual proof-of-concept and turning it into a real product with integration to an existing complex system requires the developer to re-do a-lot of the work. And reading code; especially AI code someone-else wrote, is a miserable experience.
mm. I could give a more proper answer. From the very short description of the original message, I don't doubt a long session with fable could get something up-and running even with the back-end integration. But if it needs to be maintained and trust-able in the long-run; or god-forbid sold to a costumer with any amount of accountability clause. Then there may be quite a bit of manual human labor involved.
Trust-able in particular is a growing issue i feel. Very polished looking AI made feature-rich software can have some atrocious bugs in the simplest of parts. Some features may not have been used at all since they were created. Testing never catches everything (even when written); humanity has probably been saved from countless billions of bugs from shower-thoughts of lunch discussions. (AI doesn't take showers). When AI made tests to verify AI made code based on the instructions of a single sleep deprived human using very fuzzy and ambiguous commutation media; can we trust that the software does what we expect it to do at all?
We had this discussion recently at work. "we spend X on our accounting and offer writing system; can we just replace it?". The answer was roughly; "yes, but would you trust it not to accidentally send us in an investigation with the IRS?". If we have to do it properly enough to trust, then AI ends up not being used for much more than user interface. (and that's still a glorified spreadsheet compared to most complex software systems). There is rather fascinating case of a UK cost tracking system convicting 900 sub-postmasters of theft (a few to prison and at-least one to self-inflicted death) over the span of 15 years because a software system was "perfect, tested, and not making any mistakes in its calculation"
Not to say AI is useless or inconsequential; we're wasting a lot of time writing low-consequence boilerplate for UI, code interfaces, API schemas, error handling and data parsing. If they don't work we notice, so they're perfect for AI. But when a "project manager" makes a "prototype app"; it sounds a-lot like a interactive prototype in javascript for the UI; closer to a modern-day figma design than a functional product.
This would be a great point if his manager asked him to wash the dishes. Who knows, in 10 years time if he finds himself with such a job he might consider himself lucky.
Anyway I hope I get an answer to my actual questions. Engaging with your "it's just a calculator" denialism is an obvious dead-end. Have a good day buddy.
Completely missing my point there. I wasn't saying it's a calculator. I was saying it's not a human intelligence and there's no reason to think it'll stand in for every responsibility we have.
Name me one human that can describe grandmaster level chess strategy but also loses to a random-only chess bot - that was the case for LLMs for a long time
My point is LLMs aren't humans. They're not a toddler slowly getting smarter, and when they're smarter they'll be able to do everything a human can do. It's a different scale entirely.
I didn't ask for every responsibility I asked for his specific responsibility.
Why don't you calm down and read my question again and you will see the only one "completely missing the point" is you.
You're arguing with someone else. I didn't make a claim that LLMs were human. If you're going to respond to me then engage with what I'm exactly saying. Go back and read it again, if you can manage it.
A calculator used to be a human job. Are calculators smarter than humans?
I'm asking why is it reassuring about his job? Surely your big human brain can understand to be automated away doesn't mean the machine is "smart as a human" whatever that means. There is probably not a lot of utility in comparing synthetic and organic intelligence from such a reductive perspective.
Factory workers got automated by machines. Is a robotic arm smarter than a human? Is a tractor smarter than a bovine?
My question is simply what is he doing that is so "smart" or novel that it cannot be automated or mechanized. This should not be so hard to understand.
Why should they answer the question if you can't answer it yourself? What is he doing that is so "smart" or novel that it cannot be automated or mechanized right now? If you knew that answer you could put every one out of a job right now and you would be counting your trillions instead of asking "simple" questions on HN
Factory workers that did repetitive things that didn't require any thinking got automated away by machines. But there are still factory workers today that do things that require thinking.
Machines don't go deep on problems, humans do. A machine has no will or purpose to solve a novel problem on their own. Hope that answers your question.
> You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years.
> Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor.
The problem with this thinking is it requires certainty about the future. It's much cheaper right now IF AND ONLY IF you end up needing the thing. If you don't need it, then you've threw time and money down the drain.
Where I think this analogy weakens is you probably have far more certainty of whether or not you want a big family then you do on whether or not a new product line will see major adoption.
You should have an idea of where you are going so you don't paint yourself into a corner. However certainty about the future is impossible. You make your best guess and often that will be wrong. That doesn't mean it is wrong to guess, it means you need to temper your guesses.
I am known for analogies. I use them all the time to try and explain things to less technical people.
Sometimes it's building a house, sometimes it's writing a book, sometimes it's the difference between a Ford and a kit car, sometimes it's how you build a bridge.
None of them stand up to full scrutiny. You can pick every single one apart.
That's not the point of analogies. The point is to explain just one of the many aspects of software engineering in a more understandable format to the listener. Software engineering is nothing like building a physical thing. But some of the many, many problems and complexity you hit have physical product analogies.
Even if you do use AI tools to help you write the code, at some level you have to specify what the program's output should be for every possible input.
By loosely specifying things in a prompt, there's simply not enough context for the AI tool to know the "right" output to produce for all possible inputs. What's "right" is often subjective anyway ("Should this button be red or blue?").
Pretty much every project. Initially your pace is great. You're knocking out features quickly. Everyone is upbeat and enthusiastic. Then you have to put it all together. You discover scenarios that the specs don't cover. You need more info from business about validating certain combinations of inputs. When you get that, you find contradictions with some other stuff you thought was already done. You need to store another field that they forgot about, or thought was just common knowledge. So now you need to alter the database. Combinatorial complexity. It's the essential problem with software systems. If business people don't understand it, tell them to read Brooks. If they still don't understand, tell them to read it again.
> Combinatorial complexity. It's the essential problem with software systems
After using OpenBSD for a while, I fully adopted the “write less code” approach. Create the simplest solution and leave “features” out until you need them. Nice to have should be practically banned.
> "Never really finish building it" is the key insight.
The problem with software is that it is never done. There is always another feature you could have and worse than building a property the work is only done by the people on the outside.
I think it's deeper than that, once you know software is never done you have to design for constant change.
When clients ask why something takes so long, I explain that I'm not building what you asked for today, I'm building something that will be easy to turn into what you asked for today and possible to turn into whatever you ask for tomorrow.
AI has vastly changed the shape of what that looks like though. There are whole classes of refactoring work that are much cheaper and quicker to do with agents. Integrating a protocol client library say, or swapping one library for another are now potentially hour-long instead of days-long tasks, especially when you have test coverage to back you up (which AI also immensely helps you with).
That’s merely code churn, which is not a good property. What you want in a codebase is something rigid enough to satisfy today’s constraints (including optimizing them) and flexible enough to be modified for some likely future prospects.
So for any current features, cost of fixing bugs and do trivial adjustments should be very low. But working on new things should have a great ROI, especially because what’s existing can be reused as a foundation.
I don't know that saying "this work is hard" is enlightening.
More useful would be to be able to explain at some high level what the the inherent and accidental complexity is, the tradeoffs to navigate, long-term vs short-term decisions, etc.
Saying "it is hard" makes the audience think you're less of an expert in your domain and they are then inclined to find someone who doesn't say "this work is hard".
Are we though? Despite the massive growth of the "AI industry", have the self-driving cars gotten much better than the steady snails-pace we've had for two decades?
We've gotten better at data-processing; but that was only half of making a car move around safely on a road.
The various safety measures in place: special regulations, extra equipment needed, guardrails like remote driver intervention. These are not dissimilar to the kind of measures we are currently putting in place to make AI code production worthy. As we get more “miles” trust will be earned and these measures will lessen.
Not OP, but… It can drive itself…mostly (the “belt”). And when it doesn’t, you need remote drivers (the “suspenders”) to get it unstuck. I don’t need that with the car I drive myself, and it probably won’t be needed with self-driving cars (waaaay in the future, IMO).
I've been using it for years. "Let's decide where we want the plumbing to go before pouring the slab", or "let's not focus on where the couch will go before we paint the walls". Or when a 'genius cowboy dev' discovers a super fast way to get from the 2nd floor to the kitchen by cutting a hole in the floor despite all the leaks it causes and how many other people have to work around the change.
My experience matches this also. My observation is that most business people think things they know they don't know are hard, and things that they think they do know are easy. My additional observation is that AI tools make business people think they know a lot more things, so they consider a lot more things easy, when they are not. AI tools are a machine that makes business people Dunning-Kruger-max.
>We decided to go with Lovable so the recruiting team can maintain it themselves later.
Yeah, I'm not sure that's a good idea. At the end of the day, Lovable is still a TypeScript web-app with a Supabase backend full stack system. If you don't understand what you have the LLMs actually build, then there is no way you can maintain it or debug it if something goes wrong.
All these no code/vibe code website generators don't make the code go away; the code maintenance burden just shifted to somebody else.
All software is path dependent, all code is a liability, and all technical decisions are tradeoffs. These are the immutable truths of software that not changed one iota due to AI or any Moore's Law progress before it.
There are too many product managers and decision makers that are unable or unwilling to do the hard work of actually thinking through what they want, and re-evaluating their priors as new feedback and learnings come in. Similarly, there are too many engineers who are distant from the customer and the problem at hand, and end up chasing their own idea platonic ideal of good software, detached from the hard tradeoffs of what is truly needed right now vs what we anticipate needing in the future. The less software we can write to solve the problem now, while minimizing one way door decisions, and deferring as many "scaling" challenges as long as possible to make decisions with more complete information the better.
This is why AGI won't magically solve software development—because people don't actually know what they want until they try it and then they want something else. Raw intelligence can not solve for purpose or human goals. The better it gets, the more it will become like an evil genie or monkey's paw that never quite does what the feeble-minded human prompters want.
This is a fantastically well observed comment. My org is starting to get obsessed with non engineers vibe coding their own software and I’m starting to see these inabilities to stop and make those key decisions on requirements every single day.
This is all caused because no-one understands the purpose of quality in software
Low quality = cascading bugs, issues, slow to iterate and add or change features
This is just as true for human written as it is for AI
Instead we have everyone giving up on code quality as if it was just "beautiful code" perfectly indented that was only there for people to ooh and aah at
Low quality = you will sooner or later be writing a "We take security seriously" letter and buying credit monitoring for all your customers.
That is the one of the larger issues with poor quality. However even if there are no security issues poor quality can make your customers mad enough to go elsewhere and badmouth you to others looking at your product.
My manager who vibe coded our entire webapp in claude design. Has difficulty understanding why its still not production ready.
My job is to wire to our backend data, and a lot of these wiring require me to be in there and actually think about the features. These take time, and I just haven't figure out a way to speed this process up with Claude.
Yeah, I have 2 clients that are now obsessed with vibe coding. They seem to understand the realities.
On the other hand. If his tool does the job why not. If you asked a 90s engineer how javascript triggers millions of cpu instructions for just a few code steps he would call you crazy.
> If you asked a 90s engineer how javascript triggers millions of cpu instructions for just a few code steps he would call you crazy.
I'm not a 90s engineer and that is crazy. The amount of inefficiency that people tolerate from JS and other web stuff is completely unreasonable in my view. It's also why software today is much worse than it was 20-30 years ago.
Is it big data? Claude should be able to tell you what to do and give you scripts to deploy anything behind a web app.
Why is this reassuring?
Why won't smarter and cheaper models in the future be able to automate this part for your manager as well? How novel is the feature set? Is it he has a knowledge gap or the model is incapable of something? What expertise are you bringing to bear that is beyond the scope of a future harness/model? Why wouldn't such a model simply fill in the blanks for your management, perhaps observing a diff of whatever you did? How do you verify the correctness of your thinking? Why could a future model not replicate this process?
I am just very puzzled by these sort of takes as we approach the end of 2026.
I'm not saying Its reassuring, and I think all your points are valid.
The only difference right now between my manager getting this claude design web app to production are the infrastructure and interfacing with it.
To get to prod it has to go through our monorepo pipeline, which currently requires using a cli, using a cli/command prompt requires using terminal, getting claude to use terminal also requires you to even know what a terminal is and spawning claude in there. Steering claude to do all that without knowing what or how to use a terminal is, and setting up your environment still all requires some technical knowledge or the language to tell claude to do that.
That's just getting to production. What about getting the claude design which is in a web environment without any context of all that monorepo with all its backend services. So all the interactivity that are all faked or mocked. Has to be converted to a real react components that's actually wired to the Rest API. How do you get the manager to speak to claude to do all that, with claude only being on the claude design harness?
What if manager designed a new feature that the backend service doesn't support? now your asking to make changes on the backend too.
So I think your points are valid that sure we may get to this at some point. But how exactly without the manager having to learn some technical language of steering claude and the infrastructure to support it.
We can speculate about the capability of AI models in 10 years all we want. Currently; It's not good enough for the task.
Taking a visual proof-of-concept and turning it into a real product with integration to an existing complex system requires the developer to re-do a-lot of the work. And reading code; especially AI code someone-else wrote, is a miserable experience.
> Currently; It's not good enough for the task.
If the answer is it's reassuring because it's not happening yet (with your proviso for if ever) then fine.
Doesn't sound very compelling to me but if that's the answer then fair enough.
mm. I could give a more proper answer. From the very short description of the original message, I don't doubt a long session with fable could get something up-and running even with the back-end integration. But if it needs to be maintained and trust-able in the long-run; or god-forbid sold to a costumer with any amount of accountability clause. Then there may be quite a bit of manual human labor involved.
Trust-able in particular is a growing issue i feel. Very polished looking AI made feature-rich software can have some atrocious bugs in the simplest of parts. Some features may not have been used at all since they were created. Testing never catches everything (even when written); humanity has probably been saved from countless billions of bugs from shower-thoughts of lunch discussions. (AI doesn't take showers). When AI made tests to verify AI made code based on the instructions of a single sleep deprived human using very fuzzy and ambiguous commutation media; can we trust that the software does what we expect it to do at all?
We had this discussion recently at work. "we spend X on our accounting and offer writing system; can we just replace it?". The answer was roughly; "yes, but would you trust it not to accidentally send us in an investigation with the IRS?". If we have to do it properly enough to trust, then AI ends up not being used for much more than user interface. (and that's still a glorified spreadsheet compared to most complex software systems). There is rather fascinating case of a UK cost tracking system convicting 900 sub-postmasters of theft (a few to prison and at-least one to self-inflicted death) over the span of 15 years because a software system was "perfect, tested, and not making any mistakes in its calculation"
https://en.wikipedia.org/wiki/British_Post_Office_scandal
---
Not to say AI is useless or inconsequential; we're wasting a lot of time writing low-consequence boilerplate for UI, code interfaces, API schemas, error handling and data parsing. If they don't work we notice, so they're perfect for AI. But when a "project manager" makes a "prototype app"; it sounds a-lot like a interactive prototype in javascript for the UI; closer to a modern-day figma design than a functional product.
Exactly! THANK YOU!!
Because smarter for an LLM isn't operating on the same scale as human intelligence
Making a calculator a billion times "smarter" isn't going to make it able to wash dishes
This would be a great point if his manager asked him to wash the dishes. Who knows, in 10 years time if he finds himself with such a job he might consider himself lucky.
Anyway I hope I get an answer to my actual questions. Engaging with your "it's just a calculator" denialism is an obvious dead-end. Have a good day buddy.
Completely missing my point there. I wasn't saying it's a calculator. I was saying it's not a human intelligence and there's no reason to think it'll stand in for every responsibility we have.
Name me one human that can describe grandmaster level chess strategy but also loses to a random-only chess bot - that was the case for LLMs for a long time
My point is LLMs aren't humans. They're not a toddler slowly getting smarter, and when they're smarter they'll be able to do everything a human can do. It's a different scale entirely.
I didn't ask for every responsibility I asked for his specific responsibility.
Why don't you calm down and read my question again and you will see the only one "completely missing the point" is you.
You're arguing with someone else. I didn't make a claim that LLMs were human. If you're going to respond to me then engage with what I'm exactly saying. Go back and read it again, if you can manage it.
ok
Why isn't a LLM as smart as a human? Therein lies your problem.
A calculator used to be a human job. Are calculators smarter than humans?
I'm asking why is it reassuring about his job? Surely your big human brain can understand to be automated away doesn't mean the machine is "smart as a human" whatever that means. There is probably not a lot of utility in comparing synthetic and organic intelligence from such a reductive perspective.
Factory workers got automated by machines. Is a robotic arm smarter than a human? Is a tractor smarter than a bovine?
My question is simply what is he doing that is so "smart" or novel that it cannot be automated or mechanized. This should not be so hard to understand.
> My question is simply
Why should they answer the question if you can't answer it yourself? What is he doing that is so "smart" or novel that it cannot be automated or mechanized right now? If you knew that answer you could put every one out of a job right now and you would be counting your trillions instead of asking "simple" questions on HN
Factory workers that did repetitive things that didn't require any thinking got automated away by machines. But there are still factory workers today that do things that require thinking.
Machines don't go deep on problems, humans do. A machine has no will or purpose to solve a novel problem on their own. Hope that answers your question.
> You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years. > Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor.
The problem with this thinking is it requires certainty about the future. It's much cheaper right now IF AND ONLY IF you end up needing the thing. If you don't need it, then you've threw time and money down the drain.
Where I think this analogy weakens is you probably have far more certainty of whether or not you want a big family then you do on whether or not a new product line will see major adoption.
You should have an idea of where you are going so you don't paint yourself into a corner. However certainty about the future is impossible. You make your best guess and often that will be wrong. That doesn't mean it is wrong to guess, it means you need to temper your guesses.
I am known for analogies. I use them all the time to try and explain things to less technical people.
Sometimes it's building a house, sometimes it's writing a book, sometimes it's the difference between a Ford and a kit car, sometimes it's how you build a bridge.
None of them stand up to full scrutiny. You can pick every single one apart.
That's not the point of analogies. The point is to explain just one of the many aspects of software engineering in a more understandable format to the listener. Software engineering is nothing like building a physical thing. But some of the many, many problems and complexity you hit have physical product analogies.
Don't stretch analogies too far as they all pop.
Even if you do use AI tools to help you write the code, at some level you have to specify what the program's output should be for every possible input.
By loosely specifying things in a prompt, there's simply not enough context for the AI tool to know the "right" output to produce for all possible inputs. What's "right" is often subjective anyway ("Should this button be red or blue?").
In my experience the latest models actually do a pretty good job of spotting undefined behaviours, picking sensible defaults and flagging these.
Pretty much every project. Initially your pace is great. You're knocking out features quickly. Everyone is upbeat and enthusiastic. Then you have to put it all together. You discover scenarios that the specs don't cover. You need more info from business about validating certain combinations of inputs. When you get that, you find contradictions with some other stuff you thought was already done. You need to store another field that they forgot about, or thought was just common knowledge. So now you need to alter the database. Combinatorial complexity. It's the essential problem with software systems. If business people don't understand it, tell them to read Brooks. If they still don't understand, tell them to read it again.
> Combinatorial complexity. It's the essential problem with software systems
After using OpenBSD for a while, I fully adopted the “write less code” approach. Create the simplest solution and leave “features” out until you need them. Nice to have should be practically banned.
> "Never really finish building it" is the key insight.
The problem with software is that it is never done. There is always another feature you could have and worse than building a property the work is only done by the people on the outside.
I think it's deeper than that, once you know software is never done you have to design for constant change.
When clients ask why something takes so long, I explain that I'm not building what you asked for today, I'm building something that will be easy to turn into what you asked for today and possible to turn into whatever you ask for tomorrow.
AI has vastly changed the shape of what that looks like though. There are whole classes of refactoring work that are much cheaper and quicker to do with agents. Integrating a protocol client library say, or swapping one library for another are now potentially hour-long instead of days-long tasks, especially when you have test coverage to back you up (which AI also immensely helps you with).
That’s merely code churn, which is not a good property. What you want in a codebase is something rigid enough to satisfy today’s constraints (including optimizing them) and flexible enough to be modified for some likely future prospects.
So for any current features, cost of fixing bugs and do trivial adjustments should be very low. But working on new things should have a great ROI, especially because what’s existing can be reused as a foundation.
I don't know that saying "this work is hard" is enlightening.
More useful would be to be able to explain at some high level what the the inherent and accidental complexity is, the tradeoffs to navigate, long-term vs short-term decisions, etc.
Saying "it is hard" makes the audience think you're less of an expert in your domain and they are then inclined to find someone who doesn't say "this work is hard".
We’re in the self driving car stage right now. A Waymo can drive itself but the belts and suspenders involved are more expensive than a normal car.
> We’re in the self driving car stage right now
Are we though? Despite the massive growth of the "AI industry", have the self-driving cars gotten much better than the steady snails-pace we've had for two decades?
We've gotten better at data-processing; but that was only half of making a car move around safely on a road.
More expensive?
The various safety measures in place: special regulations, extra equipment needed, guardrails like remote driver intervention. These are not dissimilar to the kind of measures we are currently putting in place to make AI code production worthy. As we get more “miles” trust will be earned and these measures will lessen.
Not OP, but… It can drive itself…mostly (the “belt”). And when it doesn’t, you need remote drivers (the “suspenders”) to get it unstuck. I don’t need that with the car I drive myself, and it probably won’t be needed with self-driving cars (waaaay in the future, IMO).
This is definitely getting my favorite. I’m also going to shamelessly steal this house analogy.
Thanks for writing this!
I've been using it for years. "Let's decide where we want the plumbing to go before pouring the slab", or "let's not focus on where the couch will go before we paint the walls". Or when a 'genius cowboy dev' discovers a super fast way to get from the 2nd floor to the kitchen by cutting a hole in the floor despite all the leaks it causes and how many other people have to work around the change.
The house analogy is great. The extreme is the Winchester Mystery house.
…which is always how I explain legacy code.
Medical doctors mostly follow standard procedure and decision trees.
TBH I think we still need to explain this to ourselves first.
My experience over many decades is this:
* If a business person thinks a change or new program is very easy to do, it is really a very hard project.
* If a business person thinks the change or new program us hard to do, usually it is a trivial project.
For me, this has been true for well over 40 years. I never use any kind AI for my work, it did not exist before I retired.
This is is relatable but I think the issue is that they are uncorrelated.
If it's easy and the business thinks it's easy it gets done. If it's hard and the business thinks it's hard it doesn't.
XKCD Tasks (from 12 years ago, to the day!) https://xkcd.com/1425/
My experience matches this also. My observation is that most business people think things they know they don't know are hard, and things that they think they do know are easy. My additional observation is that AI tools make business people think they know a lot more things, so they consider a lot more things easy, when they are not. AI tools are a machine that makes business people Dunning-Kruger-max.
It's the rest of the owl.
>We decided to go with Lovable so the recruiting team can maintain it themselves later.
Yeah, I'm not sure that's a good idea. At the end of the day, Lovable is still a TypeScript web-app with a Supabase backend full stack system. If you don't understand what you have the LLMs actually build, then there is no way you can maintain it or debug it if something goes wrong.
All these no code/vibe code website generators don't make the code go away; the code maintenance burden just shifted to somebody else.
To me stories like this seem like just a moment in time.
Like in 1 to 5 years, vibe coding without looking at the code will likely be a lot better.