"I can also write lines of code for free. I have the same superpowers you do..."
Boy oh boy can I tell that people have still not internalized this. Yes, your HTTP proxy with a list of features as long as my arm would have been impressive 5 years ago, at least on some level. Today, I can prompt it into existence as easily as you did, and if I am prompting it into existence I can build a custom one with just the features I need, that integrates into my logging & metrics, etc., and perhaps most importantly, I can literally do that more quickly than I can evaluate your project. AI has eliminated the space of open source projects where evaluation of your project takes longer than prompting it into existence does for me.
The premise of this argument is that using AI takes no skill, and experience using AI doesn't matter, and that domain expertise in software development won't help you build better software with AI.
I think you'll find most of the people creating the HTTP proxy servers and brand new AI harnesses and git or ssh config managers and all of the other things that we already have way too many versions of are not our best software engineers anyhow. I like to analyze things in terms of how much of the real world they've encountered [1], and one of the reasons I would just put my own solutions together is a lot of these manifested major projects with huge lists of "features" have either one user, or in many cases, zero, which is to say even the author isn't actually using it, and I might as well put together my 1-user project myself.
Right after I posted, I realized this hole in what I was saying.
Reflecting a bit more, I agree with you, but only in cases where the author of the open source project doesn't aggressively shun the use of AI in their own work. Folks that refuse to engage with AI (even open source project maintainers) will find themselves lacking the skill with AI that others have. So I can imagine a future where those open-source maintainers will get pull requests written with AI that they themselves could never produce.
I'm not sure I believe my own argument here, but I think it follows from "using AI to produce something worthwhile is a skill".
What about the price to verify your newly borne vibe coded project. At least the person who published it has a chance to have used their project to valid/solve their own problem and then was nice enough to publish it back to be freely used vs costing $10 to prompt it into existence
I feel that doing the job with the fewest lines of code, is best.
I also believe in focused/pure scope. If I write a type or API to do a job, then it should do that job, and only that job. If I want to add functionality that is out-of-scope, then I’ll often write another type, instead of adding it to the existing one. Making this type of decision is always fraught.
But, like in all things, it depends. Sometimes, reducing the overhead of things like setup and testing is a good reason to not introduce a whole new resource, but I should make it a point to document the reason for the incongruity.
This is especially true, when designing user interface. I’ve found that, usually (not all the time, though), less is more.
Josef Albers is known (amongst other things), for the quote “Sometimes, in design, one plus one is three or more.”.
> I feel that doing the job with the fewest lines of code, is best.
And that is one of my gripes with AI models and code. They are so, so verbose. It's a nightmare.
"Why don't you let AI implement that small feature, it will be faster.", they would ask.
Well, because if do, it will completely pollute my carefully crafted interface that I kept small, simple and understandable for easier maintenance and extension.
And yes, I might spare a few hours by having _it_ work for me. But then I need to spend a more hours to clean-up the code noise and complexification.
Sorry for having polluted the conversation by bringing AI in, when for once, ironically, it was not about AI.. I needed to vent, while fully approving of your take.
It started, by giving me a 2,500-line (about 50% documentation) viewcontroller that ate so much memory that the app would jetsam after the user just did a couple of things.
I then, spent about a week, tracking down memory issues, until we narrowed it down to the MapKit cache. All this time, the LLM was making the code scarier and scarier. It was exactly what I would expect from an inexperienced (but smart) engineer, panicking, and adding more and more cruft.
The LLM ended up suggesting fixes that didn’t work that well, and made the UI janky. Also, it was terrifyingly delicate. I don't think it would have survived one feature request.
By now, the viewcontroller was over 4,000 lines.
I asked the LLM to refactor for redundancy, quality, and size.
It removed all the documentation and logging, reducing the size back to about 2,500 lines (about 1% documentation).
Yay.
Except all of the bush-league threading and awful workaround shit was still in there, but now impossible to understand.
At this point, I gave up, threw out the LLM code, and rewrote the viewcontroller from scratch. Took a day and a half. I figured out how to force MapKit to flush its cache (2 lines of code). It's a well-known issue, and the solution was the first StackOverflow answer that showed up in the search.
It’s currently about 1,400 lines (about 50% is documentation), and works great.
> It removed all the documentation and logging, reducing the size to about 2,500 lines. [..] but now impossible to understand.
Nice. Lol.
> At this point, I gave up, threw out the LLM code, and rewrote the code. It’s currently about 1,400 lines (about 50% is documentation), and works great.
I've had similar experiences. But I must be "holding it wrong", judging by all the other articles on HN..
I get the impression that your takeaway is not to use LLMs, but I think your takeaway should be to give them more oversight. The way you describe this, it sounds like you went pure vibe coding.
> I asked the LLM to refactor for redundancy, quality, and size.
What did you expect when you asked it to make it smaller?
I’ve had good success with LLM refactoring. But the refactoring has never been “go make this better and smaller”. It’s “go do this specific thing to reduce redundancy” or maybe “give me a list of ways to improve the code redundancy” and then iterate with the LLM to improve the ideas and execute on the right ones.
I don’t think you can just vibe code your way out of a vibe coded mess.
No, my takeaway is the same as with working with any other developer.
If I take responsibility for the product, then I can't afford to accept sub-standard input; no matter the source. My main mistake was not immediately putting the kibosh on the LLM, as soon as it started thrashing. Instead, I played along, for waaaayyyy too long.
The request for refactoring was actually a fairly long and detailed prompt. I can't recall it exactly, but by that time, the context was well and truly poisoned. The LLM had decided that its way was best, and could not be persuaded, otherwise.
The same goes for humans, in a similar situation. I've encountered almost the exact same behavior, many times.
I am quite aware that my personal standards tend to be a lot tougher than what seems to be the norm, these days, so I am willing to admit that I may be demanding too much, but that's how I was trained.
But I have been making extensive use of LLMs, for the last few months, and they have been incredibly helpful. The Rubicon has been crossed. There's no going back, but I also need to make sure that I don't get drunk on Kool-Aid. LLMs are still very much a WiP.
I evaluate how good models are now by how good they are at removing code.
It’s fairly simple (assuming the test harness and agents.md are well written): do iterations of trying to remove code, ensure it passes, then have a human review it. Less code to review that way.
He recently was working on optimizing Quickdraw's region calculation
machinery, and had completely rewritten the region engine using a simpler,
more general algorithm which, after some tweaking, made region operations
almost six times faster. As a by-product, the rewrite also saved around 2,000
lines of code.
He was just putting the finishing touches on the optimization when it was
time to fill out the management form for the first time. When he got to the
lines of code part, he thought about it for a second, and then wrote in the
number: -2000.
Something I'll call Milito's Meadow [1]. Start with a clean slate. Everything goes: fences, farmhouses, roads… Down to the bare earth.
Then build up again from scratch. Likely you will in fact put a fence here or there—but of course you'll know with certainty why it is there. (And more times than not, there will be fewer fences when you are done.)
[1] Naming this for a friend who taught me about fence razing.
To rephrase in the language of this conversation, he answers: why are there all those fences there?
> I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
(Yes the references are a bit out of date. The article is from over 25 years ago!)
Actually, I think the old references are relevant. Sometimes those bug fixes and workarounds no longer matter. Windows 95 and Internet Explorer are long gone, we don’t need to architect our code base any longer to support them, but everyone’s petrified to remove the support for them.
Or in the language of fences, the fence might’ve been built for a herd of cattle that no longer exists. Raze away!
Right. Chesterton's fence isn't "never remove a fence". It's "understand why it's there before you remove it". If you look and find out it's for a long-unsupported platform, go for it.
In practice, a mature codebase is likely to have a mix of now-useless warts and seemingly useless but actually essential elements, along with some that fall in the middle (most often, in my experience: attempts to fix valid issues but in a way that no longer makes sense).
Look at it as a house (which already exists). There will be defects. Some big, some small. Some obvious, some hidden.
Maybe the exterior looks bad, but the interior is fine. Give it a paintjob.
Maybe it could use a new kitchen but otherwise it's fine. Do the kitchen.
Maybe it's fine but the family living in it could use some storage space. Add an extension or put up a shed.
Or maybe its foundations are crumbling, walls are cracked, roof is leaking everywhere, doors are slanted, and thieves ripped out all the copper piping. Tear it down & rebuild (developers seem to prefer this option).
But your job is not to follow the same approach wherever you go. It's to have a good look around, get a feel for the place, and decide what should stay & what needs fixing.
That can include fundamental design aspects. Why was it built that way? Is it time to port to a new platform?
Joel Spolsky wasn't wrong either. Re-developing a sizeable project is a big job, and comes with significant risk for its users. But the metrics have changed.
LLMs have reduced the cost of rebuilding a lot. Not the risks. Choose wisely.
Haven’t there been successful rewrites of nontrivial applications? I’ve always been skeptical of Joel’s Netscape example. Was the rewrite really the mistake? Couldn’t the mistake have been making an application where no one knows how it’s supposed to behave?
I'll admit the example is a bit sketchy. My dim memory is that Netscape's mistake was that their business model was charging for their product, which is not unreasonable but was doomed when Microsoft gave Internet Explorer away for free and included it in Windows (so you'd really have to go out of your way to find Netscape's paid alternative).
That essay really shook me into understanding things I had never thought of, and I've been better at my job ever since.
I remain grateful to Joel for the insights!
In 2026, test suites can and should handle much of this uncertainty. If Nancy wrote a good test for her fix, we can rewrite and refactor with much less fear and risk.
A ground-up rebuild can be wonderful, but something is lost in those US plaster-planned cities that attempt to imitate Florence or other EU cities; something about organic growth that is very hard to replicate ex-nihilo.
Some open source projects use PRs as an inspiration machine and just reimplement the feature themselves if they like it. I think that’s entirely sound and as a user I prefer that.
But also as a user I fork them for personally desired changes. Even keeping everything working with upstream is low cost these days.
Related to this, the concept of "free as in puppies" from D. Richard Hipp, creator of SQLite:
> Suppose you had a pull request for SQLite. "Hey, I've got this new feature for SQLite. Here's the pull request." When you want me to pull that into the tree, you say, "Oh, it's free."
> No, it's not free. What you're doing is asking me - you've got this cool feature, and you want me to maintain it for you, to document it for you, to test it for you, to maintain it for you for the next twenty-five years. That's not free.
> Linus Torvalds is famous for saying there's free as in beer and free as in speech. But there's another kind of freedom: free as in puppies. "Oh look, I've got a free puppy for you." You see where this is going?
> A pull request is a free puppy. And then you've just got a kennel full of puppies at the end of the day. And you can't just throw them out - you're morally obligated to take care of them for their natural life.
Thanks! This is very similar indeed. Related: I see a lot of “drive-by” PRs by agents, who obviously have no intent of ever maintaining the code they wrote.
It's hard to predict what parts of shared understanding we have today is going to be scarce tomorrow. And one can't serialize _all_ of that current shared understanding in documents and integration tests.
Advocates of Chesterton’s Fence tend to miss that they’re applying selective pressure to favor systems that fail to document (or outright obscure) their purpose.
Of course, the much more obvious flaw of Chesterton’s Fence is that it trivially reduces to status quo bias.
I don't think you've understood the lesson here. Chesterton's fence is not about keeping systems in place. It is about how you approach changing the system.
The counterpoint is that building software is not building a fence. When you create something in software, nothing tangible changes until that's accepted and running on all the places that you deploy to. A PR is just a hey, here's a fence that the contributor built elsewhere that proves that building something like this is possible.
The corollary is design your open source libraries so they're obvious enough that the chesterton's gaps are obvious. Anytime an AI tool submits something that breaks your expectation of things not being necessary it usually highlights that there's a missing gap in the explanation of what is necessary.
I’m not sure I share your view of PRs. I still see submitting PRs as something that puts pressure on maintainers. Even incorrect PRs take time to verify and review.
I also don’t see how this differs between the “gap” and the “fence” part of the metaphor. Whether someone submits a rewrite/removal (fence) or a new feature (gap) for PR review, it’s still going to cost me attention.
It's only pressure if you believe the social contract in a PR is that everything that is written is something you're obligated to read / respond to. If you flip that a bit to a PR being the first step in a way of saying "I tried a thing and it worked, what's necessary to make that an actual thing that other can use", then you will sort of land here.
"I can also write lines of code for free. I have the same superpowers you do..."
Boy oh boy can I tell that people have still not internalized this. Yes, your HTTP proxy with a list of features as long as my arm would have been impressive 5 years ago, at least on some level. Today, I can prompt it into existence as easily as you did, and if I am prompting it into existence I can build a custom one with just the features I need, that integrates into my logging & metrics, etc., and perhaps most importantly, I can literally do that more quickly than I can evaluate your project. AI has eliminated the space of open source projects where evaluation of your project takes longer than prompting it into existence does for me.
The premise of this argument is that using AI takes no skill, and experience using AI doesn't matter, and that domain expertise in software development won't help you build better software with AI.
I don't think any of those things are true.
I think you'll find most of the people creating the HTTP proxy servers and brand new AI harnesses and git or ssh config managers and all of the other things that we already have way too many versions of are not our best software engineers anyhow. I like to analyze things in terms of how much of the real world they've encountered [1], and one of the reasons I would just put my own solutions together is a lot of these manifested major projects with huge lists of "features" have either one user, or in many cases, zero, which is to say even the author isn't actually using it, and I might as well put together my 1-user project myself.
[1]: https://jerf.org/iri/post/2026/what_value_code_in_ai_era/
A person maintaining a sizeable open-source project is overwhelmingly likely to have all three.
Right after I posted, I realized this hole in what I was saying.
Reflecting a bit more, I agree with you, but only in cases where the author of the open source project doesn't aggressively shun the use of AI in their own work. Folks that refuse to engage with AI (even open source project maintainers) will find themselves lacking the skill with AI that others have. So I can imagine a future where those open-source maintainers will get pull requests written with AI that they themselves could never produce.
I'm not sure I believe my own argument here, but I think it follows from "using AI to produce something worthwhile is a skill".
Yes, that's precisely the thought which lead me to the "overwhelmingly likely" hedging.
I think the argument is more that jerf has that skill, experience, and domain expertise.
So why submit a PR at all if you're not even going to try to understand the aims of the project?
What about the price to verify your newly borne vibe coded project. At least the person who published it has a chance to have used their project to valid/solve their own problem and then was nice enough to publish it back to be freely used vs costing $10 to prompt it into existence
I’ve found utility in removing code.
I feel that doing the job with the fewest lines of code, is best.
I also believe in focused/pure scope. If I write a type or API to do a job, then it should do that job, and only that job. If I want to add functionality that is out-of-scope, then I’ll often write another type, instead of adding it to the existing one. Making this type of decision is always fraught.
But, like in all things, it depends. Sometimes, reducing the overhead of things like setup and testing is a good reason to not introduce a whole new resource, but I should make it a point to document the reason for the incongruity.
This is especially true, when designing user interface. I’ve found that, usually (not all the time, though), less is more.
Josef Albers is known (amongst other things), for the quote “Sometimes, in design, one plus one is three or more.”.
> I’ve found utility in removing code.
> I feel that doing the job with the fewest lines of code, is best.
And that is one of my gripes with AI models and code. They are so, so verbose. It's a nightmare.
"Why don't you let AI implement that small feature, it will be faster.", they would ask.
Well, because if do, it will completely pollute my carefully crafted interface that I kept small, simple and understandable for easier maintenance and extension.
And yes, I might spare a few hours by having _it_ work for me. But then I need to spend a more hours to clean-up the code noise and complexification.
Sorry for having polluted the conversation by bringing AI in, when for once, ironically, it was not about AI.. I needed to vent, while fully approving of your take.
I just had to rewrite a screen written by an LLM.
It started, by giving me a 2,500-line (about 50% documentation) viewcontroller that ate so much memory that the app would jetsam after the user just did a couple of things.
I then, spent about a week, tracking down memory issues, until we narrowed it down to the MapKit cache. All this time, the LLM was making the code scarier and scarier. It was exactly what I would expect from an inexperienced (but smart) engineer, panicking, and adding more and more cruft.
The LLM ended up suggesting fixes that didn’t work that well, and made the UI janky. Also, it was terrifyingly delicate. I don't think it would have survived one feature request.
By now, the viewcontroller was over 4,000 lines.
I asked the LLM to refactor for redundancy, quality, and size.
It removed all the documentation and logging, reducing the size back to about 2,500 lines (about 1% documentation).
Yay.
Except all of the bush-league threading and awful workaround shit was still in there, but now impossible to understand.
At this point, I gave up, threw out the LLM code, and rewrote the viewcontroller from scratch. Took a day and a half. I figured out how to force MapKit to flush its cache (2 lines of code). It's a well-known issue, and the solution was the first StackOverflow answer that showed up in the search.
It’s currently about 1,400 lines (about 50% is documentation), and works great.
Lesson learned.
> It removed all the documentation and logging, reducing the size to about 2,500 lines. [..] but now impossible to understand.
Nice. Lol.
> At this point, I gave up, threw out the LLM code, and rewrote the code. It’s currently about 1,400 lines (about 50% is documentation), and works great.
I've had similar experiences. But I must be "holding it wrong", judging by all the other articles on HN..
I get the impression that your takeaway is not to use LLMs, but I think your takeaway should be to give them more oversight. The way you describe this, it sounds like you went pure vibe coding.
> I asked the LLM to refactor for redundancy, quality, and size.
What did you expect when you asked it to make it smaller?
I’ve had good success with LLM refactoring. But the refactoring has never been “go make this better and smaller”. It’s “go do this specific thing to reduce redundancy” or maybe “give me a list of ways to improve the code redundancy” and then iterate with the LLM to improve the ideas and execute on the right ones.
I don’t think you can just vibe code your way out of a vibe coded mess.
No, my takeaway is the same as with working with any other developer.
If I take responsibility for the product, then I can't afford to accept sub-standard input; no matter the source. My main mistake was not immediately putting the kibosh on the LLM, as soon as it started thrashing. Instead, I played along, for waaaayyyy too long.
The request for refactoring was actually a fairly long and detailed prompt. I can't recall it exactly, but by that time, the context was well and truly poisoned. The LLM had decided that its way was best, and could not be persuaded, otherwise.
The same goes for humans, in a similar situation. I've encountered almost the exact same behavior, many times.
I am quite aware that my personal standards tend to be a lot tougher than what seems to be the norm, these days, so I am willing to admit that I may be demanding too much, but that's how I was trained.
But I have been making extensive use of LLMs, for the last few months, and they have been incredibly helpful. The Rubicon has been crossed. There's no going back, but I also need to make sure that I don't get drunk on Kool-Aid. LLMs are still very much a WiP.
I evaluate how good models are now by how good they are at removing code.
It’s fairly simple (assuming the test harness and agents.md are well written): do iterations of trying to remove code, ensure it passes, then have a human review it. Less code to review that way.
I think when somebody trains code golfing LLMs with reinforcement learning they will inadvertently be smarter
> removing code
Cue link to Negative 2,000 LoC [0]:
0. https://www.folklore.org/Negative_2000_Lines_Of_Code.htmlSomething I'll call Milito's Meadow [1]. Start with a clean slate. Everything goes: fences, farmhouses, roads… Down to the bare earth.
Then build up again from scratch. Likely you will in fact put a fence here or there—but of course you'll know with certainty why it is there. (And more times than not, there will be fewer fences when you are done.)
[1] Naming this for a friend who taught me about fence razing.
This is addressed by the classic article by Joel on Software (which is apt, as it's a classic mistake):
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
To rephrase in the language of this conversation, he answers: why are there all those fences there?
> I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
(Yes the references are a bit out of date. The article is from over 25 years ago!)
Actually, I think the old references are relevant. Sometimes those bug fixes and workarounds no longer matter. Windows 95 and Internet Explorer are long gone, we don’t need to architect our code base any longer to support them, but everyone’s petrified to remove the support for them.
Or in the language of fences, the fence might’ve been built for a herd of cattle that no longer exists. Raze away!
Right. Chesterton's fence isn't "never remove a fence". It's "understand why it's there before you remove it". If you look and find out it's for a long-unsupported platform, go for it.
In practice, a mature codebase is likely to have a mix of now-useless warts and seemingly useless but actually essential elements, along with some that fall in the middle (most often, in my experience: attempts to fix valid issues but in a way that no longer makes sense).
> which is apt, as it's a classic mistake
Was.
Look at it as a house (which already exists). There will be defects. Some big, some small. Some obvious, some hidden.
Maybe the exterior looks bad, but the interior is fine. Give it a paintjob.
Maybe it could use a new kitchen but otherwise it's fine. Do the kitchen.
Maybe it's fine but the family living in it could use some storage space. Add an extension or put up a shed.
Or maybe its foundations are crumbling, walls are cracked, roof is leaking everywhere, doors are slanted, and thieves ripped out all the copper piping. Tear it down & rebuild (developers seem to prefer this option).
But your job is not to follow the same approach wherever you go. It's to have a good look around, get a feel for the place, and decide what should stay & what needs fixing.
That can include fundamental design aspects. Why was it built that way? Is it time to port to a new platform?
Joel Spolsky wasn't wrong either. Re-developing a sizeable project is a big job, and comes with significant risk for its users. But the metrics have changed.
LLMs have reduced the cost of rebuilding a lot. Not the risks. Choose wisely.
Haven’t there been successful rewrites of nontrivial applications? I’ve always been skeptical of Joel’s Netscape example. Was the rewrite really the mistake? Couldn’t the mistake have been making an application where no one knows how it’s supposed to behave?
I'll admit the example is a bit sketchy. My dim memory is that Netscape's mistake was that their business model was charging for their product, which is not unreasonable but was doomed when Microsoft gave Internet Explorer away for free and included it in Windows (so you'd really have to go out of your way to find Netscape's paid alternative).
That essay really shook me into understanding things I had never thought of, and I've been better at my job ever since.
I remain grateful to Joel for the insights!
In 2026, test suites can and should handle much of this uncertainty. If Nancy wrote a good test for her fix, we can rewrite and refactor with much less fear and risk.
A ground-up rebuild can be wonderful, but something is lost in those US plaster-planned cities that attempt to imitate Florence or other EU cities; something about organic growth that is very hard to replicate ex-nihilo.
This likely doesn’t correlate to code as much.
Extreme programming in a nutshell. I like doing this to features: build it, then take it down and rebuild but better.
"Plan to throw one away. You will anyway."
Reminds me of Ackoff’s Idealised Design [1]
[1] https://en.wikipedia.org/wiki/Interactive_planning#Idealized...
Unfortunately, before the fences are down you are in jail, and with you, it stays where it was.
Sounds like a very expensive and time-consuming way to build something that won't work very well for a while. Is that the point?
It takes technical debt head-on?
Some open source projects use PRs as an inspiration machine and just reimplement the feature themselves if they like it. I think that’s entirely sound and as a user I prefer that.
But also as a user I fork them for personally desired changes. Even keeping everything working with upstream is low cost these days.
Related to this, the concept of "free as in puppies" from D. Richard Hipp, creator of SQLite:
> Suppose you had a pull request for SQLite. "Hey, I've got this new feature for SQLite. Here's the pull request." When you want me to pull that into the tree, you say, "Oh, it's free."
> No, it's not free. What you're doing is asking me - you've got this cool feature, and you want me to maintain it for you, to document it for you, to test it for you, to maintain it for you for the next twenty-five years. That's not free.
> Linus Torvalds is famous for saying there's free as in beer and free as in speech. But there's another kind of freedom: free as in puppies. "Oh look, I've got a free puppy for you." You see where this is going?
> A pull request is a free puppy. And then you've just got a kennel full of puppies at the end of the day. And you can't just throw them out - you're morally obligated to take care of them for their natural life.
> I don't want any free puppies.
source: https://youtu.be/x8_ZZhRL3YU?t=1715
It's normally been called a "white elephant" but this framing is a perfect completion to Torvalds' previously-two-part troika.
Thank you for sharing it!
Thanks! This is very similar indeed. Related: I see a lot of “drive-by” PRs by agents, who obviously have no intent of ever maintaining the code they wrote.
Puppy cannons. Puppy carpet bombing.
A new definition of "puppy mill."
Puppy slush automatically pushed through vents into your codebase
FYI there are quite a few glitches in there:
> and want you want me to maintain it for you
> to to document it for you
> Linus Torvalds is famous famous
> A pool request
> They're you you're you're morally obligated
Thank you, I was too eager copy-pasting YT transcriptions.
It’s refreshing to read something not run though an LLM to make it look plausible first.
Whoever built the fence should have put a sign on it saying why.
Oh, and integration tests to check that the problem doesn't recur when the fence is replaced.
Context is that which is scarce.
It's hard to predict what parts of shared understanding we have today is going to be scarce tomorrow. And one can't serialize _all_ of that current shared understanding in documents and integration tests.
https://marginalrevolution.com/marginalrevolution/2021/12/co...
Advocates of Chesterton’s Fence tend to miss that they’re applying selective pressure to favor systems that fail to document (or outright obscure) their purpose.
Of course, the much more obvious flaw of Chesterton’s Fence is that it trivially reduces to status quo bias.
I don't think you've understood the lesson here. Chesterton's fence is not about keeping systems in place. It is about how you approach changing the system.
The counterpoint is that building software is not building a fence. When you create something in software, nothing tangible changes until that's accepted and running on all the places that you deploy to. A PR is just a hey, here's a fence that the contributor built elsewhere that proves that building something like this is possible.
The corollary is design your open source libraries so they're obvious enough that the chesterton's gaps are obvious. Anytime an AI tool submits something that breaks your expectation of things not being necessary it usually highlights that there's a missing gap in the explanation of what is necessary.
I’m not sure I share your view of PRs. I still see submitting PRs as something that puts pressure on maintainers. Even incorrect PRs take time to verify and review.
I also don’t see how this differs between the “gap” and the “fence” part of the metaphor. Whether someone submits a rewrite/removal (fence) or a new feature (gap) for PR review, it’s still going to cost me attention.
It's only pressure if you believe the social contract in a PR is that everything that is written is something you're obligated to read / respond to. If you flip that a bit to a PR being the first step in a way of saying "I tried a thing and it worked, what's necessary to make that an actual thing that other can use", then you will sort of land here.
Previously I wrote https://news.ycombinator.com/item?id=48517931
Saying your quoted words is a request for someone to read and respond; it's still pressure and a burden.
I wouldn’t have thought that black text on a lavender background would make for pleasing reading, but it was actually quite nice.
I probably would have agreed 50 years ago, but it's a bit hard now. Fortunately, select-all boosted the contrast nicely. ;)
Ha thanks, it was pink a while ago