Hacker News new | ask | show | jobs
by zahlman 22 days ago
For a project like this, relying on AI assistance also makes it effectively dead in the water.
3 comments

Why?
Time-cost for machines instead of willing knowledgeable humans. The former requires money, the latter requires passion.

Arguably, passion for a project is without price.

Someone pays for the AI? That's the new human maintainer.
Who will pay if someone, somewhere is not passionate about it?
You can spin up a model locally and pay yourself. Who will maintain the project if the passionate sole maintainer burns out?
I strictly use only local models, so I agree, but the project was built with Fable so my argument hinges on the assumption that the maintainer is going to continue using Fable and needs to pay for it.
Which model works well?
Hypothetically, maybe. In practice, probably not.
If it's valuable enough to someone, and it isn't keeping up, someone will pay. If it's not valuable enough for someone to pay, then who cares?
Plenty of important things have been born of passion without necessity.
Humans have time-cost too, much higher than machines. Considering SOTA right now, for a project like this it would make more sense for the community to contribute and verify tests, sponsor updates with $.
Trust
Not convinced. I was looking for an answer like "it doesn't actually have parity with CPython." If it does, that's a decent indication that it can be sustained.
Good luck implementing and then maintaining a project of this size and complexity at ~100 lines of verified code per human developer per day.
I wonder how you arrived at that number. Is it perhaps a number that we should aspire to, if we want to write high-quality, maintainable code by hand?
I've been doing some reading recently around what the literature expects a professional software engineer to produce in a day.

In ~1976 Mythical Man Month era it was around 5 lines of fully debugged assembly.

Code Complete 2nd edition ~2004 bumped that up to 10-50 delivered lines of code per day.

I found other estimates of around 20-60. I need to pull them altogether into a cited article.

Based on that plus my own experience I think 100 lines per day of production-level, reviewed and debugged code was a reasonably higher target for a professional software engineer up until just a couple of years ago.

Today I'm frequently pushing 2,000 to 4,000 - and that's not vibe coded junk (I can easily hit 10,000+ if I'm not reviewing anything), that's code that I've reviewed and am happy to put my name to.

Obviously counting lines of code is a stupid, easily gamed metric. But I still think there's signal there. If you want to build a sophisticated piece of software you're going to have to write a bunch of code to do it. Writing at 1,000+ lines of code per day vs 100 will get you there faster.