Live data from Hacker News

A staff engineer's journey with Claude Code

sanity.io

351–360 of 410 posts

Re: A staff engineer's journey with Claude Code

#351
post #322

Earlier quoted context omitted.

I agree. Based on my very subjective and limited experience (plus friends/colleagues), when it comes to producing solutions, what you get from AI is what you get from your 2-day hackathon—then you spend months making it production-ready. And your starry-eyed CEO is asking the same old question: How come everything takes so long when a 2-person team over two days was able to produce a shiny new thing?!. sigh Could be…

Yeah but you get the two days of hacking in 15 minutes. And I highly doubt you spend months, as in 5+ weeks at the least making it production ready. What even is "production readiness?" 100% fully unit tested and ready for planetary hyper scale or something? 95% of the human generated software I work on is awful but somehow makes people money.

First of all, you can rarely write down in English, what you want in 15 minutes… It’s even common to have longer specification, than its implementation. Just look at tests. Especially, if you want to do something which was never done before, the disparity can be staggering.

Claude Code for example is also not that quick at all. It produces some code quickly, but even scaffolding three hello world level example projects together definitely takes more than an hour. And that’s with zero novelty. The first version of code is done quickly, but the continuous loop of self corrections after that takes a long time. Even with Serena, Context7, and other MCPs.

And, of course, without real code review. That’s easily hours even with just few thousands lines of code, if it uses something which you don’t know. But I know that almost everybody gave up understanding “their” “own” code, during vibe coding. Even before AIs, it was a well known fact, that real code reviewing is hard, and people rarely did it.

AI can make you quicker in certain situations, but these “15 minutes” claims are totally baseless. This is one reason why many people are against AIs, vibe coding, etc. These stupid claims which cannot hold even the smallest scrutiny.

Re: A staff engineer's journey with Claude Code

#352
post #334

Earlier quoted context omitted.

You can do this with a custom filter list in Ublock Origin, no custom extension necessary.

I'm thinking something that would actually use HN's "Hide" feature, so other stories will populate the page after the AI ones are hidden. Is that something uBO could do?

You make a good point, I don't believe so. I currently block most LLM/AI threads and some pages can get quite sparse. Would love to check that out if you get around to putting that together!

Re: A staff engineer's journey with Claude Code

#354
post #342

Earlier quoted context omitted.

You could use an agentic AI coding tool to vibe code you one in minutes! /s

Honestly might give that a go, yeah. Brand new, low stakes, throwaway projects are one of the few things these tools are actually genuinely pretty useful for.

I agree. It may not be the most environmentally sensitive approach but throwaway one time tooling is a perfect use case.

Re: A staff engineer's journey with Claude Code

#355

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

> but this was true when they wrote their own code with stack overflow. Searching for solutions and integrating examples found requires effort that develops into a skill. You would rarely get solutions that would just fit into the codebase from SO. If I give a task to you and you produce a correct solution on the initial review I now know I can trust you to deal with this kind of problem in the future. Especially aft…

> So using LLMs as a junior you are just breaking my trust, and we both know you are not a competent reviewer of LLM code - why am I even dealing with you when I'll get LLM outputs faster myself ? This was my experience so far.

So much this. I see a 1000 lines super complicated PR that was whipped up in less than a day and I know they didn't read all of it, let alone understand.

Re: A staff engineer's journey with Claude Code

#357
post #82

Earlier quoted context omitted.

What you’re working on? In my industry it fails half of the time and comes up with absolute nonsense. The data just don’t exist for our problems, it can only work when you guide it and ask for a few functions at max.

This sounds like my experiences with it. I'm writing embedded firmware in C and Rust. I'd describe further, but Claude seems incompetent at all aspects of this space.

This. Every "AI is greate" response seems to be from someone doing web development - something I've intentionally avoided ever since I got tired of it around 2001, and hope to never have to do again.

We write C++ code in a very customized internal idiom to drive our hardware. Claude is great at filling in debugging statements / iterating over standard data structures to dump their contents, but not much else.

Re: A staff engineer's journey with Claude Code

#358

did this guy read that other paper about ai usage making people stupid? how long until he falls from staff engineer back down to senior or something less?

It's funny that the MIT paper HN is trending higher than this post, so it propped up before I read this article.

Re: A staff engineer's journey with Claude Code

#359

Earlier quoted context omitted.

The spec contains ambiguities and the code contains bugs. Clarifying ambiguities in the spec with stakeholders, allows one to reduce bugs in the code.

If you repeat this process until all ambiguities in the spec are eliminated, aren't you essentially left with code? Or at least something that looks more like code than plain English?

No

Re: A staff engineer's journey with Claude Code

#360

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

[deleted]
Post reply on HN