[schnebbau]

That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better.

I started using AI with the best intentions. Checking everything before committing. Improving output by hand if it didn't quite follow the existing code style guidelines or variables were not named as well as they should be. Or if it did something sloppy or hacky.

Now, AI GOES BURRRRRRRRRRRR! If the tests pass it's good to ship. AI can deal with the problems it may create. No problems so far.

[saghm]

How did you know you're not stuck at a local optimum where the AI could iterate even faster if you enforced higher quality on what it produced?

To make up some hypothetical numbers in order to illustrate with math: if you ship bugfixes 10x faster but then have 11x more bugs you need to fix, that's not a net improvement. Even if it's only 5x more bugs, maybe you could reduce that to 2x if you changed how you worked to only be 8x as fast in a way that produced higher quality code. Similarly, maybe you could cut the time it needed to produce a new feature by 50% if your code were higher quality by moving 20% slower.

My point in all of this isn't that you literally need to work the same way you did before you had these tools, but that framing it as either "move fast and ignore the code" and "use the same exact heuristics you would in the pre-LLM days for what code is acceptable" is a false dichotomy. If you aren't thinking about how effectively you're using these tools and whether there are changes you could make to move even faster because "AI go brrr", I think you've lost the plot in the same way you probably think that other people in this thread have.

[geraldwhen]

It’s a new form of development. The thing that the author didn’t state is that to work the code base at all, you must also use these tools and workflows.

Manual edits literally aren’t possible. You can’t grok the code growth and the new patterns fast enough to be productive.

This does work. I’ve seen it in real products. Nobody has a real mental model of the code flows. But with enough money in Claude credits it doesn’t matter.

The spend to support this development model is something like $50/day/developer.

[saghm]

I don't understand what anything you're saying has to do with what I said. My claim is that "groking the code" is not a binary, and you can balance between full vibe mode without ever reading it and requiring that you understand every single line, with the corollary that it's at least plausible that being on the far end of the spectrum where you never read it isn't safe to assume is the global optimum, and your rebuttal seems to be "well it's not the global minimum".

[thevillagechief]

Are you my colleague? It's fine if it's your own personal app, but please don't do this in a large complex codebase in a team. It's entirely depressing. You can use AI and still write good code. I think it's actually probably easier to write maintainable code with AI.

[embedding-shape]

> That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better.

This work great until you reach a certain size, then good (or even "not bad") code is required otherwise the model spins its wheel trying to ensure the change is correct.

The way I've measured how good/bad the code is (for AI) is to have one "baseline fixed change" that I measure how long time it takes to implement. Always in the beginning (less than 10K LOC, as just some measurement), this baseline change will take 2-3 minutes. As you add more code, the same change starts to take 5-6 minutes, and once you hit 1 million LOC, it can take as long as 10 minutes, even though the change is the same.

It's when this baseline task starts to take longer time, that you need to update the design/architecture/layout/whatever, to better fit the task/domain, and to actually make it easy to maintain and still possible to add changes without spending 10 minutes. So its at this point you refactor, and once done, the baseline task will again be easy for the model to do.

So yeah, if all you do is smaller projects, then "shipping 10x as many features" is easy and doable, for the lifetime of the projects. But once the projects start to accumulate technical debt, the model will have a harder time making sure the changes are correct, and suddenly "shipping 2x as many features" is maybe doable, but you could still have had 10x if you just spend slightly more time on the actual design and architecture of the program.

[schnebbau]

Yes, this resonates. I have noticed things slow down over time. But fortunately my app will never grow that big so I don't think it will be an issue.

The solution, as you say, is probably to break it down into isolated sub-components that are only aware of each other's APIs and nothing more.

[javier123454321]

Yeah, for personal software, enterprise practices don't make sense.

[swatcoder]

> shipping 10x as many features and bugfixes sounds better

I understand you're excited about the tool, but for the sake of earnest discussion here, maybe commenters like yourself can tone the hype down to plausibility?

Claims like this are just nonsense. It's not how product development works.

How do you even have so many bugs left to fix if the tool is so fast and productive? Surely, you didn't have a backlog of tens of thousands of bugs that you're still chewing through? And of course, the volume of new bugs much be minimal since the AI-composed additions introduce "no problems so far". If it works like you say, which we'll accept in good faith per HN guidelines, you must have exhausted your backlog long ago.

And if you've indeed exhausted your bug backlog long ago (incredible!), you're left to talking about shipping "10x as many features". Yet no product has a limitless capacity for features. Nobody would want to use software so bloated and churning that was gaining features at such a pace. And who is designing and specifying them so quickly anyway? If it works like you say, which we again accept in good faith, you must have stalled out on your feature list long ago.

If the AI indeed allows you to "[ship] 10x as many features and bugfixes", and we take what you say in good faith, then one of the following seems to be implied:

* you've fixed all your bugs and blew through your mature feature designs already, leaving your AI agents sitting idle for all but a few hours a week, while you're bottlenecked on feature design and your software product is bloated beyond imagination

* your coding productivity before AI was absolutely glacial by industry standards such that "10x" productivity for you is actually much closer to "0.5-2x" for others

Any insight into which of those it might be?

[javier123454321]

OP is making toys, not enterprise software

[latexr]

Man, I bet Jia Tan is simultaneously kicking themselves and having a field day. All those years of wasted effort gaining trust and making good contributions to try to land a sophisticated backdoor into a tool via layers of indirection, and then not long after we have devs just going “I don’t need to read this code, or prioritise, or think about what makes sense, just prompt for fractals of kitchen sinks and ship it”.

Anthropic themselves have admitted you don’t need much to poison LLMs¹. I can’t wait for us to discover the backdoors that are being introduced. I hope it happens soon so people get to their senses. Bah, what am I saying, when (not if) that happens, the response will just be to throw more LLMs at it.

¹ https://www.anthropic.com/research/small-samples-poison

[duskdozer]

It's a good time to archive pre-LLM copies of the programs you use and make sure you can build them.

[matt_kantor]

How long has "so far" been?

[pauletienney]

I second that question

[schnebbau]

Since November.

[AnimalMuppet]

Yeah... in at least some circumstances, "maintainable" means, like, 20 years. 8 months is not an adequate test.

[hansonkd]

Yeah, the flip side of the article is that Fable level models can fix the majority of codebases created from the past 3 years and one shot it to a fixable state that is "human maintainable"

[geraneum]

That sounds like a good idea but how do you know what you’re shipping?

[aarjaneiro]

Nobody is reviewing this, right?

[exabrial]

One does not exclude the other

[carimura]

I find myself doing this but then I worry that the slop will just compound and 3, 6, 12 months from now as my services scale I'll have a harder time operating them. Maybe I'm wrong.

[cmrdporcupine]

The bigger problem is the number of things you don't understand will grow substantially from under your feet, and then you'll slip on it.

[carimura]

that's 100% happening to me right now not just with a specific codebase but with the fun/engineering parts of coding in general.... it makes me sad, slightly concerned, but optimistic that I can build a trillion dollar company with no employees. I'm kidding. Who knows. I'm enjoying building so I guess there's that.