Item — HN Reader

Even if Claude writes 100% code, I think there will be a bifurcation between people who are finicky about 10 lines of code. And those finicky about high level product experiences.

I think the 10 lines of code people worry their jobs now become obsolete. In cases where the code required googling how to do X with Y technology, that's true. That's just going to be trivially solvable. And it will cause us to not need as many developers.

In my experience though, the 10 lines of finicky code use case usually has specific attributes:

1. You don't have well defined requirements. We're discovering correctness as we go. We 'code' to think how to solve the problem, adding / removing / changing tests as we go.

2. The constraints / correctness of this code is extremely multifaceted. It simultaneously matters for it to be fast, correct, secure, easy to use, etc

3. We're adapting a general solution (ie a login flow) to our specific company or domain. And the latter requires us to provide careful guidance to the LLM to get the right output

It may be Claude Code around these fewer bits of code, but in these cases its still important to have taste and care with code details itself.

We may weirdly be in a case where it's possible to single-shot a slack clone, but taking time to change the 2 small features we care about is time consuming and requires thoughtfulness.

3 comments

One of the first bugs I found - and fixed - at my current job instantly made us an extra 200k/year. One line of code (potentially a one character fix?), causing a little bug nobody noticed, which I only saw because I like to comb through application logs, and caused by a peculiarity of the data. Would an LLM have written better code? Maybe. But I've seen a lot of bad code churned out by LLMs, even today. I'm not saying every line matters - particular for frontend code - but sometimes individual lines of code, or even individual characters, can be tremendously important, and not be written in any spec, not tested with all possible data combinations, or documented anywhere. At a previous job, I spent several days unraveling another one-line bug that was keeping a multi-million dollar project from running at all. Again, totally non-obvious unless you had a tremendous amount of context and were running a pretty complex system to figure it out, with a sort of tenacity the LLMs don't currently possess.

> I think the 10 lines of code people worry their jobs now become obsolete.

I'm gonna assume you think you're in the other camp, but please correct me if I'm mistaken.

I'd say I'm in the 10 lines of code camp, but I'd say that group is the least afraid of fictionalized career threat. The people that obsess over those 10 lines are the same people who show up to fix the system when prod goes down. They're the ones that change 2 lines of code to get a 35% performance boost.

It annoys me a lot when people ship broken code. Vibe coded slop is almost always broken, because of those 10 lines.

I’m probably in the 10 lines of code camp

At the same time I make enough silly mistakes hand coding it feels irresponsible to NOT have a coding LLM generate code. But I look at all the code and (gasp) make manual changes :)

> I think there will be a bifurcation between people who are finicky about 10 lines of code. And those finicky about high level product experiences.

No ones care about a random 10 lines of code. And the focus of AI hypers on LoC is disturbing. Either the code is correct and good (allows for change later down the line) or it isn't.

> We may weirdly be in a case where it's possible to single-shot a slack clone, but taking time to change the 2 small features we care about is time consuming and requires thoughtfulness.

You do remember how easy it is to do `git clone`?

Nobody care until there’s an incident or security vulnerability, something doesn’t work based on some PMs assumptions of how it should work.

The question to me becomes whether the PM -> engineering handoff outdated? Should they be the same person? Does it collapse to one skillet for this work?

A PM describes the business needs. Engineering makes it a reality according to technical constraints. I've never seen a PM checking the code from engineering or investigating the root cause of an incident. And imagine being an engineer working on such a case and having to converse to consumers at the same time. That would be a very poor usage of resources.