There's a few of my friends in tech for whom AI has obviously massively changed how they work, but again not in a clear positive direction.

To me there seems to be a push to heavily prompte LLMs, even thought the benefits aren't all that clear yet. Some people are seeing massive improvements in how they work and it's understandable that they, like with blockchains or Kubernetes previously want to share their optimism. I just question if maybe these people are being to louder and have to much influence. There's a large silent majority for whom all the AI stuff is almost completely pointless.

It does need to take up more space on HN, compared to your normal media, because the technology needs to find it's way into applications and appliances. The hype will die down, especially once we start to see the actual costs, e.g. ChatGPT doesn't actually provide enough value for the average user to warrant a subscription, hence the ads. For now, it seems that AI is heavily pushed by industry and a group of fans, the amount of news and articles just doesn't line up with the actual daily use.

Since you're building it, two things you'll hit before you hit the docs. cargo install needs the package name, because it searches the whole repo and finds three packages with binaries (the CLI, the fuzz harness, the Windows shim):

cargo install --git https://github.com/getkern/kern getkern --locked

And a source build is 1.91 MB, not the 1.5 in the title. The release binary is smaller because CI builds it with a pinned nightly, build-std and optimize_for_size, on an opt-level="z" profile; the source stays plain stable Rust on purpose, so building doesn't need nightly.

Interested in what breaks.

Now with agents I don't have any insights into what its doing with kubectl and would have no reason to learn how it works (other than my own curiosity).

I agree that the human no longer gains expertise, but I am not sure that will matter in the long run.

It’s kind of ironic that, for all the expertise I’ve cultivated, all the skills I’ve grown, all the knowledge I’ve gained, I’ve found myself back at the start of my career cycle again in terms of manually defining and building OS images for virtualization on local hardware. AI has not been much help in this regard because of the hundreds of OS settings I have to understand and set according to security posture - I’ve been unable to get Claude/Qwen/etc to build an effective hardening profile for something as fundamental as CIS2, because it always presumes an AD environment on a CSP as opposed to a local VM. Believe me, I would love for it to do so, because this is dry, uninteresting work, but I’ve spent more time wrangling AI than I would’ve spent writing my own Powershell.

AI is, at least in my realm, a neat tool for basic, repetitive, boilerplate work. Very much a sudo make me a sandwich type of deal, except for YAML. That’s not me knocking the tool, just my two cents on what function it serves at present. Put another way: we wouldn’t have made our sixth hire a Support staffer if AI could do more.

K8s did not kill Ansible because of ease. Ansible is obsolete because we moved from creating a machine and changing it to instantiating it with the changes we wanted. Ansible makes sense when you are continuously updating a server-in-place and is decidedly less useful when you spin up a new unit with the new configuration when changes are made. Even in this instance the underlying skills remain the same.

- Running an old version of Golang (older than 1.18 if memory serves), or

- has libraries that the eBPF probes don't like.

And while I like OTel, I agree with the OP that you are absolutely going deep-sea diving if you're going to do anything beyond the examples provided (which is very easy to do!)

Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.

Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.

On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.

For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).

[0] https://neovim.io

[1] https://github.com/jrop/morph.nvim

[2] https://github.com/jrop/tuis.nvim

TUIs, at least to me and some friends in my circles, do something that native applications don’t: demand focus from the user.

Sure, modern terminals and TTY environments have visual tabs and virtual terminals that let you quickly toggle between multiple apps, and you can of course manually code your screen to split apps across a single “window” if you really want to get into the guts of things.

But for several folks in my close circles (myself included), the fact that each TUI occupies an entire screen by default, forces us to focus on what’s going on and what tasks we’re trying to accomplish in a way native UIs don’t. On the desktop I can flit between Discord and Telegram and multiple games and several Firefox windows full of tabs and the video encode I’m working on and hey did that bank transaction go through let’s check my email except UGH music streaming went off the rails so let me go back to my client and-

You get the idea. For folks who lack the neurotransmitters to maintain consistent focus or wave off distractions, a terminal environment acts as an accessibility device in and of itself. btop on 1, irssi on 2, Hermes (Qwen 35B) on 3, with 4 as my primary workspace and 5 as a fallback. Simple. Clean. Efficient. Lightweight.

I generally concur with the author that we should be “summoning” (I love that word for reasons that deserve their own essay/comment) more native UI apps that are as information-dense as, well, Bloomberg Terminal. There’s no reason we can’t build something as powerful and focused for the everyman for, say, inventory collections, or K8s constructs, or network architecture, all in a native UI. There’s nothing wrong with the GUI, only that at some point we let ourselves get suckered for the narrative that GUIs have to be easy, simple, and opaque, as opposed to transparent and (logically) complex. We can and should build GUIs that flow logically like the commands they’re executing behind the scenes; hell, we should be able to open a console log of every action we took in the GUI and the associated command(s) it executed, so we can better learn to transpose from GUI to CLI ourselves and build more capable or complex automations.

GUI isn’t bad. TUI isn’t bad. What’s bad is presuming one or the other is superior to everything (or for everyone) else, or worse, assuming one cannot function in a given way comparable or equivalent to the other.

I wish the observability vendors would move to using it under the covers so it's easier to mix and match.

I wish the otel support wasn't super buggy in most of the frameworks and backends.

Postgres isn’t the answer for my workload tho we really tried, i even wrote custom sharding for our postgres and it couldn’t handle the writes the cassandra setup shrugs off, but for sure this isn’t a ‘normal’ requirement most applications have.

The CC-5 rule specifically seems to be (just from reading through, nothing repeatable-eval based) the part that actually catches and prevents me from having to clean it up afterwards.

```

### Code comments

The failure this prevents: writing a comment that narrates the change I am making right now. That context is real, but it expires the instant the change merges — the defect it describes no longer exists, so the comment becomes a story about a problem no future reader can observe. It is a changelog entry in the wrong file, and a third copy of text already required in the commit body (3.b) and the PR description.

- *CC-1 (MUST NOT)* Write a comment describing a change, a fix, a defect, its cause, or what the code used to do. No "was/now/previously/instead of", no "this fixes", no "needed because otherwise", no "note that we no longer".

- *CC-2 (MUST)* Apply the survival test to every comment before writing it: would this still be true and useful to someone reading this file a year from now, who never saw the diff? If it only makes sense beside the diff, it is changelog — delete it and put it in the commit body.

- *CC-3 (MUST)* Default to zero comments. Declarative config — Terraform, DNS records, k8s manifests, CI YAML, Helm values — is self-describing and takes none. A resource named `dmarc-example-com` does not need a comment saying it is the DMARC record.

- *CC-4 (MAY)* Comment only when a future editor would actively break something without it: a non-obvious external constraint, a required out-of-band manual step, an invariant the surrounding code cannot show. One line. If it needs a paragraph it belongs in `plans/`, not inline.

- *CC-5 (MUST)* Before every commit, re-read the comment lines I added: `git diff --cached | grep '^+' | grep -E '#|//|/*'`. Each hit must pass CC-2 on its own. Deleting is always an acceptable outcome. "I already wrote it", "it is only one line", and "this one is genuinely useful" are not exemptions — the last one is the exact thought that precedes every violation.

- *CC-6 (MUST)* Applies to comments I edit as well as ones I add. When a change invalidates an existing comment, the default action is DELETE, not rewrite it into a new narrative.

```

Yes, I am aware that claude mostly generated this, and it can probably be better and/or more succinct.

A poster child for this is k8s.

You run queries against real PostgreSQL 18 compiled to WASM (PGlite). Building up from early broad grants directly on users in the first section through to abstractions around owners, login roles and roles that scope access.

Why not? Because sadly, fundamentally, most workplaces are not run by people who care about day-2 operations or long-term health. Product or Sales pushes customer-visible work into the pipeline, and you dare not say no. "Day-2" work is not considered to be something that moves the needle. Even now, with GitHub facing these severe outages, it's not like they're facing some massive exodus; their load seems to be getting worse over time, not better.

I'd be very surprised if there weren't any employees at GitHub who had read the SRE book. I'd expect that they're just not listened to.

It will just be computing new geometric states and syncing them to the screen.

Incidentally not having devs save endless copies of their dev tools and languages will save a bunch of electricity; storing and copying that stuff around uses a lot of electricity.

Software engineers who want to be taken as experts in their craft need to understand the chip makers are experts in theirs all the same. They’re not leaving your concerns about correctness, efficiency, and stability unconsidered.

Almost offensive for non-experts in hardware dev to continue to insinuate no one but SaaS devs have any idea how computers work.

3 comments https://news.ycombinator.com/item?id=48734656