> Why? Because the bottleneck was never typing code. It was always understanding the problem, making architectural decisions, debugging edge cases, and most importantly - knowing what NOT to build.
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.
Same here. I do well in existing codebases because I can follow patterns and adapt to existing limitations but starting a new project is always so daunting to me. Writing a spec and iterating on it is so much more natural than writing code in a new project for me.
I’m the same way; I feel like Claude is doing more than just writing code, it’s getting me unstuck.
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.
Fascinating- I've always loved the big picture, architecture, and I've also loved stable software but have one hell of a time fixing bugs. AI helped me a ton with that.
Well if you're ever in need for a complementary mind in side projects- huh, how does one connect over HackerNews?
I have my own side project that I vibe coded. I probably did what would take one team 6 montns and produced it myself in one month.
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.
Yeah I vibe coded an addition game for my 4 year old that lets him do addition problems where the answer is always 10 or less. It’s very “juicy”. There’s a lot of screen shake and spinning and flashy rainbow insanity going on. If I had done all that stuff myself it would have take a week because I would have been picky about each little animation. The thing that saved me the most time was just being ok with the good enough animations the ai spit out.
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.
> It is insane that companies think they can replace teams wholesale while maintaining quality.
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.
> I probably did what would take one team 6 montns and produced it myself in one month.
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.
A missing link right now is automated high-quality code reviews. I would love an adversarial code review agent that has a persona oriented around all incoming code being slop, that leverages a wealth of knowledge (both manually written by the team and/or aggregated from previous/historical code reviews). And that agent should pull no punches when reviewing code.
This would augment actual engineer code reviews and help deal with volume.
The issue is that before AI, 1% of the population was capable of creating 1 side project per year. After AI, 10% of the population is capable of creating 10 side projects per year. The competition grew by 100x. The pessimist in me thinks that the window of opportunity to create something successful is shrinking.
> The pessimist in me thinks that the window of opportunity to create something successful is shrinking.
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.
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.
Maybe, but LLMs solve but one issue (maybe two). Take me, for example. I am highly proficient regarding software development in most aspects. Except for that tiny problem: I wouldn't even know what to build. And at least for me, LLMs could not help with that.
The whole side project or even private project thing doesn't just hinge on being able to produce software. There's a lot more.
It's like the business of selling electric drills. People don't really want drills they want holes. But holes are difficult to sell so the selling the drills is a proxy for that.
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.
Yes it become much easier to fail fast and iterate, but also a lot of these fail fast projects are trivial for anyone to implement themselves. Differentiating your project is going to be tougher too.
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
But the total market size (in number of products) also multiplied. For instance, as a relatively tiny example, I create a nutrition tracker. There's hundreds already out there, but they never met my specific desire for one. So I created one with Claude (took maybe 2 hours total over a few days) that completely matches my desire, plus I can tweak it as want for my needs.
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.
I think we need to change our perspective of what success is. I believe there will be a ton of small companies popping up instead of a few big ones that eats everyone's lunch. Like Google, Microsoft and others giants have done until now.
Are most side projects in competition? I wouldn't think so.
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.
If the competition just grew by 100x, where's all the great, high-quality, AI-vibe coded side products? Something just isn't adding up here. Could it be that vibe coding on its own just isn't all that useful, and most of those 10% are wasting their time?
I can relate. Sincerely debating whether I quit my well-paying and comfortable corporate job and just go full-time entrepreneur before the opportunities disappear.
The game is all about content now. Forget software. Games, movies, books, music, etc. Things that people will always want regardless of how much there already is. Look at the success of AI slop authors and YouTube channels. That's our future.
> I've shipped 7 side projects in the past year using AI heavily. But I've noticed something counterintuitive: the total time from idea to shipped product barely decreased.
> 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.
>The engineers who thrive will be the ones who can resist the temptation to over-engineer when the marginal cost of adding complexity drops to near zero.
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.
We need to have more metrics for this. Like I hear people making this claim on HN all the time as if they know absolutely for sure but I doubt it's this simple.
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.
This piece hit something I've been trying to articulate for months.
The part about the identity shift from builder to reviewer - that's the real thing nobody's talking about. I spent years getting good at turning thoughts into code. That's a craft. There's a rhythm to it, a kind of flow state you hit when the problem and the solution start locking together.
Now I spend most of my time evaluating code I didn't write, catching issues I didn't create, in systems I didn't design. The volume is higher. The satisfaction is lower.
The HBR study numbers track with what I'm seeing around me. 83% saying AI increased their workload. That's not a bug, that's the whole point. We made code production faster, so now we produce more code. Nobody stopped to ask if that was actually the bottleneck worth solving.
The thing that gets me is the pretense. Everyone talks about AI making engineers more productive. But if you look at what's actually happening, we're not producing better software. We're just producing more of it, faster, with the same number of people. That's not productivity - that's volume.
What's being lost is the time to think. To sit with a problem long enough that you actually understand it before you start implementing. The old friction of writing code manually gave you that thinking time by default. Now you have to fight for it.
Well how many side projects did you ship last year? I’ve written small programs in the last few months over a weekend that would have taken me a month to do a couple years ago, and they’re better. Not in terms of code quality, but in terms of features I wanted and knew how to implement but couldn’t be bothered, Opus can do in one minute and even if it’s not the optimal implementation it’s completely functional, fine, and costs me almost nothing.
The new bottleneck is code ownership. You have to understand what it does and how it works to maintain it long term. You can LLM into a maintainability disaster but you can’t LLM out of it. Biting off more than you can chew is more dangerous than ever.
Fortunately, AI can also be used to reduce complexity. The case I noticed most often is to use the slightly more ugly API, or duplicate some generic code, but avoid pulling in a dependency. Examples are avoiding UI frameworks and directly accessing the DOM in simple web projects, using the CLI arg parser from the stdlib or adding simple helper functions rather than pulling in left-pad like dependencies.
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.
When the goal is to ship (the result) I'll happily leverage LLM's to try an idea or 3 out. However, it wouldn't be fair to claim that my side projects have exactly one goal. That's why I choose to use AI generated code when I deal with stuff that I already know how to do, done a lot of times, and the only thing that I gain from using AI is time typing it out.
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.
This tracks with the way a lot of heavily vibecoded projects have issues with beeing feature heavy, while those features often don't fully work and most importantly don't fit together cohesively. In other words, the quality is low.
I totally agree, except the more we get used to working with the tools the better and faster things will get. I would argue the field has been evolving fast in the past 3 years, but now it's showing signs of slowing down. And I think this is good, as it will allow people to catch up, and refine the approach to adapt better to the new paradigm of coding.
When I got to the part where it said that developers chose software engineering as a job because they like to code not because they want to review or "manage" code I really felt that. But while I enjoy coding & building as solo developer on my projects I can't really say I've ever enjoyed it as a job. Or are you not supposed to like your job? Is that how the world works?
My immediate reaction was, "Only 7?" but that may not be a fair thing to think, depending on what the constraints were.
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.
> AI made me faster at producing code, but it also made me produce MORE code, which means more surface area for bugs, more maintenance burden, more complexity to reason about
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.
They've always said you spend a lot more time reading code than writing it. If suddenly you're writing a lot more code, you're going to spend a ton more time reading it.
> Because the bottleneck was never typing code. It was always understanding the problem, making architectural decisions, debugging edge cases, and most importantly - knowing what NOT to build.
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.
You are putting sentences together just like an LLM would - quite fitting for an AI generated article. You might want to get it checked out, these days you never know if you are a real person or not.
because it is an LLM account or at least someone responding by putting things through an LLM first im pretty sure. Reported it already earlier today somehow not banned. I guess HN is a bit dead, considering how many people are upvoting this slop.
I get benefits with AI both on the writing the code part and the understanding the problem part. If AI disappeared tomorrow I’d probably still enter “plan mode” in my head. I like having the discussion with the AI about requirements and edge cases and all that, while it updates the plan and documents architectural decisions in CLAUDE.md. I love that I can add extra polish, such as color to terminal output, or other random features that would have not made the cut before. Instead toiling on a random one off script to fix a problem I can have a whole CLI build that is a joy to use. Explaining complex architecture is easy now because instead of a boring EDD I can slop out animations that demonstrate data moving and transforming through a system.
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.
There's also a reward for not over thinking it and letting AI bring the solutions to you. The outcomes are better when it's a question, answer, and execution session.
I mean if you've built 7 side projects (and we assume it's the same phase since total time from idea to shipped product barely decreased), how are these things still a bottleneck to you? I'm assuming you're building in a domain/language you're comfortable with by now (unless you're crazy and try something fundamentally different on each of those shipped products).
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?
I use AI for side projects because Google gives me a stupid large number of tokens that refresh every 6-24 hours on my existing $10/mo Google One plan. I see it as my civic duty to help increase their costs by producing slop that I generally throw away anyways because it doesn't actually work after it gets generated.
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.
> The engineers who thrive will be the ones who can resist the temptation to over-engineer when the marginal cost of adding complexity drops to near zero.
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.
JimBlackwood|9 hours ago
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.
rockostrich|7 hours ago
jerich|5 hours ago
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.
rainmaking|8 hours ago
Well if you're ever in need for a complementary mind in side projects- huh, how does one connect over HackerNews?
unknown|7 hours ago
[deleted]
fma|9 hours ago
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.
Thanemate|9 hours ago
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.
arw0n|7 hours ago
sarchertech|9 hours ago
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.
lakrici88284|6 hours ago
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.
latexr|9 hours ago
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.
prescriptivist|8 hours ago
This would augment actual engineer code reviews and help deal with volume.
RivieraKid|9 hours ago
kevinsync|7 hours ago
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.
[0] https://youtu.be/YYkj2yYaGtU?t=112
[1] https://youtu.be/YYkj2yYaGtU?t=160
hypfer|9 hours ago
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.
fuzzy2|9 hours ago
The whole side project or even private project thing doesn't just hinge on being able to produce software. There's a lot more.
samiv|9 hours ago
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.
rapind|9 hours ago
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
gilbetron|8 hours ago
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.
o_m|9 hours ago
ehnto|9 hours ago
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.
zozbot234|7 hours ago
kcmastrpc|9 hours ago
claytongulick|8 hours ago
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.
ramesh31|8 hours ago
Aurornis|8 hours ago
> 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.
citizenkeen|7 hours ago
xhrpost|6 hours ago
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.
threethirtytwo|8 hours ago
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.
amelius|8 hours ago
I'm sure it also helps translate an app written for iOS into an app written for Android.
So it definitely improves performance.
onoht|6 hours ago
The part about the identity shift from builder to reviewer - that's the real thing nobody's talking about. I spent years getting good at turning thoughts into code. That's a craft. There's a rhythm to it, a kind of flow state you hit when the problem and the solution start locking together.
Now I spend most of my time evaluating code I didn't write, catching issues I didn't create, in systems I didn't design. The volume is higher. The satisfaction is lower.
The HBR study numbers track with what I'm seeing around me. 83% saying AI increased their workload. That's not a bug, that's the whole point. We made code production faster, so now we produce more code. Nobody stopped to ask if that was actually the bottleneck worth solving.
The thing that gets me is the pretense. Everyone talks about AI making engineers more productive. But if you look at what's actually happening, we're not producing better software. We're just producing more of it, faster, with the same number of people. That's not productivity - that's volume.
What's being lost is the time to think. To sit with a problem long enough that you actually understand it before you start implementing. The old friction of writing code manually gave you that thinking time by default. Now you have to fight for it.
Allybag|9 hours ago
peacebeard|7 hours ago
karl42|8 hours ago
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.
Thanemate|8 hours ago
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.
StrauXX|9 hours ago
3abiton|7 hours ago
victorzidaroiu|8 hours ago
rnimmer|6 hours ago
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.
jmull|6 hours ago
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.
eunos|9 hours ago
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.
Brysonbw|5 hours ago
mark-r|8 hours ago
zozbot234|7 hours ago
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.
cornholio|9 hours ago
jascha_eng|5 hours ago
mountainriver|9 hours ago
eloisant|9 hours ago
You can use it to discuss about what you should build, identify edge cases, ask you questions to force you to take decisions, etc.
ramoz|6 hours ago
383toast|6 hours ago
Shadowmist|7 hours ago
sh3rl0ck|8 hours ago
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.
cactusplant7374|8 hours ago
westurner|9 hours ago
Were you able to fairly split test?
altmanaltman|9 hours ago
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?
hardolaf|9 hours ago
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.
TacticalCoder|9 hours ago
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.
snowhale|8 hours ago
[deleted]
syndacks|8 hours ago