5 ms·

It is always "I'm producing 300 projects in a nanosecond" but it's almost never about sharing or actually deploying these ;)

by gloosx 10mo ago

DoctorOW 10mo ago
The problem I had that the larger your project gets, the more mistakes Claude makes. I (not a parent commenter) started with a basic CRUD web app and was blown away by how detailed it was, new CSS, good error handling, good selection and use of libraries, it could even write the terminal commands for package management and building. As the project grew to something larger Claude started forgetting that some code already existed in the project and started repeating itself, and worse still when I asked for new features it would pick a copy at random leaving them out of sync with eachother. Moving forward I've been alternating between writing stuff with AI, then rewriting it myself.
- cpursley 10mo ago
  So, just like a human on a growing codebase?
- HarHarVeryFunny 10mo ago
  > The problem I had that the larger your project gets, the more mistakes Claude makes I think the reason for this is because these systems get all their coding and design expertise from training, and while there is lots of training data available for small scale software (individual functions, small projects), there is much less for large projects (mostly commercial and private, aside from a few large open source projects). Designing large software systems, both to meet initial requirements, and to be maintainable and extensible over time, is a different skill than writing small software projects, which is why design of these systems is done by senior developers and systems architects. It's perhaps a bit like the difference between designing a city and designing a single building - there are different considerations and decisions being made. A city is not just a big building, or a collection of buildings, and large software system is not just a large function or collection of functions.
  - chrisweekly 10mo ago
    Well said, and good analogy.
  - commakozzi 10mo ago
    Yeah, great analogy. Thanks!
- delaminator 10mo ago
  I’ve got Claude on 10k loc projects, which is probably mid range. But I also have it document and summarise its own work.
  - collinmanderson 10mo ago
    > I also have it document and summarise its own work. Could you share some of your prompts or CLAUDE.md? I'm still learning what works.
- adastra22 10mo ago
  Have it produce CLAUDE.md files in every directory giving a summary of what code is where, and a system directive to keep these updated.
freehorse 10mo ago
At this point my prior is that all these 300/ns projects are some kind of internal tools, with very narrow scope and many just for a one-off use. Which is also fine and great and very useful and I am also making those, but it probably does not generalize to projects that require higher quality standards and actual maintenance.
- delaminator 10mo ago
  Sure, but 80% of software is probably internal and short lived like that, if not more. Solving the problems of the business that isn’t a software business.
  - everforward 10mo ago
    Places that aren't software businesses are usually the inverse. The software is extremely sticky and will be around for ages, and will also bloat to 4x the features it was originally supposed to have. I worked at an insurance company a decade ago and the majority of their software was ancient. There were a couple desktops in the datacenter lab running Windows NT for something that had never been ported. They'd spent the past decade trying to get off the mainframe and a majority of requests still hit the mainframe at some point. We kept versions of Java and IBM WebSphere on NFS shares because Oracle or IBM (or both) wouldn't even let us download versions that old and insecure. Software businesses are way more willing to continually rebuild an app every year.
properbrew 10mo ago
I also see a lot of this so I can't blame you for thinking it! See my other post about some projects build _only_ using LLMs. https://news.ycombinator.com/item?id=46133458 https://news.ycombinator.com/item?id=46133458
sahn44 10mo ago
Here's mine fully deployed, https://hackernewsanalyzer.com/ https://hackernewsanalyzer.com/. I use it daily and have some users. ~99.7% LLM code. About 1 hour to first working prototype then another 40 hours to get it polished and complete to current state.
- beepbooptheory 10mo ago
  To be clear, roughly 39.8 hours of just prompting and output to make this website?
  - sahn44 10mo ago
    41 hours total of prompting, looking at code diffs, reverting, reprompting, and occasional direct code commits. I do review the full code changes nearly every step of the way and often iterate numerous times until I'm satisfied with the resulting code approach.
    - beepbooptheory 10mo ago
      Have you tried to go back to the old way, maybe just as an experiment, to see how much time you are actually saving? You might be a little surprised! Significant "reprompting" time to me indicates maybe a little too much relying on it rather than leading by example. Things are much faster in general if you find the right loop of maybe using Claude for like 15%-20% of stuff instead of 99.7%. You wouldn't give your junior 99.7% ownership of the app unless they were your only person, right? I find spending time thinking through certain things by hand will make you so much more productive, and the code will generally be much better quality. I get that like 3 years ago we were all just essentially proving points building apps completely with prompts, and they make good blog subjects maybe, but in practice they end up being either fragile novelties or bloated rat's nests that end up taking more time not less.
      - adastra22 10mo ago
        I’ve done things in days that in the before times would have took me months. I don’t see how you can make that time difference up. I have at least one project where I can make that direct comparison - I spent three months writing something in the language I’ve done most of my professional career in, then as a weekend project I got ChatGPT to write it from scratch in a different language I had never used before. That was pre-agentic tools - it could probably be done in an afternoon now.
staticassertion 10mo ago
There's a massive incentive not to share them. If I wrote a project using AI I'd be reluctant to publish it at all because of the backlash I've seen people get for it.
- aenis 10mo ago
  People are and always were reluctant to share their own code just the same. There is nothing to be gained, the chances of getting positive reviews from fellow engineers are slim to none. We are a critical and somewhat hypocritical bunch on average.
__MatrixMan__ 10mo ago
If you haunt the pull requests of projects you use I bet you'll find there's a new species of PR: > I'm not an expert in this language or this project but I used AI to add a feature and I think its pretty good. Do you want to use it? I find myself writing these and bumping into others doing the same thing. It's exciting, projects that were stagnant are getting new attention. I understand that a maintainer may not want to take responsibility for new features of this sort, but its easier than ever to fork the project and merge them yourself. I noticed this most recently in https://github.com/andyk/ht/pulls https://github.com/andyk/ht/pulls which has two open (one draft) PRs of that sort, plus several closed ones. Issues that have been stale for years are getting traction, and if you look at the commit messages, it's AI tooling doing the work. People feel more capable to attempt contributions which they'd otherwise have to wait for a specialist for. We do need to be careful not to overwhelm the specialists with such things, as some of them are of low quality, but on the whole it's a really good thing. If you're not noticing it, I suggests hanging out in places where people actually share code, rather than here where we often instead brag about unshared code.
- filoeleven 10mo ago
  > People feel more capable to attempt contributions That does not mean that they are more capable, and that's the problem. > We do need to be careful not to overwhelm the specialists with such things, as some of them are of low quality, but on the whole it's a really good thing. That's not what the specialists who have to deal with this slop say. There have been articles about this discussed here already.
  - __MatrixMan__ 10mo ago
    What would you have us do, Keep the fixes to ourselves?
    - eschaton 10mo ago
      Yes, keep AI slop “fixes” to yourself and only create PRs for your own work.
delaminator 10mo ago
I came with receipts
JackSlateur 10mo ago
Building something is easy Building something that works ? Not so easy Pushing that thing in production ? That the hardest part

It is always "I'm producing 300 projects in a nanosecond" but it's almost never about sharing or actually deploying these ;)

by gloosx 10mo ago

It is always "I'm producing 300 projects in a nanosecond" but it's almost never about sharing or actually deploying these ;)

DoctorOW 10mo ago

The problem I had that the larger your project gets, the more mistakes Claude makes. I (not a parent commenter) started with a basic CRUD web app and was blown away by how detailed it was, new CSS, good error handling, good selection and use of libraries, it could even write the terminal commands for package management and building. As the project grew to something larger Claude started forgetting that some code already existed in the project and started repeating itself, and worse still when I asked for new features it would pick a copy at random leaving them out of sync with eachother. Moving forward I've been alternating between writing stuff with AI, then rewriting it myself.

cpursley 10mo ago
So, just like a human on a growing codebase?
HarHarVeryFunny 10mo ago
> The problem I had that the larger your project gets, the more mistakes Claude makes I think the reason for this is because these systems get all their coding and design expertise from training, and while there is lots of training data available for small scale software (individual functions, small projects), there is much less for large projects (mostly commercial and private, aside from a few large open source projects). Designing large software systems, both to meet initial requirements, and to be maintainable and extensible over time, is a different skill than writing small software projects, which is why design of these systems is done by senior developers and systems architects. It's perhaps a bit like the difference between designing a city and designing a single building - there are different considerations and decisions being made. A city is not just a big building, or a collection of buildings, and large software system is not just a large function or collection of functions.
- chrisweekly 10mo ago
  Well said, and good analogy.
- commakozzi 10mo ago
  Yeah, great analogy. Thanks!
delaminator 10mo ago
I’ve got Claude on 10k loc projects, which is probably mid range. But I also have it document and summarise its own work.
- collinmanderson 10mo ago
  > I also have it document and summarise its own work. Could you share some of your prompts or CLAUDE.md? I'm still learning what works.
adastra22 10mo ago
Have it produce CLAUDE.md files in every directory giving a summary of what code is where, and a system directive to keep these updated.

freehorse 10mo ago

At this point my prior is that all these 300/ns projects are some kind of internal tools, with very narrow scope and many just for a one-off use. Which is also fine and great and very useful and I am also making those, but it probably does not generalize to projects that require higher quality standards and actual maintenance.

delaminator 10mo ago
Sure, but 80% of software is probably internal and short lived like that, if not more. Solving the problems of the business that isn’t a software business.
- everforward 10mo ago
  Places that aren't software businesses are usually the inverse. The software is extremely sticky and will be around for ages, and will also bloat to 4x the features it was originally supposed to have. I worked at an insurance company a decade ago and the majority of their software was ancient. There were a couple desktops in the datacenter lab running Windows NT for something that had never been ported. They'd spent the past decade trying to get off the mainframe and a majority of requests still hit the mainframe at some point. We kept versions of Java and IBM WebSphere on NFS shares because Oracle or IBM (or both) wouldn't even let us download versions that old and insecure. Software businesses are way more willing to continually rebuild an app every year.

properbrew 10mo ago

I also see a lot of this so I can't blame you for thinking it! See my other post about some projects build _only_ using LLMs. https://news.ycombinator.com/item?id=46133458 https://news.ycombinator.com/item?id=46133458

sahn44 10mo ago

Here's mine fully deployed, https://hackernewsanalyzer.com/ https://hackernewsanalyzer.com/. I use it daily and have some users. ~99.7% LLM code. About 1 hour to first working prototype then another 40 hours to get it polished and complete to current state.

beepbooptheory 10mo ago
To be clear, roughly 39.8 hours of just prompting and output to make this website?
- sahn44 10mo ago
  41 hours total of prompting, looking at code diffs, reverting, reprompting, and occasional direct code commits. I do review the full code changes nearly every step of the way and often iterate numerous times until I'm satisfied with the resulting code approach.
  - beepbooptheory 10mo ago
    Have you tried to go back to the old way, maybe just as an experiment, to see how much time you are actually saving? You might be a little surprised! Significant "reprompting" time to me indicates maybe a little too much relying on it rather than leading by example. Things are much faster in general if you find the right loop of maybe using Claude for like 15%-20% of stuff instead of 99.7%. You wouldn't give your junior 99.7% ownership of the app unless they were your only person, right? I find spending time thinking through certain things by hand will make you so much more productive, and the code will generally be much better quality. I get that like 3 years ago we were all just essentially proving points building apps completely with prompts, and they make good blog subjects maybe, but in practice they end up being either fragile novelties or bloated rat's nests that end up taking more time not less.
    - adastra22 10mo ago
      I’ve done things in days that in the before times would have took me months. I don’t see how you can make that time difference up. I have at least one project where I can make that direct comparison - I spent three months writing something in the language I’ve done most of my professional career in, then as a weekend project I got ChatGPT to write it from scratch in a different language I had never used before. That was pre-agentic tools - it could probably be done in an afternoon now.

staticassertion 10mo ago

There's a massive incentive not to share them. If I wrote a project using AI I'd be reluctant to publish it at all because of the backlash I've seen people get for it.

aenis 10mo ago
People are and always were reluctant to share their own code just the same. There is nothing to be gained, the chances of getting positive reviews from fellow engineers are slim to none. We are a critical and somewhat hypocritical bunch on average.

__MatrixMan__ 10mo ago

If you haunt the pull requests of projects you use I bet you'll find there's a new species of PR: > I'm not an expert in this language or this project but I used AI to add a feature and I think its pretty good. Do you want to use it? I find myself writing these and bumping into others doing the same thing. It's exciting, projects that were stagnant are getting new attention. I understand that a maintainer may not want to take responsibility for new features of this sort, but its easier than ever to fork the project and merge them yourself. I noticed this most recently in https://github.com/andyk/ht/pulls https://github.com/andyk/ht/pulls which has two open (one draft) PRs of that sort, plus several closed ones. Issues that have been stale for years are getting traction, and if you look at the commit messages, it's AI tooling doing the work. People feel more capable to attempt contributions which they'd otherwise have to wait for a specialist for. We do need to be careful not to overwhelm the specialists with such things, as some of them are of low quality, but on the whole it's a really good thing. If you're not noticing it, I suggests hanging out in places where people actually share code, rather than here where we often instead brag about unshared code.

filoeleven 10mo ago
> People feel more capable to attempt contributions That does not mean that they are more capable, and that's the problem. > We do need to be careful not to overwhelm the specialists with such things, as some of them are of low quality, but on the whole it's a really good thing. That's not what the specialists who have to deal with this slop say. There have been articles about this discussed here already.
- __MatrixMan__ 10mo ago
  What would you have us do, Keep the fixes to ourselves?
  - eschaton 10mo ago
    Yes, keep AI slop “fixes” to yourself and only create PRs for your own work.

delaminator 10mo ago

I came with receipts

JackSlateur 10mo ago

Building something is easy Building something that works ? Not so easy Pushing that thing in production ? That the hardest part