[flagged]
For me, this is a bit different. Writing code has always been the bottleneck. I get most of my joy out of solving edge cases and finding optimizations. My favorite projects are when I’m given an existing codebase with the task, “When mars and venus are opposite eachother, the code gets this weird bug that we can’t reproduce.”
When a project requires me to start from scratch, it takes me a lot longer than most other people. Once I’ve thought of the architecture, I get bored with writing the implementation.
AI has made this _a lot_ easier for me.
I think the engineers who thrive wi be the ones know when to use what tool. This has been the case before AI, AI is just another tool allowing more people to thrive.
Well if you're ever in need for a complementary mind in side projects- huh, how does one connect over HackerNews?
I stopped trying to recruit cofounders because I don’t need them anymore
I can do everything I need to do by myself plus tools at a pace no set of humans can achieve
I’ve been pulling projects out of the closet that have been sitting there for years. It’s because I can sit down and get started so seamlessly. Before, I might waste the first couple hours configuring my environment and tool setup, but with Claude Code I can just jump in and start building, start solving the real problem.
I just built something this week where I had the parts sitting in my closet for a couple years, but just got curious to see how Claude does with embedded C, so it got me started. (Turns out Claude scanned my drive and found an abandoned C project that was outside my usual DEV folder, and just built on that). The code was 5% of the project, but it got done because Claude Code gave me the momentum push.
For my personal projects, the last 3 weeks have been more productive than the last 3 years.
I'm not afraid of breaking stuff because it is only a small set of users. However for my own code for my professional job no way I would go that fast because I would impact millions of users.
It is insane that companies think they can replace teams wholesale while maintaining quality.
Tech-savvy people might understand this feeling, but those who are responsible for hiring will easily proceed with another candidate that goes fast.
When push comes to shove, then, programmers will opt to have food to eat over handling technical debt generation.
It’s amazing for him and it works on his iPad.
However when I tried it on my iPhone it was a broken mess. Completely unusable (not because of screen size differences).
I tried getting Claude to fix it but it couldn’t do it without changing too much of the look and feel, so I dug into the code and it was thousands of lines of absolute madness. I know from using this at work that there are things I could have done. Write tests to lock in things I like etc…
But so much of the speed up was about not caring about the specifics that once I started caring about making an actual product, I was not much faster maybe not any faster at all. The bottleneck in writing a game was never in banging out code.
Ask the AI to assess the code itself and to propose ways to gradually refactor it for better cleanliness. It can be good at that stuff, but you need to make it an explicit goal.
It’s not an impossible problem to solve. I could probably setup a test harness that uses the existing game as an oracle that checks to see if the same sequence of inputs produces the same outputs. But by the time one done all, got it to clean up the code, and then diagnosed and fixed the issue, I doubt I would have saved very much time at all if any.
I find it… Amusing? That’s not quite the word. That programmers—a group notoriously for making wrong estimates of how long something will take to build—continuously and confidently spew a version of this.
And it’s not even estimating how long we ourselves would take to build something, now we’re onto estimating what an undetermined team of completely made up strangers could do. It’s bonkers. It has no basis in reality.
Yes, it is. “It would take a team 6 months” is an estimate, and I don’t see how you can argue it’s not. Even if it just said it would take them longer, that would still be an estimate.
> Claude makes me 10x faster than on my own without AI
Also an estimate.
> where 10x absolutely is a completely made up number
And by your own admission, an estimate taken from the ass that you thus cannot be certain is true. Made up perception does not equal reality.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
Yes you do, you already made the argument when you pointed out the “team” size and makeup was completely unspecified, therefore the number is not an estimate, it’s just a number.
When you call it an “estimate” you are adding additional unsupported specificity to something that was explicitly stated as being hand-wavy to make an obviously rhetorical point. Are you saying you can’t understand the point being made?
My 10x is based on my experience doing projects with Claude. I also said “some” tasks, not all tasks, and I didn’t specify which tasks, and I clarified that my number is made up, which is why my number is also not an estimate of anything. There are some tasks that Claude can do 10x faster than me, and there are some tasks that it can do 100x faster than me, and there are some tasks I can do faster than Claude... for now... More importantly for me personally, Claude makes starting projects and using tech I don’t already know easier; it’s lower effort, regardless of speed.
The paper is interesting and a valid data point, but I don’t think it proves your point. I’ll respond with a few thoughts.
First, the dev’s self estimate of AI productivity speedup was +20%, even though their measured productivity was -20%. This may relate to the effort and not the speed, and it’s important to note that this is a gray zone the paper didn’t explore, and something that can be true on both sides. I can be “faster” at developing and still take the same or longer wall clock time. Measuring the time doesn’t capture how the time was spent, nor the qualities of that time.
Second, this study was done a year ago. That’s an eternity in AI land, and everyone noticed Claude and other models getting substantially better at code writing last fall, plus workflows and tooling are improving even faster than that. There’s every reason to believe the outcome of the exact same study might be different this year than it was last year.
Third, this study is explicitly biased toward large projects, and large projects are, even today, more difficult to find the productivity boosts with. I find Claude absolutely amazing at starting new projects, and absolutely terrible at working in large code bases that don’t fit in context. When I say Claude makes me 10x faster at some projects, I’m referring to something like setting up a new CRUD app when I don’t know much about setting up a database and web server backend, or writing a graphics app in Vulkan when I’ve only used OpenGL. Doing stuff like that, having Claude help me with tech stacks I don’t know, absolutely is many multiples faster than doing it on my own, and the paper link you’ve shared doesn’t address that use of AI at all.
Note specifically the paper says they are not demonstrating or claiming that “AI systems do not currently speed up many or most software developers”, and they have not demonstrated or claimed that “AI systems in the near future will not speed up developers in our exact setting”. It might be a mistake on your part to try to use this as some kind of evidence that AI isn’t speeding devs up.
This would augment actual engineer code reviews and help deal with volume.
The assumption is that AI will continue to improve. If we get another one or two quality jumps over the next 1-3 years, which is not totally unreasonable, AI quality might be good enough.
Dunno man. Ideas alone aren't worth anything [0] and execution is everything [1], but good ideas and great execution will never go out of style regardless of how much competition is out there. I'm of the opinion that even if 10% of the population is now capable of creating a side project, there's still the same relatively-fixed amount of people capable of making a good side project, and even fewer who will see it through to a real product. Nothing has really changed in the aggregate. It's like architecture, there are always improvements in materials, tools and processes, and Claude and Codex can provide more laborers for almost free, but most people are still gonna be building uninspired McMansions instead of the Guggenheim.
So really, they are comparatively cheap. I, for one, have hundreds of ideas, but always lacked the time to execute on 5% of them.
- A todo app better than the existing ones
- A todo app with these 3 features
- A todo app with these 3 features, here's how the UI would look
I have tens of ideas, but maybe 1 - 3 that I believe have a meaningful chance to become successful and generate income ($20k annually or more) with great execution. I find it hard to come up with ideas that have a fairly clear path to success and can generate income.
Eg. when interviewing, sometimes I have a pool of interviewers, and I want a pair to be offered to a candidate (they only see time slots, obviously) with certain internal conditions (one expert from this pool, another from this pool; eg. tech stack or timezone), while equally loading all of them.
Sounds simple but I could never find a tool that does it, and I believe companies might be interested just like they get tools like calendly just for limited purposes.
iCal format is simple on the face of it, but companies have restrictions on the feeds, and accounting for recurring events and working hours is not as trivial.
What do you mean "nothing has changed"? Using your numbers, the SNR went off a cliff.
Use HN as an example - I used read the new stories all the time before they hit the frontpage, and upvote as needed.
But with 100s of slop submitted for every 1 actual good article, I can't do that anymore.
IOW, I have finite time. If 10% of the population is now able to vomit out side-projects, I am never going to find the one good one because it will be lost in a sea of rubbish.
And you're right that people still have limited, fixed bandwidth with regards to attention available to give to things.. and the same amount of things that break through doesn't change from what could break through and stick before (in the monoculture). But the amount of niches/verticals where you have the opportunity to break through inside of is significantly higher than ever. That gives you a better chance for success, because your audience is more targeted, more receptive, hungrier for authenticity, hungrier for quality, and desperate for connection to something they like.
TL;DR if you have a good, valuable idea that people want (or don't yet know that they want), execute it well, deliver something that is undeniable, promote it effectively, and stick it out for the long haul, you'll find success. There's no magic formula beyond that, and it doesn't matter if there are 10 or 10 million amateurs clogging the toilet bowl next to you.
True; I misunderstood.
You are contending the assertion "more slop == decreasing ability to create quality", I am asserting that "more slop == lower overall quality".
FWIW, there's probably an argument to be made against your assertion as stated above, but it's probably going to be a long-winded and ultimately weak one. I'm not really in the mood to explore weak arguments, TBH.
Why do you look at it that way? Why does anyone beside you have to care about what you do?
Just build something for yourself. You will always have things you'd like to build for yourself. You will be in competition with yourself only and your target audience will be yourself.
Market forces do not apply to side-projects, because that's what people do for fun.
Just because there are chess computers, doesn't mean that no one plays chess anymore at home.
This is just a correction of something that managed to remain in an invalid state for an impressively long time.
Yes.
> The entire open source ecosystem works on this idea otherwise there would be no point in sharing and we can move to closed software.
No.
The _actual_ open source system consisted of hackers scratching their own itch and sharing the artifacts, because (it was assumed that) sharing is free. So if the work is already done and solved their problem, why not also share it as gift.
This remains unchanged.
The driving force of FOSS is not "how can I fix someone else's problem". It never has been.
Well.. maybe on HN it was different, but that's not "the open source ecosystem". And, yes, maybe some corps have gaslit naive people into believing that they must donate their lives to said corps.
If you have the time tona scratch your own itch and gift the results, it implies you have a source of income that gives you the time/lifestyle to do such a thing. You might be a tenured academic, or live in a society with a strong safety net. Or you might be able to do your day job in 1/2 the allotted time.
The problem is that a those scenarios are eroding precipitously, leaving more to seek compensation for their work output, whether it is closed or open source.
So what is really changing?
Higher education is less affordable and accessible to more families, and the value proposition is eroding. CS academics survive by joint ventures with corporations, not by their University salaries.
Escalating cost of living and reduction in institutional support systems push more people toward allocating their scarce spare time toward fundamental needs rather than contributing to the software commons.
I agree the scale will change, but most of the core FOSS we depend on today has started off when software development was not as lucrative as it was in the past 2+ decades — which means it can still happen. It does change the dynamics as you say.
If you are good at something that you enjoy doing and that is valued by others, that’s the ideal scenario. And that’s what writing software looked like for many people for a long time.
That doesn’t mean you should do things just to please others. And it also doesn’t mean you can’t do something just because you enjoy doing it. But it means that these people now have a diminished ability to employ their unique skills to help others while doing something they love doing. That can sting, understandably.
a) Almost no one but you cares and
b) Now that this has become trivial, there's no much joy in it. The struggle we had before A.I was the real joy; prompting agents for a few days and getting what you want isn't that joyful.
If you have no reaction at all, you probably weren't paying attention.
Eventually though, people _should_ recover and return after having processed the changes. So maybe the professor was still recovering at the time?
The whole side project or even private project thing doesn't just hinge on being able to produce software. There's a lot more.
In software it's the same thing. People don't really want software they want data and data transformation. But traditionally the proxy for that has been selling the software (either as a desktop app or then later as sole kind of service).
You could argue that in either case the proxy is not what people want but yet because of the difficulty of selling the "actual" thing the proxy market has flourished.
We're now inventing a new tool that will completely disrupt that market and any software business that is predicated on the complexity required to create the software to transform the data is going to get severely disrupted. Software itself will be worthless.
The value of computers since its inception was that it's capable of transforming data very, very fast and autonomously. But someone has to input that data from the real world or capture it using some device, and someone has to write the rules.
What happened is that we created a whole world of information and the rules has become very complex. Now we have multiple layers stacked vertically and multiple domains spread horizontally. At one time, ASCII was enough, now we have to deal with Unicode.
Software becoming worthless will mean that everyone has learned the rules of the systems we created and capable of creating systems with good enough quality. I'm not seeing that happens anytime soon.
When you drive down that cost you drive down the potential value of the software products. Remember that what is a cost to one party is revenue to the other party. Without revenue there cannot be profit and without revenue software has no dollar value.
If anyone can create "photoshop" with minimal cost and there are thousands of said "photoshop" apps what will be the retail sell value of those apps. Close to zero.
This same lifecycle already happened with games. Driving down the cost of producing games resulted in a proliferation of games that are mostly worthless that you can't even give away.
I do agree with you on that point.
> If anyone can create "photoshop" with minimal cost and there are thousands of said "photoshop" apps what will be the retail sell value of those apps. Close to zero.
This is the point that I cannot agree with. Not anyone can create photoshop because of the amount of knowledge you need about the data and transformations that needs to be applied to get a specific result. And then make a coherent system around it. You can create isolated function just fine, just like a lot of people knows how to build a shed with planks and nails. But even when given all the materials and tools, only a few can build a skyscraper or a mansion.
That knowledge of how to create a coherent systems that does something well is the real cost of software. Producing code isn't it.
That being said what already exists was already enough to shutter the stock prices of many software companies precisely because the fear is that their clients will just re-create the software themselves instead of buying it from someone else.
I guess we'll see how this will pan out in the next few years.
A lot of the moats are gone, but quality (and security) is in a nose dive. AI built project might be the Ikea furniture. Good for the masses, but there's still a market (much smaller) for well crafted applications and services. It's hard to say what it'll look like in a couples years though. Maybe even the crafting is eventually gone. /shrug
No one else will want this specific piece of software. But I love it.
Sure, there will be 100x the competition, but there will be also 100x the software needs. Now, if you want to get crazy rich building software, that does get tougher, but that's a good thing, I think.
Even if they were I disagree that 10x more ideas being produced means 10x more products in competition. You could leverage AI to execute but still have terrible ideas, leadership, product stewardship etc.
I think some clever people with a real and valuable insight will finally be able to turn that insight into a product. I also think the other 9 products will be get rich quick attempts by people with nothing to offer.
I think there's more opportunity to do something novel.
AI can't do it, and the humans with the skills to do it are rapidly disappearing.
> Why? Because the bottleneck was never typing code.
Were you also shipping side projects every 2 months before AI?
If not, this comment just reads like cognitive dissonance. Your core claim is that AI has enabled you to ship 7 projects in 12 months, which presumably was not something you did pre-AI, right? So the AI is helping ship projects faster?
I agree that AI is not a panacea and a skilled developer is required. I also agree that it can become a trap to produce a lot of bad code if you’re not paying attention (something a lot of companies are going to discover in 2026 IMO)
But I don’t know how you can claim AI isn’t helping you ship faster right after telling us AI is helping you ship faster.
I can guarantee you this... the story is not absolute. Depending on who you are and what you need to work on dev time could be slower, same or faster for you. BUT what we don't know is the proportion. Is it faster for 60% of people? 70%, 80%?
This is something we don't know for sure yet. But i suspect your instinct is completely wrong and that 90% of people are overall faster... much faster. I do agree that it produces more bugs and more maintenance hurdles but it is that much faster.
The thing is LLMs can bug squash too. AND they are often much faster at it then humans. My agentic set up just reads the incoming slack messages on the issue, makes a ticket, fixes the code and creates a PR in one shot.
I'm sure it also helps translate an app written for iOS into an app written for Android.
So it definitely improves performance.
I think this isn't being discussed enough in the SWE world. It wasn't too long ago that engineers on HN would describe a line of code as "not an asset but a liability". Now that code is "free" though, I'm seeing more excessively verbose PRs at work. I'm trying to call it out and rein it in a bit but until engineers on average believe there is inherent risk here, the behavior will continue.
Since managing dependencies is one of the major maintenance burdens in some of my projects (updating them, keeping their APIs in mind, complexity due to overgeneralization), this can help quite a lot.
See also https://www.karl.berlin/simplicity-by-llm.html for some of my thoughts regarding this.
Anything else? I'll struggle and grow as a developer, thanks. And before anyone says "but there are architecture decisions etc. so you still grow"... those existed anyways. If I have to practice, I'll practice micro AND macro skills.
I think from time to time, it's better to ask the AI whether the codebase could be cleaned and simplified. Much better if you use different AI than what you use to make the project.
The shift I've experienced is something akin to being able to finally focus on the aspects I've always enjoyed most: architecture and user experience. I review all the code, but through iteration my prompts have gotten better, and for the most part my automated codemonkey 'employee' produces good code. It's not reasonable to expect complex things to be one-shot; UX improvements always require follow-ups, and features need to be divided and conquered one at a time. Engineers who lack those higher level skills will struggle. You are leading a small team now, not just plugging away at implementing user stories.
Anyone could ship thousands of projects, depending on the definition of "ship" and if you don't care what value the project has beyond notionally increasing your tally.
You can use it to discuss about what you should build, identify edge cases, ask you questions to force you to take decisions, etc.
Were you able to fairly split test?
The AI can help you in these tasks too, but you need to ask for the help in terms that it can help you with, and not expect it to be genuinely intelligent or to have a crystal ball. As a bonus, once you've gotten these things into the agentic context, the code itself becomes better too.
One-shotted vibe coding is an anti-pattern.
Why will the 8th project still have those things as the bottleneck given your experience?
Also if you're not seeing any real gains in productivity, why are you using AI for your side projects and wasting tokens/money?
At work, I was told to use AI but it doesn't actually work for anything that I couldn't have handed off to a brand new undergraduate intern. So I use it for things that I don't care about then go spend twice as long rewriting what it output because it made the task longer by being wrong.
One area --and many may not like that fact-- where it can help greatly is that the cost of adding tests also drops to near zero and that doesn't work against us (because tests are typically way more localized and aren't the maintenance burden production code is). And a some us were lazy and didn't like to write too many tests. Or take generative testing / fuzzy testing: writing the proper generators or fuzzers wasn't always that trivial. Now it could become much easier.
So we may be able to use the AI slop to help us have more correct code. Same for debugging edge cases: models can totally help (I've had case as simple as a cryptic error message which I didn't recognize: passed it + the code to a LLM and it could tell me what the error was).
But yup it's a given that, as you put it, when the marginal cost of adding complexity drops to near zero, we're opening a whole new can of worms.
TFA is AI slop but fundamentally it may not be incorrect: the gigantic amount of generated sloppy code needs to be kept in check and that's where engineering is going to kick in.
As you mentioned, scope definition and constraints play a major role but ensuring that you don't just go for the first slop result but refine it pays off. It helps to have a very clear mental model of feature constraints that doesn't fall prey to scope creep.