alecbz

I think if you just look at what people like e.g. Sam Altman are doing it's clear that they don't believe everything that they're saying regarding AI safety.

nearly 100% of code would be written with AI in 2026

I feel like this is kind of a meaningless metric. Or at least, it's very difficult to measure. There's a spectrum of "let AI write the code" from "don't ever even look at the code produced" to "carefully review all the output and have AI iterate on it".

Also, it seems possible as time goes on people will _stop_ using AI to write code as much, or at least shift more to the right side of that spectrum, as we start to discover all kinds of problems caused by AI-authored code with little to no human oversight.

There's no need to tack on "because the wiki is open". That's still just part of a solution seeping into the statement of the problem.

I don't think this means "most concerns aren't valid", it's more "people aren't always good at vocalizing their underlying concerns, and instead treat a proposed solution as the concern".

Those sound like proposed solutions, not the underlying concerns. Motivating concerns here might be things like "our wiki will be full of inaccurate info", "people will unknowingly install spyware".

I don't know that you can establish objectively if someone is a good writer. He's an acclaimed, award-winning writer, sure.

Yeah I think the lesson is that specific suggestions for what to do aren't as helpful as just hearing how someone else experienced your work, and then drawing your own conclusions about how to fix that.

Bug reports should describe the problem but often shouldn't try to prescribe a solution.

How can you tell the difference?

I don't think parliamentary systems help the legislature remain effective, since they're still elected in roughly the same way, no?

But yeah, it prevents an ineffective legislature from leading to strong-men, which does seem nice. :)

if enough people want to willing vote in a corrupt president

Why do people do this though? Maybe it's inevitable, but I think there was a lot of pent up frustration with the government that led a lot of people to just say "fuck it". Not really excusing it (especially for his second term), but I feel like we're reaping years and years of a dysfunctional and ineffectual congress. Not that that's an especially easy problem to solve either.

I think this also explains a lot of the frustration with SCOTUS. In-theory, SCOTUS is supposed to just interpret and flesh out the policies decided on by congress. In practice, congress doesn't really do anything, and people started depending on SCOTUS's ability and willingness to make far-reaching and impactful decisions. Now a more conservative SCOTUS isn't doing that.

Although [touch typing] refers to typing without using the sense of sight to find the keys ... the term is often used to refer to a specific form of touch typing that involves placing the eight fingers in a horizontal row along the middle of the keyboard (the home row) and having them reach for specific other keys.

https://en.wikipedia.org/wiki/Touch_typing

I think they're referring to the latter.

Say more.

Craft, in coding or anything else, exists for a reason. It can bleed over into vain frivolity, but craft helps keep the quality of things high.

Craft often inspires a quasi-religious adherence to fight the ever-present temptation to just cut this one corner here real quick, because is anything really going to go wrong? The problems that come from ignoring craft are often very far-removed from the decisions that cause them, and because of this craft instills a sense of always doing the right thing all the time.

This can definitely go too far, but I think it's a complete misunderstanding to think that craft exists for reasons other than ensuring you produce high-quality products for users. Adherents to craft will often end up caring about the code as end-goal, but that's because this ends up producing better products, in aggregate.

A "deep" tool that fully automates fairly specific tasks works this way. LLMs are more of a "shallow", general tool that can partially help with lots of different things, but none so completely that they alleviate the need for human involvement in them.

If the 1% is just a bit less efficient with the new tech, sure, but it's different if the 1% means your car crashes.

Sure -- I think articles like this are a warning that the skills we're losing are likely _not_ so completely supplanted by AI that they'll soon be irrelevant.

A car that can self-drive 100% of the time is a new tool that could make driving an obsolete skill. A car that can self-drive successfully 99% of the time is dangerous because it trains people to not be ready to take over for the 1% they need to.

Big Tech is not the same thing as all technology.

I'm sure some companies do this poorly but there's lots of places where code review happens on every PR and there's processes and systems in place to make sure it's an easy process (or at least, as easy as it should be). Many large tech companies have things pushed to prod automatically many, many times per day and still have code review for all changes going out.

sure, they coined the term “move fast and break things”

Yeah I'm aware, but as any company gets larger and has more and more traffic (and money) dependent on their existing systems working, keeping those systems working becomes more and more important.

There's lots of things worth protecting to ensure that people keep using your product that fall short of "lives are at stake". Of course it's a spectrum but lots of large enterprises that aren't saving lives but still care a lot about making sure their software keeps running.

There's a lot of software in between Air Traffic Controller and Facebook. And honestly would Meta be okay with Instagram or Facebook going down even for just a few minutes? I'd think at this point that'd be considered a fairly severe incident.

Even if we ignore criticality, things just get really messy and confusing if you push a bunch of broken stuff and only try to start understanding what's actually going on after it's already causing issues.

Yeah in many places we had two humans with context on every line, and now we're advocating going to zero?

How do you know which lines you need to review and which you don't?

Does it feel archaic because LLMs are clearly producing output of a quality that doesn't require any review, or because having to review all the code LLMs produce clips the productivity gains we can squeeze out of them?

Yeah performance optimization is potentially another good area for LLMs to shine, if you already have a sufficiently comprehensive test suite, because no functionality is changing. But if functionality is changing, you need to be in the loop to, at the very least, review the tests that the LLM outputs. Sometimes that's easier than reviewing the code itself, but other times I think it requires similar levels of context.

But honestly I think sane code organization is the bigger hurdle, which is a lot harder to get right without manual oversight. Which of course leads to the temptation to give up on reviewing the code and just trusting whatever the LLM outputs. But I'm skeptical this is a viable approach. LLMs, like human devs, seem to need reasonably well-organized code to be able to work in a codebase, but I think the code they output often falls short of this standard.

(But yes agree that getting the LLM to iterate until CI passes is table-stakes.)

The best experiences I have are those where I can describe what I want done with details.

But that's the hard part! You can only eke out moderate productivity gains by automating the tedium of actually writing out the code, because it's a small fraction of software engineering.

Stuff like this works for things that can be verified programmatically (though I find LLMs still do occasionally ignore instructions like this), but ensuring correct functionality and sensible code organization are bigger challenges.

There are techniques that can help deal with this but none of them work perfectly, and most of the time some direct oversight from me is required. And this really clips the potential productivity gains, because in order to effectively provide oversight you need to page in all the context of what's going on and how it ought to work, which is most of what the LLMs are in-theory helping you with.

LLMs are still very useful for certain tasks (bootstrapping in new unfamiliar domains, tedious plumbing or test fixture code), but the massive productivity gains people are claiming or alluding to still feel out of reach.

It's good at writing/updating tedious test cases and fixtures when you're directing it more closely. But yes, it's not as great at coming up with what to test in the first place.

I'm still choosing to believe this is all a joke.

If AI makes people more productive then labor is cheaper than it was pre-AI, even at pre-AI salaries, because you're getting more done at the same cost.

All words in a thesaurus would generally also be in a dictionary? The difference between a thesaurus and a dictionary is what each tells you about a word.

"to be" is a very weird example because that's just the full infinitive of "be" which is definitely in dictionaries: https://www.merriam-webster.com/dictionary/be