hombre_fatal

Attacks have been distributed for quite some time if your service has any loot worth attacking. You have to handle the case where every request comes from a unique IP address.

Well, I’d say LLMs scale up the underlying starting point.

It’s still shocking to me pre-AI how often people would ship code they didn’t bother to run once, relying on some QA stage to report an issue.

With AI the solution to it is also trivial since an extra three seconds spent writing a prompt could have had the agent run and verify it.

> That’s the problem, these tests can’t tell you how good a model is anymore because it’s trivial for labs to optimise for exactly these tests by the next release.

But they don't prove the claim. Are the models amazing at recreating Minecraft, but the second you swap the word Minecraft out with another game or a custom game, it shits the bed?

That's not what I see. My feed is full of people using Astra to recreate all sorts of games from Diablo to some random idea they came up with, in ridiculously polished detail like animations that would have taken me weeks of iteration in gpt-5.6-sol but it was a single shot by Astra.

Orwell's bad sentence uses harder words than it needs to, but it reworks the bible verse into direct claims.

Needing better reading skills to understand the bible verse just shows that it's not a good way to communicate. If an HNer wrote like the bible verse, you'd find them insufferably ostentatious. Just like you wouldn't want Claude to use literary flair when you're asking why your production database stopped working.

If you dumb down Orwell's sentence back to simpler terms, it's a point much better communicated than the bible verse.

Frankly the bickering in this thread is due to the original HN comment choosing a bad comparison because both sentences are poorly communicated for different reasons in this context: you wouldn't want Claude to write either.

Good questions.

> why did it write so much to begin with?

It's an incremental project covering a complex domain. At any time, the code has to stay balanced in a spot that addresses correctness and performance across things like pty parsing, a terminal grid, stateful pty behavior, rendering, scrollback history, font glyphs, and like all software there is a fractal of idiosyncrasies that sprout up. And that's just the terminal side.

Unless you can see the future, like most software, so much of the project is trying things and seeing what happens at the periphery, like how to represent "row damage" and apply it in a way that works with macOS Core Graphics and 1000 other things.

e.g. Can you tell me off the top of your head what the trade-offs are of representing the terminal contents/scrollback as a pre-wrapped grid vs. a list of logical lines that are soft-wrapped on the fly? Did you enumerate them all and correctly weigh them such that you can pick the ideal solution ahead of time? No. You just kinda make educated decisions and find out in practice what the exact weight of the trade-offs are.

You should see the amount of iterations a human needs on these kinds of projects. https://github.com/ghostty-org/ghostty has almost 18,000 commits. So does https://github.com/gnachman/iterm2. So does https://github.com/kovidgoyal/kitty.

> why do you assume that now there's no more debt?

I don't. Like all software, you try to ratchet into better and better positions, and you try to come up with metrics that can tell you "You are here" with regard to rather fuzzy goals like "it should be correct and performant and nice to use".

But I can look at individual findings and their solution to go "yes, this improves the code." And on principle I think that, e.g. correct/DRY/simple by-construction is superior to by-convention, and I assume it helps future agents reason about the system and make future edits, and it gives them singular places to make changes that impact multiple components just like it would a human. But how much did it actually matter?

Because we have evidence otherwise, and even the worst code can be refactored by LLMs.

That a high velocity project might accumulate technical debt isn't interesting to me if LLMs can also pay it back or if you can decide to work at a different pace where you polish the architecture as you go instead of accumulating debt.

I'd make the opposite claim to you: people really don't want my claims to be true, probably because it robs us of our value and expertise as software engineers. But it's getting a bit late in the game to still be dancing around that pill to swallow.

Like real life, you want to accrue debt strategically.

When you're experimenting, vetting ideas, mapping out the requirements, exploring solutions, then technical debt keeps churn cheap.

e.g. You don't want to overly commit to static types that keep "impossible state unrepresentable" too early on since you aren't even sure yet what impossible state looks like in the system.

So we regard debt repayment as some sort of transformation we'll do in the future that never comes because it's hard and expensive, but not to LLMs.

I did. Just about all of the findings were re-verified to be good and then implemented by a rigorous pipeline of clankers, and the project was improved.

If it weren't for me insisting that I manually sign off on the solution of every finding, then it would have been fully automated too.

How? Because it found too many opportunities to improve the code beyond what we'd want to review as a human?

Each file is a list of findings that includes the justification/verification of each finding in the same file.

This is just what work looks like, especially tech debt repayment. It's analysis, reasoning, and justification. Those produce words.

Trivially debunked with the prompt "find technical debt to fix".

https://github.com/danneu/danterm/blob/749942ffa1198f520c8b7...

Here's the result of a prompt that specifically looks for correctness and simplifications to make "by construction" before I added "Design bar: ensure correctness by construction rather than by convention" to AGENTS.md:

https://github.com/danneu/danterm/blob/749942ffa1198f520c8b7...

This is a good example of what LLMs save us from.

Everyone likes to pretend that LLMs are only capable of writing mudballs, but it's trivially debunked by using LLMs yourself to refactor code, pay back debt, and fan out agents to look for debt to repay.

We're already at the point with sota models where I'm not even sure you can get the sort of mudballs OP is talking about; the LLM's inherent "taste" forbids it, and it can just end-to-end refactor as requirements change.

The hypermudballs were distinctly a human creation due to how expensive it is to generalize and refactor brittle, incremental production code.

I can’t imagine how many shortcuts I would have taken as a kid/teen or stressed uni student if AI were an option.

I can see even a well-meaning student stuck in this aspirational cycle of “I’ll do it myself next time, but right now I just want to catch up.”

I don't think there's always obvious linearity with learning, especially not these days where you have more options vs. elders copying programs from magazines line by line or however the legend goes.

How responsible was fiddling with vbulletin/phpbb forum plugins in my eventual career, one of the first things I remember doing and for quite a long time?

I have no idea, and it was just one of the various things I did as a noob, none of them with an impact particularly memorable. There were a bunch of nodes in a daisy chain of things I tried out, and over time I could take on bigger and bigger projects with fewer and fewer rails.

I like a lightweight ADR system.

e.g. docs/decisions/README.md (index with a blurb about each decision), docs/decisions/01-some-lesson.md (some architectural decision/pattern that you or the agents discovered).

ADR files have important sections like "rejected solutions" and "acceptable risks", and they're live files that can be refined and pivoted over time or retired to docs/decisions/archive/.

It's also nice to give each top-level bullet point some stable ID like "R1" for rejected solution #1, I3 for invariant #3. Agents use this stuff intelligently all the time like "This could be a time to reconsider D4/R2" = ADR #4, rejected solution #2.

The essential part being that your system ratchets into increasingly better decisions and invariants over time, and there's a place to actually put this stuff.

It's essential for automating high-quality software and something we couldn't be arsed to do much less update before AI.

LLMs change this since you can get them to create a wrapper for some software you want based on a hash, and then bump it when you want to update it.

The end goal is that you have a reproducible, immutable build contained in some git-diffed config files which is all I want.

And it becomes especially nice when you have a single repo that configures all the machines you use, from your macOS laptop to your remote servers, with common config/programs shared between them.

Whether anyone else offers a nix/flake/HM version of their software barely moves the needle on utility of this setup.

That's what delegation looks like, but it needs a better process.

They could be committing plan files alongside any nontrivial change to application code, and the plan file can have everything you'd care about, like the invariants it held to and why, the rejected ideas and why, the acceptable risks and why, etc.

This is solved by better usage of LLMs, not less.

The divide to me isn't engineering skill vs those who lost it, it's people who care vs. those who don't care. It's a higher level thing now that we're working at a higher level (delegation).

Agreed, but what "prevents" it is that making a good keyboard-driven UI takes a lot of taste, extra effort to build it, and it must be revisited any time the UI changes. It's duplicated work.

Ideally all GUIs/TUIs are usable with keyboard and mouse independently.

A good example of this is when you have a fancy keyboard-driven workflow yet you can't even do the most trivial task without placing two hands on your keyboard. Sometimes I just want to reach over and do it with one hand on the trackpad.

You still need the organizational conditions (the will, structure, processes) for someone to care, do, approve, and land the solution.

The missing part of this is that verifying the bug with LLMs is also easy, and so is adversarially reviewing the proposed fix with LLMs.

The only thing left for you to do should be directional decisions. The LLMs should pause and rope you in if the fix involves directional/invariant changes.

I'd consider embracing to include developing expertise in the tool.

The mental model was required when your brain was the only chance to reason about changes, answer cross-cutting questions (architecture), and develop a visceral feel for the project, because that's what you needed to write high quality software

It's hard to let that go, but you already had to in larger human organizations/collaborations where you might be assigned work on systems you never/seldom touch, or coming back to a project you haven't touched in a long time.

You don't need a mental model when you can automate the reasoning and the benchmarks that vet the reasoning. Your mental model is better spent pondering->reconsidering high level things like invariants, and then automating the the proof and implementation of those decisions.

Consider how you can just get Claude to start a workflow of 15 Fable agents to fan out over your system looking for correction/simplification/perf opportunities before spawn another wave of agents to vet the list of findings. How much time and energy and studying of the code would it have taken you to build and vet the same list?

It's pretty amazing what you can do when you embrace LLMs, figure out how to build one high-quality rigorous project with them, and then start working on more projects.

You become a machine with your workflow, once again limited only by your time/energy, tokens, and your discretion on how to spend it.

LLMs benefit from knowing the why, the intent, and the reason/justification for code to exist, too.

Catching code desyncing from it is a valuable place to reconsider assumptions and maybe even invariants.

Yeah, I feel you.

A lot of my nonchalance here is from dealing with an immense sense of loss for the end of my identity-level skillset/profession, then acceptance, then deciding to push the envelope on AI-generated software to see what I can pull off since the start of this year.

Focusing on creating things that I want has been an antidote to the melange/uncertainty for the future.

It's insane how it takes advantage of good people who feel like they're doing something wrong for hitting "no tip" in settings where nobody was asked to tip just 5-10 years ago.

Is it: "How do you know the solution is good?"

Because I can still reason and dig into things and ask questions and have the domain explained to me out of curiosity, the same way I could build anything that was originally out of my depth.

But what I've noticed is that the need for any corrective power has gone or is going to nil and I'm mainly doing directional work. And even then, I can constantly have sota models "rank the top options and recommend one", and it's almost always the right way forward.

I used to read every line of every plan that LLMs generated, but over time I've realized I have less and less to correct or, more impressively, the LLM had foresights I never considered. The same thing happens with implementation.

Periodically I can spawn a bunch of agents to evaluate the system adversarially to find improvements, and the findings have been so good that it's evident that soon I can just automate that too.

In other words, the skills I need to excel here are more curiosity and patience than tech expertise -- the things that got me into software engineering in the first place since that was the only way to build things.

While true, I'm not sure it matters.

It kinda seems like wishful thinking on our part as software engineers that one day we'll be able to go "Hah, miss me now?" but that just isn't the writing that I see on the wall.

Over the past year, I've AI-generated two large pieces of software over 2000 commits without having much depth in either domain, and my ability to deliver value as a veteran software engineer has only shrunk over the months or it can be trivially extracted into a reusable markdown file like "design bar: ensure things 'by construction' where possible", a lesson I learned viscerally over decades.

Lots of small fs operations on macOS is apparently rough.

I use nix on macOS and any time it's making changes to /nix/store, the Finder and fsevents processes peg cpu.

IIRC his video shows fs-heavy ops like file deltions and pnpm install taking much longer on a macbook despite better specs.

Frankly, things like the lack of a universal cmd-c/v clipboard on linux has been 1000x worse for usability than slower bulk fs.

There's some hyperbole but his point is obvious to me from hanging out in forums and IRC channels over the years, or reading snarky "umm, I'm confused...?" quote-tweets for certain Omarchy posts about how Omarchy is just quickshell hyprland rice.

I used to use an old omakase version of Debian called Crunchbang in uni (https://crunchbang.org/) and there was always someone around to make the remark that you'd only use it if you couldn't read manpages.

Or Dropbox seems pointless because you can build it trivially by mounting an ftp location with curlftpfs + svn.

For a single document like a blog post it should be easy, though you don't have to sub a famous author in for X.

There are all sorts of ways to do it though, like pointing it to an example doc.