Live data from Hacker News

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

twitter.com

711–720 of 870 posts

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

#711

Earlier quoted context omitted.

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!

> Unless your code is multi-threaded, to which I say, good luck! What isn't multi-threaded these days? Kinda hard to serve HTTP without concurrency, and practically every new business needs to be on the web (or to serve multiple mobile clients; same deal). All you need is a database and web form submission and now you have a full distributed system in your hands.

nginx is single–threaded, but you're absolutely right — any concurrency leads to the same ghost bugs.

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

#712

Earlier quoted context omitted.

It's not just brain atrophy, I think. I think part of it is that we're actively making a tradeoff to focus on learning how to use the model rather than learning how to use our own brains and work with each other. This would be fine if not for one thing: the meta-skill of learning to use the LLM depreciates too. Today's LLM is gonna go away someday, the way you have to use it will change. You will be on a forever trea…

> the meta-skill of learning to use the LLM depreciates too. Today's LLM is gonna go away someday, the way you have to use it will change. You will be on a forever treadmill, always learning the vagaries of using the new shiny model (and paying for the privilege!) I haven’t found this to be true at all, at least so far. As models improve I find that I can start dropping old tricks and techniques that were necessary t…

Interesting, I’ve experienced the opposite in certain contexts. CC is so hastily shipped that new versions often imbalance existing workflows. E.g. people were raving about the new user prompt tools that CC used to get more context but they messed my simple git slash commands

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

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

Yup.

My personal counterpoint is Norman's thesis in Things That Make Us Smart.

I've long tried, and mostly failed, to consider the tradeoffs, to be ever mindful that technologies are never neutral (winners & losers), per Postman's Technopoly.

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

#714

Earlier quoted context omitted.

One challenge is, are those decisions making tangible differences? We won't know until the code being produced especially greenfields hits any kind of maturity 5 years+ atleast?

What? Of course it makes a difference when I direct it away from a bad solution towards a good solution. I know as soon as I review the output and it has done what I asked, or it hasn't and I make a correction. Why would I need to wait 5 years? That makes no sense, I can see the output. If you're using LLM's and you don't know what good/bad output looks like then of course you're going to have problems, but such a pe…

The problem is the LLMs are exceptionally good at producing output that appears good.

That's what it's ultimately been tuned to do.

The way I see this play out is output that satisfied me but that I would not produce myself.

Over a large project that adds up and typically is glaringly obvious to everyone but the person who was using the LLM.

My only guess as to why that is, is because most of what we do and why we do it we're not conscious of. The threshold we'd intervene at is higher than the original effort it takes to do the right thing.

If these things don't apply to you. Then I think you're coming up to a golden era.

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

#715

Earlier quoted context omitted.

> Unless your code is multi-threaded, to which I say, good luck! What isn't multi-threaded these days? Kinda hard to serve HTTP without concurrency, and practically every new business needs to be on the web (or to serve multiple mobile clients; same deal). All you need is a database and web form submission and now you have a full distributed system in your hands.

nginx is single–threaded, but you're absolutely right — any concurrency leads to the same ghost bugs.

nginx is also from the era when fast static file serving was still a huge challenge, and "enough to run a business" for many purposes -- most software written has more mutable state, and much more potential for edge cases.

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

#716

Earlier quoted context omitted.

> I feel like most apps at most companies can just build an app and deploy it using some modern paas-like thing. Most companies (in the global, not SV sense) would be well served by an app that runs in a Docker container in a VPS somewhere and has PostgreSQL and maybe Garage, RabbitMQ and Redis if you wanna get fancy, behind Apache2/Nginx/Caddy. But obviously that’s not Serious Business™ and won’t give you zero downt…

> Most companies (in the global, not SV sense) would be well served by an app that runs in a Docker container in a VPS somewhere and has PostgreSQL and maybe Garage, RabbitMQ and Redis if you wanna get fancy, behind Apache2/Nginx/Caddy. That’s still too much complication. Most companies would be well served by a native .EXE file they could just run on their PC. How did we get to the point where applications by defaul…

> How did we get to the point where applications by default came with all of this shit?

Because when you give your clients instructions on how to setup the environment, they will ignore some of them and then they install OracleJDK while you have tested everything under OpenJDK and you have no idea why the application is performing so much worse in their environment: https://blog.kronis.dev/blog/oracle-jdk-and-openjdk-compatib...

It's not always trivial to package your entire runtime environment unless you wanna push VM images (which is in many ways worse than Docker), so Docker is like the sweet spot for the real world that we live in - a bit more foolproof, the configuration can be ONE docker-compose.yml file, it lets you manage resource limits without having to think about cgroups, as well as storage and exposed ports, custom hosts records and all the other stuff the human factor in the process inevitably fucks up.

And in my experience, shipping a self-contained image that someone can just run with docker compose up is infinitely easier than trying to get a bunch of Ansible playbooks in place.

If your app can be packaged as an AppImage or Flatpak, or even a fully self contained .deb then great... unless someone also wants to run it on Windows or vice versa or any other environment that you didn't anticipate, or it has more dependencies than would be "normal" to include in a single bundle, in which case Docker still works at least somewhat.

Software packaging and dependency management sucks, unless we all want to move over to statically compiled executables (which I'm all for). Desktop GUI software is another can of worms entirely, too.

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

#717
post #654

Earlier quoted context omitted.

We are very clearly living through a moment in history that will be studied intensely for thousands of years.

Because of the collapsing empire, mind you, not because of the LLMs.

Creation of the internet, social media, everyone on the planet getting a pocket sized supercomputer, beginning of the AI boom, Trump/beginning of the end of the US, are all reasons people will study this period of time.

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

#718

Earlier quoted context omitted.

> Vendors of small utilities could be in trouble. For example I needed to cut out some pages from a pdf. I could have found a tool online(I’m sure there are several), write one myself. However, Claude quickly performed the task. Definitely. Making small, single-purpose utilities with LLMs is almost as easy these days as googling for them on-line - much easier, in fact, if you account for time spent filtering out all…

Whatever happened to just typing "apt install qrencode"? It's definitely "fast, reliable, free of surveillance economy bullshit, and doesn't employ URL shorteners".

Users can't use command–line tools. They just can't. It has to be user–friendly or it doesn't exist.

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

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

> > LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. This is much less significant than the fact LLMs split engineers on those who primarily like quality v. those who primarily like speed.

That split has always existed. LLMs can be used on either side of the divide.

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

#720

Is it really brain atrophy if I never learned to code in ASM in my entire career as compiler has been doing that for me? A part of me really want to say yes and wear it as a badge to have been coding before LLMs were a thing, but at the same time, it's not unprecedented.

Is it muscle atrophy if you were a weakling since birth? Is it retina degeneration if you were born blind? No, because atrophy is a loss of a prior strength, and not an ever–existing weakness, but it's just as bad.
Post reply on HN