sigotirandolas

My take: I don't see the point of those new-IDEs. They are mostly just worktrees+sandbox+tabs+prompts, which is just git+docker+tmux+thinking, but if you actually learn to use those tools instead of handcuffing your agents to whatever take the IDE has, you're going to be much happier and effective.

(That's also why there are so many of them: It just isn't that hard, everyone feels like a genius when they figure it out, and it's a great way to resume-build in the AI era).

> Why does AI-generated imply "not bothered" to you?

1. AI generated text is just hard to read and verbose, if you worked so hard on your docs/specs, why would you want your README to be unreadable?

2. There's so much garbage written with AI that I'm just going to assume yours also is. Would you sign up to a gym with broken windows? It could be the best gym ever, but I wouldn't count on it.

My thought as well, I think this approach only works for them because:

* They can afford frequent CC incidents since their value is having the best models, and 95%+ uptime is still OK-ish.

* The core functionality of CC (the harness "agentic loop") is simple, an if that works then for most purposes CC works.

* CC just stores a bunch of config and history files, there isn't any financial or irreversible safety loss if they mess it up once in a while.

Once you work on something where a minor slipup can result in a huge real world mess, then I don't see how their approach can work.

A bit off-topic, but on the rare occasions I help some acquaintance with Windows I always feel a bit upset that random split second console windows still pop up when installing everyday software, even that from Microsoft.

I remember them from way back on Windows 98 and no one seems to care to hide them (?).

I agree. For bug fixes, just write a clear issue: how to reproduce it, what goes wrong, what's the root cause. As short and well written as possible, without AI fluff.

Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?

In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.

If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.

Yeah. A git bisect can still hit it.

It definitely doesn't inspire confidence in the project taking security seriously.

(Also the "write-up" is almost surely a "Claude-up", though it appears generated by someone external to the project).

Perhaps that's true of the top 5% engineers. But the question is if the top 40% of engineers can replace the bottom 60%.

The LLMs don't need to be perfect, they just need to be good enough so that the cost of fixing their code is lower than the communication overhead and the 'lost in translation' overhead from delegating tasks to mediocre engineers.

I don't look at whether the text is written by an LLM but at whether it has substance and whether the writer understands what they are doing and is respecting my time.

If the text is full of punchy three word phrases or nonsense GenAI images then that's an obvious sign. But so is if the other person has some revolutionary project with great results but they can't really explain why their solution works where presumably many failed in the past (or it's a word salad, or some lengthy writing that doesn't show any signs of getting you to an "aha, that's some great insight" moment).

A good sign is also if the author had something interesting going before 2022, and they didn't fall into the earliest low quality LLM waves. Unfortunately some genuinely talented people have started using LLMs to turbocharge their output while leaving some quality on the table nowadays, so I don't really know. I'm becoming a lot more sceptical of the Internet, to be honest.

On the one side I reject that product and engineering concerns are separated: Sometimes you want to avoid a feature due to the way it will limit you in the future, even if the AI can churn it in 2 minutes today.

On the other side perhaps your company, like most, does not know how to measure overengineering, cognitive complexity, lack of understanding, balancing speed/quality, morale, etc. but they surely suffer the effects of it.

I suspect that unless we get fully automated engineering / AGI soon, companies that value engineers with good taste will thrive, while those that double down into "ticket factory" mode will stagnate.

To be devil's advocate:

Many of those tools are overpowered unless you have a very complex project that many people depend on.

The AI tools will catch the most obvious issues, but will not help you with the most important aspects (e.g. whether you project is useful, or the UX is good).

In fact, having this complexity from the start may kneecap you (the "code is a liability" cliché).

You may be "shipping a lot of PRs" and "implementing solid engineering practices", but how do you know if that is getting closer to what you value?

How do you know that this is not actually slowing your down?

Luckily those I work with are smart enough that I've not seen a PR thrown away yet, but sometimes I'm approving with more "meh, it's fine I guess" than "yeah, that makes sense".

The most annoying thing is that even after cleaning up all the nonsense, the tests still contain all sort of fanfare and it’s essentially impossible to get the submitter to trim them because it’s death by a thousand cuts (and you better not say "do it as if you didn’t use AI" in the current climate..)

N~10^(6.5) aliens.

I hope this too but it's not a given, IMO. Previously people without technical chops failed quickly by being unable to deliver working code, now they can deliver mediocre code with the damage only becoming clear years later. It breaks the "can deliver code --> good technical ability" proxy and even after the initial damage wave, it's unclear if we will find a better proxy.