Live data from Hacker News

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

twitter.com

801–810 of 870 posts

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

#801

Earlier quoted context omitted.

The respect is unwarranted. He ran Teslas ML division, but still doesnt know what a simple kalman filter is (in the sense where he claimed that lidar would be hard to integrate with cameras).

The Kalman filter examples I've seen always involve estimating a very simple quantity, like the location of a single 3D point, from noisy sensors. It's clear how multiple estimates can be combined into a new estimate. I'd guess that cameras on a self-driving car are trying to estimate something much more complex, something like 3D surfaces labeled with categories ("person", "traffic light", etc.). It's not obvious to…

https://www.bzarg.com/p/how-a-kalman-filter-works-in-picture...

Kalman filters basic concept is essentially this.

1. make prediction on the next state change of some measurable n dimentional quantity, and estimate the covariance matrix across those n dimentions, which describe essentially a probability that the i-th dimention is going to increase (or decrease) with j-th dimention, where i and j are between 0 and n (indices of the vector)

2. Gather sensor data (that can be noisy), and reconcile the predicted measurement with the measured to get the best guess. The covariance matrix acts as a kind of weight for each of the elements

3. Update the covariance matrix based on the measurements in previous step.

You can do this for any vector of numbers. For example, instead of tracking individual objects, you can have a grid where each element represents a physical object that the car should not drive into, with a value representing certainty of that object being there. Then when you combine sensor reading, you still can use your vision model but that model would be enhanced by what lidar detects, both in terms of seeing things that camera doesn't pick up and rejecting things that aren't there.

And the concept is generic enough to where you can set up a system to be able to plug in any additional sensor with its own noise, and it all works out in the end. This is used all the You can even extend the concept past Gaussian noise and linearity, there are a number of other filters that deal with that, broadly under the umbrella of sensor fusion.

The problem is that Karpathy is more of a computer scientist, so he is on his Code 2.0 train of having ML models do everything. I dunno if he is like that himself or Musks "im smarter than everyone else that came before me" rubbed off.

And of course when you think like that, its going to be difficult to integrate lidar into the model. But the problem with that thinking is that forward inference LLM is not AI, and it will never ever be able to drive a car well compared to a true "reasoning" AI with feedback loops.

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

#802
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 feel like this is the core issue that will actually stall LLM coding tools short of actually replacing coding work at large.

'Coders' make 'builders' keep the source code good enough so that 'builders' can continue building without breaking what they built.

If 'builders' become x10 productive and 'coders' become unable to keep up with unsurmountable pile of unmaintainable mess that 'builders' proudly churn out, 'bullders' will start to run into impossibility to build further without starting over and over again hoping that agents will be able to get it right this time.

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

#803

Earlier quoted context omitted.

Socrates was right about the effects. Writing did indeed cause us to loose the talent of memorizing. Where he was wrong though (or rather where this quote without context is wrong) is that it turned out that memorizing was by the most part not the important skill to have. When Socrates uses the same warnings about LLMs he may however be correct both on the effect and the importance of the skill being lost. If we loos…

While there are dangers to LLMs -science fiction has been talking about this issue for decades (see below) and I think its overblown and the point of the Socrates quote is valid. e.g the Matrix Reloaded: https://youtu.be/cD4nhYR-VRA?si=bXGBI4ca-LaetLVl&t=69 Machines no one understand or can manage Issac Asmiov's Classic - the Feeling of Power https://ia600806.us.archive.org/20/items/TheFeelingOfPower/T... (future sci…

I’m not making a Malthusian doomsday prediction, and neither was Socrates for that matter. Jobs need to be done, and there will always be somebody willing and able to acquire the relevant skills, and do the job. And in the worst case scenario, society will change it self before it is allowed to fail.

Unlike Malthus, for whom it was easier to imagine the end of the world then the end of Mercantilism, I can easily imagine a world which simply replaces capitalism as its institutions start producing existential threats for humanity.

However, I don‘t think LLMs are even that, for me they are an annoyance which I personally want gone, but next to climate change and the stagnation of population growth, they wont make a dent in upending capitalism, despite how much they suck.

But just because they are not an existential threat, that doesn’t make them harmless. Plenty of people will be harmed by this technology. Like Socrates predicted people will lose skills, this includes skilled programmers, and where previously we were getting some quality software, instead we will get less of it, replaced with a bunch of AI slop. That is my prediction at least.

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

#804
post #501

Earlier quoted context omitted.

Are you using Opus 4.5? Sounds more like Sonnet.

Yes I'm using Sonnet 4.5. Thanks for the tip, will try Opus 4.5, although costs might become an issue.

> although costs might become an issue.

If you have a ChatGPT subscription, try Codex with GPT-5.2-High or 5.2-codex High? In my experience, while being much slower, it produces far better results than Opus and seems even more aggressively subsidized (more generous rate limits).

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

#805

Earlier quoted context omitted.

I ran into a new problem today: "reading atrophy". As in if the LLM doesn't know about it, some devs are basically giving up and not even going to RTFM. I literally had to explain to someone today how something works by...reading through the docs and linking them the docs with screenshots and highlighted paragraphs of text. Still got push back along the lines of "not sure if this will work". It's. Literally. In. The.…

As someone working in technical support for a long time, this has always been the case. You can have as many extremely detailed and easy to parse gudies, references, etc. there will always be a portion of customers who refuse to read them. Never could figure out why because they aren't stupid or anything.

> Never could figure out why because they aren't stupid or anything.

They may be intelligent, but they don't sound wise.

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

#806
post #284

Earlier quoted context omitted.

You will get a different bridge. With very different technology. Same as "I can't repair my grandfather clock cheaply". In general, there are several things that are true for bridges that aren't true for most technology: * Technology has massively improved, but most people are not realizing that. (E.g. the Bay Bridge cost significantly more than the previous version, but that's because we'd like to not fall down agai…

> But sure, the cost of "one bridge, please" has gone up over time. Even if you adjust for inflation?

Depends, do we care about TCO? Also, can I pick the set of bridges I compare?

OK, kidding aside: If you deeply care, you can probably mine the Federal Highway Administration's bridge construction database: https://fhwaapps.fhwa.dot.gov/upacsp/tm?transName=MenuSystem...

I don't think the question is answerable in a meaningful way. Bridges are one-off projects with long life spans, comparing cost over time requires a lot of squinting just so.

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

#807

Earlier quoted context omitted.

I am a devops engineer and understand your point. But there's a huge difference: legacy code doesn't change. Yeah occasionally something weird will happen and you've got to dig into it, but it's pretty rare, and usually something like an expired certificate, not a logic bug. What we're entering, if this comes to fruition, is a whole new era where massive amounts of code changes that engineers are vaguely familiar wit…

after a decade of follow-the-sun deployments by php contractors from vietnam to costa rica where our only qa was keeping an eye on the 500s graph, ai can't scare me.

That's actually a good comparison. Though even then, I imagine you at least have the ability to get on the phone and ask what they just did. Whereas LLM would just be like, "IDK, that was my twin brother. I'd ask him directly, but unfortunately he has been garbage collected. It was very sad. Would you like a cookie?"

I wonder if there's any value in some system that preserves the chat context of a coding agent and tags the commits with a reference to it, until the feature has been sufficiently battle tested. That way you can bring them back from the dead and interrogate them for insight if something goes wrong. Probably no more useful than just having a fresh agent look at the diff in most cases, but I can certainly imagine scenarios where it's like "Oh, duh, I meant to do X but looks like I accidentally did Y instead! Here's a fix." way faster than figuring it out from scratch. Especially if that whole process can be automated and fast, worst case you just waste a few tokens.

I'm genuinely curious though if there's anything you learned from those experiences that could be applied to agent driven dev processes too.

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

#808
post #778

Earlier quoted context omitted.

"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they…

It's unclear if you've presented this quote in order to support or criticize the idea that new technologies make us dumber. (Perhaps that's intentional; if so, bravo). To me, this feels like support. I was never an adult who could not read or write, so I can't check my experience against Socrates' specific concern. But speaking to the idea of memory, I now "outsource" a lot of my memory to my smartphone. In the past,…

I don‘t think human memory works like that, at least not in theory. Storage is not the limiting factor of human memory, but rather retention. It takes time and effort to retain new information. In the past you spent some time and effort to memorize the shopping list and the phone number. Mulling it over in your mind (or out loud), repeated recalls, exposure, even mnemonic tricks like rhymes, alliterations, connecting with pictures, stories, etc. if what you had to remember was something more complicated/extensive/important. And retention is not forever, unless you repeat it, you will loose it. And you only have so much time for repetition and recall, so inevitably, there will be memories which won‘t be repeated, and can’t be recalled.

So when you started using technology to offload your memory, what you gained was the time and effort you previously spent encoding these things into your memory.

I think there is a fundamental difference though between phone book apps and LLMs. Loosing the ability to remember a phone number is not as severe as loosing the ability to form a coherent argument, or to look through sources, or for a programmer to work through logic, to abstract complex logic into simpler chunks. If a scholar looses the skill to look through sources, and a programmer looses the ability to abstract complex logic, they are loosing a fundamental part of their needed to do their jobs. This is like if a stage actor looses the ability to memorize the script, instead relying on a tape-recorder when they are on stage.

Now if a stage actor losses the ability to memorize the script, they will soon be out of a job, but I fear in the software industry (and academia) we are not so lucky. I suspect we will see a lot of people actually taking that tape recorder on stage, and continue to do their work as if nothing is more normal. And the drop in quality will predictably follow.

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

#809
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…

"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they…

And so we learn that over 2000 years before the microphone came to be, Socrates invented the mic drop.

In all seriousness though, it's just crazy that anybody is thinking these things at the dawn of civilization.

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

#810
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 feel like this is the core issue that will actually stall LLM coding tools short of actually replacing coding work at large. 'Coders' make 'builders' keep the source code good enough so that 'builders' can continue building without breaking what they built. If 'builders' become x10 productive and 'coders' become unable to keep up with unsurmountable pile of unmaintainable mess that 'builders' proudly churn out, 'bu…

"Coders" can code tools that programmatically define quality. We have like 80% of those already.

Then force the builders to use those tools to constrain their output.

Post reply on HN