6 ms·

"Maybe later" was a feature

106 points by arnorhs 3mo ago

vegadw 3mo ago
I think if you assume a capitalistic, commercial framing of code, this makes sense. If you think about all the projects you don't have time to make that require code but would be really cool albeit have no *marketable* value, making those faster to make and easy to share isn't a bad thing. I want more cool free things people make out of passion - sure, you could argue using AI removes some of that passion, but there's also a large subset of people who are passionate about their field but not passionate about code, and if they're able to make something cool by feeding the idea in and pulling the token generation slot machine's lever on repeat to get their vision, I still think that's cool. Of course, there's a line where it's slop, so it depends what they're making. A tool to make music? Cool. An album where it's all AI gen'd audio. Not cool. A tool to modify art/apply filters/modify brushes? Cool. AI art standalone? Not cool. Basically, is the target something standalone as a product we want to have human creativity in the output expression (art) or not. I don't think of MS office as particular artful, but I'm sure many good books have been written in it. This line is definitely blurry and full of gray areas. For example, https://www.redwoodrhetorica.com https://www.redwoodrhetorica.com to me is totally fine, but I could see why people find it weird. Similarly, I'm sure to someone working in or on emacs or vim, they're almost sacred and they view the tool itself as a work of art, such that the idea of using AI to improve either sounds offensive, but as long as VSCode works (which, it has had more bugs lately...) I really don't care if they used Claude or whatever to work on the editor/IDE itself. Of course, there are projects and features which probably shouldn't make it past the "Should this exist?" filter. Complexity does have a cost - nobody wanted CoPilot in Notepad - but having LLMs doesn't change that, I don't think. It means we can do more, but being selective and having good taste to avoid making something bad by adding unnecessary crap to it was a problem far before LLMs.
- dbt00 3mo ago
  This seems like you're arguing against something this post does not say.
casey2 3mo ago
There is still code you aren't writing. facepalm
- dbalatero 3mo ago
  I've personally seen way more of a bias to shipping something because "now it's free" without actually discussing whether it's worthwhile. "Just do it" and we'll measure it later. Often the later doesn't happen though. I think this article is a good reminder that applying taste and asking questions is still valuable, even if the code is considered to be cheaper.
deleted 3mo ago
[deleted]
overgard 3mo ago
Definitely agree with this. Even without a large backlog, one of the things I find working on my personal project/product where I'm simultaneously the engineer/designer/project manager is it's really easy to ask the LLM to implement an idea I've been mulling for an hour or two, it one-shots it and I'm happy, and then a week or two later it starts to dawn on me that the feature was maybe not a great idea. Which isn't on the LLM, but I know when I write features by hand I tend to reach the "this is a bad idea" conclusion a lot earlier because I'm directly confronted with the cases where it won't work out, I have to think a lot harder about corner cases, etc. Where I think/hope this goes is instead of using LLMs to go faster, we use them to do better work. I'd rather someone vibe code up better ways to test things, or use it to do in-depth code analysis and bug fixing, etc., then just pile in features.
- skydhash 3mo ago
  That’s why I usually starts with the simplest version of something I want, which is usually a shell or a perl script. When I nailed down my workflows and needs, that’s when I build a proper program. This is one of the reason I like cli programs. They’re like lego blocks for workflows. Same things with bigger projects. Write the most minimalistic version of a feature, and then ship it (or do a round of testing). Iterate based on feedback.
- jfim 3mo ago
  The good thing is since the feature was cheap to implement, you can just say "this was a bad idea" and remove it, as long as adding that feature wasn't a one way decision. People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do.
  - kibwen 3mo ago
    > People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do. Careful. The sunk cost fallacy isn't just about time, it's also about money, and people may naturally be reluctant to remove bad features that cost them a lot of tokens, especially if the act of removal itself is going to cost even more tokens.
jordwest 3mo ago
From the title I thought this was gonna be about software (like MacOS updater) giving users an “Update now” and “Maybe later” option but no “don’t show this again”. I’m still holding out from upgrading to macOS 26 and it’s doing its absolute best to make me accidentally misclick to update
patcon 3mo ago
Doesn't this just mean we need to get better at the active deconstruction and disassembly process? Like it's too easy to build, so we build more things we realize later that we shouldn't. Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake". I'd much rather learn to live in the latter world. That world is based more on validated experience, and less on assumptions about a hypothetical future that hasn't yet been experienced. Of course, we will perhaps start to atrophe in our skills at projecting futures, which is a real concern. As in "what's the benefit of building robust mental models of the future when it makes more sense to YOLO through it and experience it the results directly?" It's all a little scary, to be honest. It turns a lot of the world on its head in many ways. Experientially tumbling into things with robust sensing processes... this is perhaps becoming more important than modelling futures in a judicious sense of economizing resources...
- Swizec 3mo ago
  > Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake" The hard part is that you very quickly become Salesforce or Jira or <insert large confusing product>. You have thousands of users who love your product and pay lots of money and find the features absolutely essential to their workflow. Everyone says your product is bloated and has too many useless features, if only you could delete a bunch of crap they don’t use your software would be perfect. They all use a different 20%. Delete a feature, lose a fifth of your users.
  - patcon 3mo ago
    Great point. It's probably obvious from my take that I build a lot of bespoke software, and have blind spots about the pitfalls of building at scale :)
cortesoft 3mo ago
Sometimes it is, but sometimes it isn’t. I can remember plenty of times in my career there were some “nice to haves” that we didn’t get to, and not having them continued to waste our time over and over again as we kept putting it off. Time saving work for our software lifecycle that we spent so much time working around. Some of those things we finally did get to, and then spent the next few months wondering why we hadn’t don’t it before.
- chickensong 3mo ago
  Yeah, this right here. It's a cute and pithy blog post, but it's one-dimensional. Backlogs may have plenty of dead-ends, but there's just as likely the same amount of legit work that would be useful. For every company with a security breach, there's probably a related ticket that got pushed to the back burner because it wasn't part of the core product roadmap.
- int_19h 3mo ago
  +1, I can think of many things in my career that could have been that much better if we had the time and resources to do all the bells and whistles that we wanted.
lowbloodsugar 3mo ago
I guess that’s the difference between “maybe later” and YAGNI. YAGNI is a discipline.
- block_dagger 3mo ago
  One of the most important things I ever learned from a colleague was YAGNI. He would review my code and mark sections as YAGNI. I didn't know what it meant at the time. He kindly explained and since then I have been the teacher of that very important guideline.
staticshock 3mo ago
Everything is search. Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer. AI software development is more search. If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though. The world has been writing way more books than you'll ever read, recording more music you'll ever hear, filming more television shows than you'll ever get to watch, etc. A lot of it is garbage, but the good stuff stands the test of time and rises to the top, and I'd rather live in a thriving, flourishing world full of all these things, because there's more cream-of-the-crop when there's more everything. It's evolutionary fitness operating in the space of ideas. I agree that "maybe later" was indeed a useful mechanism, and maybe even a local optimum in the development methodology search space (which recently experienced a major earthquake!), but evolutionary pressure will bring it back into existence in some form sooner or later.
- jaggederest 3mo ago
  One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"
  - apsurd 3mo ago
    I agree but the practical cost is most heavily paid in a collaborative work setting. Now everyone at all layers of a company is doing build prototype exploration but without the intermediary internal-filter check. Instead, these explorations get a straight line to production, for reasons I'm not exactly sure. Because it can I guess?
    - jaggederest 3mo ago
      Yeah that's where my eyebrows go to the moon. My investigations are at best in staging after a dev machine review, if nontech people are involved you need per-user cloud dev I think
gamerDude 3mo ago
I agree, but I think this is a skill in all parts of life. Some design has always been add, add, add. The skill to remove and simplify has always been valuable, but few do it. In weight loss, many people take the approach of add and it doesn't work. Do what you are doing now and take this pill or run further or do more. But mostly the secret is eat less. In design and engineering, it's often removing things instead of overcomplicating them. In communication, it's often, remove lots of your side points and just focus on your core argument. We may have removed a constraint that allows people to do more, but the skill has always been to choose, prioritize and remove the things that are making it worse
oxag3n 3mo ago
Was invented long, long time ago. I first learned formal definition as "part count reduction" fromm Design for Manufacturing (DFM).
andai 3mo ago
They say the fastest code is the code that never runs. This is true. But actually, this principle generalizes. The most correct code is the code that doesn't run. There are no security vulnerabilities in code that doesn't exist. It fails no tests. There are no bugs hiding within it. It requires no documentation. (And doesn't get out of sync!) It incurs no maintenance burden. The best code is no code.
greatgib 3mo ago
"4 years later it's clear that those backlog features would not have helped at all. It is a good thing they never got built." To me, it is a survivor bias. How could you know where you would have been now if you built these features of your backlog 4 years ago? Maybe some things would have been easier and faster, maybe you would have been bigger, got more customers and money. Maybe you would have done a big breakthrough that would have transformed your project into something different and better. Or maybe it would have been exactly the same, or worst, or would have led you to bankruptcy. Maybe there is a security hole that you did well to not spend time fixing because no one abused of it (...yet), or maybe some hackers could have leaked all your customer base to some random forum killing your company because of this missing fix. The outcome is unsure, but you can't easily consider as a generality that you had not needed them.

106 points by arnorhs 3mo ago

I think if you assume a capitalistic, commercial framing of code, this makes sense. If you think about all the projects you don't have time to make that require code but would be really cool albeit have no *marketable* value, making those faster to make and easy to share isn't a bad thing. I want more cool free things people make out of passion - sure, you could argue using AI removes some of that passion, but there's also a large subset of people who are passionate about their field but not passionate about code, and if they're able to make something cool by feeding the idea in and pulling the token generation slot machine's lever on repeat to get their vision, I still think that's cool. Of course, there's a line where it's slop, so it depends what they're making. A tool to make music? Cool. An album where it's all AI gen'd audio. Not cool. A tool to modify art/apply filters/modify brushes? Cool. AI art standalone? Not cool. Basically, is the target something standalone as a product we want to have human creativity in the output expression (art) or not. I don't think of MS office as particular artful, but I'm sure many good books have been written in it. This line is definitely blurry and full of gray areas. For example, https://www.redwoodrhetorica.com https://www.redwoodrhetorica.com to me is totally fine, but I could see why people find it weird. Similarly, I'm sure to someone working in or on emacs or vim, they're almost sacred and they view the tool itself as a work of art, such that the idea of using AI to improve either sounds offensive, but as long as VSCode works (which, it has had more bugs lately...) I really don't care if they used Claude or whatever to work on the editor/IDE itself. Of course, there are projects and features which probably shouldn't make it past the "Should this exist?" filter. Complexity does have a cost - nobody wanted CoPilot in Notepad - but having LLMs doesn't change that, I don't think. It means we can do more, but being selective and having good taste to avoid making something bad by adding unnecessary crap to it was a problem far before LLMs.

dbt00 3mo ago
This seems like you're arguing against something this post does not say.

casey2 3mo ago

There is still code you aren't writing. facepalm

dbalatero 3mo ago
I've personally seen way more of a bias to shipping something because "now it's free" without actually discussing whether it's worthwhile. "Just do it" and we'll measure it later. Often the later doesn't happen though. I think this article is a good reminder that applying taste and asking questions is still valuable, even if the code is considered to be cheaper.

deleted 3mo ago

[deleted]

overgard 3mo ago

Definitely agree with this. Even without a large backlog, one of the things I find working on my personal project/product where I'm simultaneously the engineer/designer/project manager is it's really easy to ask the LLM to implement an idea I've been mulling for an hour or two, it one-shots it and I'm happy, and then a week or two later it starts to dawn on me that the feature was maybe not a great idea. Which isn't on the LLM, but I know when I write features by hand I tend to reach the "this is a bad idea" conclusion a lot earlier because I'm directly confronted with the cases where it won't work out, I have to think a lot harder about corner cases, etc. Where I think/hope this goes is instead of using LLMs to go faster, we use them to do better work. I'd rather someone vibe code up better ways to test things, or use it to do in-depth code analysis and bug fixing, etc., then just pile in features.

skydhash 3mo ago
That’s why I usually starts with the simplest version of something I want, which is usually a shell or a perl script. When I nailed down my workflows and needs, that’s when I build a proper program. This is one of the reason I like cli programs. They’re like lego blocks for workflows. Same things with bigger projects. Write the most minimalistic version of a feature, and then ship it (or do a round of testing). Iterate based on feedback.
jfim 3mo ago
The good thing is since the feature was cheap to implement, you can just say "this was a bad idea" and remove it, as long as adding that feature wasn't a one way decision. People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do.
- kibwen 3mo ago
  > People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do. Careful. The sunk cost fallacy isn't just about time, it's also about money, and people may naturally be reluctant to remove bad features that cost them a lot of tokens, especially if the act of removal itself is going to cost even more tokens.

jordwest 3mo ago

From the title I thought this was gonna be about software (like MacOS updater) giving users an “Update now” and “Maybe later” option but no “don’t show this again”. I’m still holding out from upgrading to macOS 26 and it’s doing its absolute best to make me accidentally misclick to update

patcon 3mo ago

Doesn't this just mean we need to get better at the active deconstruction and disassembly process? Like it's too easy to build, so we build more things we realize later that we shouldn't. Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake". I'd much rather learn to live in the latter world. That world is based more on validated experience, and less on assumptions about a hypothetical future that hasn't yet been experienced. Of course, we will perhaps start to atrophe in our skills at projecting futures, which is a real concern. As in "what's the benefit of building robust mental models of the future when it makes more sense to YOLO through it and experience it the results directly?" It's all a little scary, to be honest. It turns a lot of the world on its head in many ways. Experientially tumbling into things with robust sensing processes... this is perhaps becoming more important than modelling futures in a judicious sense of economizing resources...

Swizec 3mo ago
> Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake" The hard part is that you very quickly become Salesforce or Jira or <insert large confusing product>. You have thousands of users who love your product and pay lots of money and find the features absolutely essential to their workflow. Everyone says your product is bloated and has too many useless features, if only you could delete a bunch of crap they don’t use your software would be perfect. They all use a different 20%. Delete a feature, lose a fifth of your users.
- patcon 3mo ago
  Great point. It's probably obvious from my take that I build a lot of bespoke software, and have blind spots about the pitfalls of building at scale :)

cortesoft 3mo ago

Sometimes it is, but sometimes it isn’t. I can remember plenty of times in my career there were some “nice to haves” that we didn’t get to, and not having them continued to waste our time over and over again as we kept putting it off. Time saving work for our software lifecycle that we spent so much time working around. Some of those things we finally did get to, and then spent the next few months wondering why we hadn’t don’t it before.

chickensong 3mo ago
Yeah, this right here. It's a cute and pithy blog post, but it's one-dimensional. Backlogs may have plenty of dead-ends, but there's just as likely the same amount of legit work that would be useful. For every company with a security breach, there's probably a related ticket that got pushed to the back burner because it wasn't part of the core product roadmap.
int_19h 3mo ago
+1, I can think of many things in my career that could have been that much better if we had the time and resources to do all the bells and whistles that we wanted.

lowbloodsugar 3mo ago

I guess that’s the difference between “maybe later” and YAGNI. YAGNI is a discipline.

block_dagger 3mo ago
One of the most important things I ever learned from a colleague was YAGNI. He would review my code and mark sections as YAGNI. I didn't know what it meant at the time. He kindly explained and since then I have been the teacher of that very important guideline.

staticshock 3mo ago

Everything is search. Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer. AI software development is more search. If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though. The world has been writing way more books than you'll ever read, recording more music you'll ever hear, filming more television shows than you'll ever get to watch, etc. A lot of it is garbage, but the good stuff stands the test of time and rises to the top, and I'd rather live in a thriving, flourishing world full of all these things, because there's more cream-of-the-crop when there's more everything. It's evolutionary fitness operating in the space of ideas. I agree that "maybe later" was indeed a useful mechanism, and maybe even a local optimum in the development methodology search space (which recently experienced a major earthquake!), but evolutionary pressure will bring it back into existence in some form sooner or later.

jaggederest 3mo ago
One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"
- apsurd 3mo ago
  I agree but the practical cost is most heavily paid in a collaborative work setting. Now everyone at all layers of a company is doing build prototype exploration but without the intermediary internal-filter check. Instead, these explorations get a straight line to production, for reasons I'm not exactly sure. Because it can I guess?
  - jaggederest 3mo ago
    Yeah that's where my eyebrows go to the moon. My investigations are at best in staging after a dev machine review, if nontech people are involved you need per-user cloud dev I think

gamerDude 3mo ago

I agree, but I think this is a skill in all parts of life. Some design has always been add, add, add. The skill to remove and simplify has always been valuable, but few do it. In weight loss, many people take the approach of add and it doesn't work. Do what you are doing now and take this pill or run further or do more. But mostly the secret is eat less. In design and engineering, it's often removing things instead of overcomplicating them. In communication, it's often, remove lots of your side points and just focus on your core argument. We may have removed a constraint that allows people to do more, but the skill has always been to choose, prioritize and remove the things that are making it worse

oxag3n 3mo ago

Was invented long, long time ago. I first learned formal definition as "part count reduction" fromm Design for Manufacturing (DFM).

andai 3mo ago

They say the fastest code is the code that never runs. This is true. But actually, this principle generalizes. The most correct code is the code that doesn't run. There are no security vulnerabilities in code that doesn't exist. It fails no tests. There are no bugs hiding within it. It requires no documentation. (And doesn't get out of sync!) It incurs no maintenance burden. The best code is no code.

greatgib 3mo ago

"4 years later it's clear that those backlog features would not have helped at all. It is a good thing they never got built." To me, it is a survivor bias. How could you know where you would have been now if you built these features of your backlog 4 years ago? Maybe some things would have been easier and faster, maybe you would have been bigger, got more customers and money. Maybe you would have done a big breakthrough that would have transformed your project into something different and better. Or maybe it would have been exactly the same, or worst, or would have led you to bankruptcy. Maybe there is a security hole that you did well to not spend time fixing because no one abused of it (...yet), or maybe some hackers could have leaked all your customer base to some random forum killing your company because of this missing fix. The outcome is unsure, but you can't easily consider as a generality that you had not needed them.