sockgrant

LLM evals are well established, are these not applicable here?

if you work on platforms, frameworks, tools that are public knowledge, then yeah. If there’s nothing unique to your project or how to write code in it, build it, deploy it, operate it, yeah.

But for some projects there will be things Claude doesn’t know about, or things that you repeatedly want done a specific way and don’t want to type it in every prompt.

The only way Claude can help improve your code cleanliness is if you write poor code?

Code coverage means nothing if you didn't carefully check every test? "and if everything was tested" do you know what code coverage is?

not gonna engage the trolling

Heck yeah! Love that way of putting it. Agree. Now there’s more time to focus on making the right architecture and carrying it out. It’s no longer a days long task to do a big refactor to remove code smells.

I agree some people go to work to work, and claude is find / good for them, but I feel that characterization of us who are loving claude is disingenuous. I’m a creative, while I loved coding and honed my craft, it was creating that always had me hooked. Claude is creating on steroids. Not to mention, it can help you massively improve your code cleanliness. All of the little nice-to-have features, the cleanups, the high unit test coverage, nagging bug fixes, etc., they’re all trivial to do now.

It’s not the same as writing code, but it’s fun.

If your coworkers can’t outpace your code output they’re either not using opus4.6 or they aren’t really trying.

It’s pretty easy to slam 20 PRs a day with some of them being complex changes. The hardest part is testing the diffs, but people are figuring that out too.

“As a designer…”

IMHO the bleeding edge of what’s working well with LLMs is within software engineering because we’re building for ourselves, first.

Claude code is incredible. Where I work, there are an incredible number of custom agents that integrate with our internal tooling. Many make me very productive and are worthwhile.

I find it hard to buy in to opinions of non-SWE on the uselessness of AI solely because I think the innovation is lagging in other areas. I don’t doubt they don’t yet have compelling AI tooling.

It’s also a description of why native wasn’t chosen from the get go.

This thread is people who ship products vs people who ship engineering.

The companies do pay a cost — lost users and revenue due to the downsides.

But they’ve determined that this cost isn’t meaningful enough to write performant native platform specific versions.

Yeah but if something stays in Electron 10 years later then either it’s not successful enough to warrant the cost of a rewrite or the payoff of the rewrite isn’t a good trade off.

In both cases if originally building in Electron was a substantial productivity boost then it sounds like it was the right choice.

Gotta love engineers. 45 minutes of reading 12 years of someone’s work and the first thing they say is “yeah I’d rewrite it”.

Every. Dang. Engineer. It’s crazy.

I try to work in a codebase for 3-6 months before coming to any wild conclusions. Usually you find that there’s some warts but it does the job and there’s complexity that was solved that you hadn’t originally noticed, and it’s not worth rewriting it just needs some love in some areas.

People hate reading other peoples code.

Was on a team this happened on and a lot of the l4 l5 Eng gossiped about how little our L7 knew

I don’t agree because not all interviews work that way, especially for teams that write cpp and c — they don’t let candidates interview in JS for instance.

I had a high level eng join a domain specific team I was on and he didn’t do well because he didn’t know the domain very well. He had general skills around leadership and communication that someone of his level should have, and it kept him afloat, but for a high level technical IC you need to be at worst fluent in the domain and at best a technical leader in the group.

At lower levels of IC generalist is fine, the blast radius of your technical decisions is smaller so it’s less risky to learn on the job.

But yeah, not knowing the domain you’re going to join, whether it’s a type of work or a programming language, you won’t be as effective.

You get massive DoS attacks pretty regularly? State sponsored hackers?

While I see your point, a lot of invention happened when someone ignored conventional wisdom and others’ failures.