Live data from Hacker News

A few random notes from Claude coding quite a bit last few weeks

twitter.com

461–470 of 870 posts

Re: A few random notes from Claude coding quite a bit last few weeks

#461
post #11

> LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. I’ve always said I’m a builder even though I’ve also enjoyed programming (but for an outcome, never for the sake of the code) This perfectly sums up what I’ve been observing between people like me (builders) who are ecstatic about this new world and programmers who talk about the craft of programming…

I like building, but I don't fool myself into thinking it can be done by taking shortcuts. You could build something that looks like a house for half the cost but it won't be structurally sound. That's why I care about the details. Someone has to.

Re: A few random notes from Claude coding quite a bit last few weeks

#462
post #438

Earlier quoted context omitted.

Have you ever learnt a foreign language (say Mongolian, or Danish) and then never spoken it, nor even read anything in it for over 10 years? It is not like riding a bike, it doesn’t just come back like that. You have to actually relearn the language, practice it, and you will suck at it for months. Comprehension comes first (within weeks) but you will be speaking with grammatical errors, mispronunciations, etc. for m…

Anecdotally, i burned out pretty hard and basically didn't open a text editor for half a year (unemployed too). Eventually i got an itch to write code again and it didn't really feel like I was really worse. Maybe it wasn't long enough atrophy but code doesn't seem to quite work like language though ime.

Six months is definitely not long enough of a break for skills to degrade. But it's not just skills, as I wrote in another comment, the biggest thing is knowledge of new tools, new versions of language and its features.

I'd say there's at most around 2 years of knowledge runtime (maybe with all this AI stuff this is even shorter). After that period if you don't keep your knowledge up to date it fairly quickly becomes obsolete.

Re: A few random notes from Claude coding quite a bit last few weeks

#463

> 80% agent coding A lot of these things sound cool but sometimes I'm curious what they're actually building Like, is their bottleneck creativity now then? Are they building naything interedting or using agents to build... things that don't appeal to me, anyway?

I guess it depends what appeal to you.

As an example finding myself in a similar 80% situation, over the last few months I built

- a personal website with my projects and poems

- an app to rework recipes in a format I like from any source (text, video,...)

- a 3d visual version of a project my nephew did for work

- a gym class finder in my area with filters the websites don't provide

- a football data game

- working on a saas for work so typical saas stuff

I was never that productive on personal projects, so this is great for me.

Also the coding part of these projects was not very appealing to me, only the output, so it fits well with AI using.

In the meanwhile I did Advent of Code as usual for the fun of code. Different objectives.

Re: A few random notes from Claude coding quite a bit last few weeks

#464
post #318

Earlier quoted context omitted.

Haha, it has the human developer traits of thinking all old code is garbage, failing to identify oneself as the dummy who wrote this particular code, and wanting to start from scratch.

It's like NIH syndrome but instead "not invented here today ". Also a very human thing.

More like NIITS: Not Invented in this Session.

Re: A few random notes from Claude coding quite a bit last few weeks

#465
post #410

Earlier quoted context omitted.

I'm worried about that too. If the error is reproducible, the model can eventually figure it out from experience. But a ghost bug that I can't pattern? The model ends up in a "you're absolutely right" loop as it incorrectly guesses different solutions.

Are ghost bugs even real? My first job had the Devs working front-line support years ago. Due to that, I learnt an important lessons in bug fixing. Always be able to re-create the bug first. There are no such thing as ghost bugs, you just need to ask the reporter the right questions. Unless your code is multi-threaded, to which I say, good luck!

Historically I would have agreed with you. But since the rise of LLM-assisted coding, I've encountered an increasing number of things I'd call clear "ghost bugs" in single threaded code. I found a fun one today where invoking a process four times with a very specific access pattern would cause a key result of the second invocation to be overwritten. (It is not a coincidence, I don't think, that these are exactly the kind of bugs a genAI-as-a-service provider might never notice in production.)

Re: A few random notes from Claude coding quite a bit last few weeks

#466
post #360
post #65

I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency". Like there have been multiple times now where I wanted the code to look a certain way, but it kept pulling back to the way it wanted to do things. Like if I had stated certain design goals recently it would adhere to them, but after a few iterations it would forget again and g…

Honestly, this seems very much like the jump from being an individual contributor to being an engineering manager. The time it happened for me was rather abrupt, with no training in between, and the feeling was eerily similar. You know _exactly_ why the best solution is, you talk to your reports, but they have minds of their own, as well as egos, and they do things … their own way. At some point I stopped obsessing w…

The only issue is that as an engineering manager you reasonably expect that the team learns new things, improve their skills, in general grow as engineers. With AI and its context handling you're working with a team where each member has severe brain damage that affects their ability to form long term memories. You can rewire their brain to a degree teaching them new "skills" or giving them new tools, but they still don't actually learn from their mistakes or their experiences.

Re: A few random notes from Claude coding quite a bit last few weeks

#467

> You realize that stamina is a core bottleneck to work There has been a lot of research that shows that grit is far more correlated to success than intelligence. This is an interesting way to show something similar. AIs have endless grit (or at least as endless as your budget). They may outperform us simply because they don't ever get tired and give up. Full quote for context: Tenacity. It's so interesting to watch…

If you ever work with LLMs you know that they quite frequently give up. Sometimes it's a // TODO: implement logic or a "this feature would require extensive logic and changes to the existing codebase". Sometimes they just declare their work done. Ignoring failing tests and builds. You can nudge them to keep going but I often feel like, when they behave like this, they are at their limit of what they can achieve.

Using LLMs to clean those up is part of the workflow that you're responsible for (... for now). If you're hoping to get ideal results in a single inference, forget it.

Re: A few random notes from Claude coding quite a bit last few weeks

#468
post #100

Earlier quoted context omitted.

I noticed the same thing, but wasn't able to put it into words before reading that. Been experimenting with LLM-based coding just so I can understand it and talk intelligently about it (instead of just being that grouchy curmudgeon), and the thought in the back of my mind while using Claude Code is always: "I got into programming because I like programming, not whatever this is..." Yes, I'm building stupid things fas…

Funny you say that. Because I have never enjoyed management as much as being hands on and directly solving problems. So maybe our common ground is that we are direct problem solvers. :-)

For some reason this makes me think of a jigsaw puzzle. People usually complete these puzzles because they enjoy the process where on the end you get a picture that you can frame if you want to. Some people seem to want to get the resulting picture. No interest in process at all.

I guess that's the same people who went to all those coding camps during their hay day because they heard about software engineering salaries. They just want the money.

Re: A few random notes from Claude coding quite a bit last few weeks

#469
post #65

I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency". Like there have been multiple times now where I wanted the code to look a certain way, but it kept pulling back to the way it wanted to do things. Like if I had stated certain design goals recently it would adhere to them, but after a few iterations it would forget again and g…

> Eventually it was easier just to quit fighting it and let it do things the way it wanted. I wouldn't have believed it a few tears ago if you told me the industry would one day, in lockstep, decide that shipping more tech-debt is awesome. If the unstated bet doesn't pay off, that is, AI development will outpace the rate it generates cruft, then there will be hell to pay.

The industry decided that decades ago. We may like to talk about quality and forethought, but when you actually go to work, you quickly discover it doesn't matter. Small companies tell you "we gotta go fast", large companies demand clear OKRs and focusing on actually delivering impact - either way, no one cares about tech debt, because they see it as unavoidable fact of life. Even more so now, as ZIRP went away and no one can afford to pay devs to polish the turd ad infinitum. The mantra is, ship it and do the next thing, clean up the old thing if it ever becomes a problem.

And guess what, I'm finally convinced they're right.

Consider: it's been that way for decades. We may tell ourselves good developers write quality code given the chance, but the truth is, the median programmer is a junior with rapid growth of software industry itself. ~all production code in the past few decades was written by juniors, it continues to be so today; those who advance to senior level end up mostly tutoring new juniors instead of coding.

Or, all that put another way: tech debt is not wrong. It's a tool, a trade-off. It's perfectly fine to be loaded with it, if taking it lets you move forward and earn enough to afford paying installments when they're due. Like with housing: you're better off buying it with lump payment, or off savings in treasury bonds, but few have that money on hand and life is finite, so people just get a mortgage and move on.

--

Edited to add: There's a silver lining, though. LLMs make tech debt legible and quantifiable.

LLMs are affected by tech debt even more than human devs are, because (currently) they're dumber, they have less cognitive capability around abstractions and generalizations[0]. They make up for it by working much faster - which is a curse in terms of amplifying tech debt, but also a blessing, because you can literally see them slowing down.

Developer productivity is hard to measure in large part because the process is invisible (happens in people's heads and notes), and cause-and-effect chains play out over weeks or months. LLM agents compress that to hours to days, and the process itself is laid bare in the chat transcript, easy to inspect and analyze.

The way I see it, LLMs will finally allow us to turn software development at tactical level from art into an engineering process. Though it might be too late for it to be of any use to human devs.

--

[0] - At least the out-of-distribution ones - quirks unique to particular codebase and people behind it.

Post reply on HN