A "regular" UI is usually pleasant to the human eye, but it is complex by nature. By "regular" I mean browser-based UIs, native OS UIs, desktop apps, mobile screens -- all the rich, graphical surfaces we've spent decades polishing. They look great, and they cost a lot: heavier to build, harder to maintain, painful to ship everywhere.

A TUI is efficient. Even more so when you're dealing with text only -- which, let's be honest, is most of what we do as engineers. That's exactly why I'm using and developing Thurbox. It's faster to iterate on, trivial to install, and it runs the same everywhere: a remote VM over SSH, WSL, a bare desktop. One tool, one experience, no graphical stack required.

Look at the most powerful coding agents -- Claude Code and the rest. Almost all of them were designed first as a TUI. Then a wave of people tried to bolt their own "nicer" UI on top, and most of those wrappers have quietly ended up in the garbage. The terminal interface stuck around because it was the part that actually worked.

That's the real point: a TUI enforces simplicity (KISS) by nature. There's no room for decorative complexity, so you focus on the essential and keep only the features that earn their place. The constraint isn't a limitation -- it's the feature.

I've been reading Peter Steinberger's post on shipping at inference speed, and the work behind it is genuinely impressive. But when you strip it down, it's essentially a pure application of the Continuous Integration principle: integrate source code changes frequently and ensure the codebase is always in a workable state.

Peter pushes directly to main, which technically bypasses traditional CI workflows. And honestly? GitHub and its equivalents were never designed for this development speed. They keep inserting humans into the loop at every turn. Pull Requests, reviewers, approval gates -- these feel like artifacts from a slower era.

That said, we absolutely need to keep automated checks. Pre-commit and pre-push hooks are useful, but they're biased by local context -- your machine, your setup, your environment. You need a third party running the validation: a CI server that doesn't care about your local quirks.

The practical implementation today? A Pull Request with auto-merge enabled by default. If CI passes, we ship. No human bottleneck, no waiting for approvals. The only remaining challenge is making CI fast enough that "shipping at inference speed" isn't blocked by a 20-minute pipeline.

I don't like the term "vibe coding." It hides the stuff that actually keeps software working: proper workflows, CI, validation gates, architecture checks, security tests. All the process that ensures what you ship is actually good.

That said, I can't deny that the need for deep experience with specific tools is way less than it used to be. You can create very good software with a language you've never touched -- as long as you put some effort into setting up the right automation around it.

Now we have people calling it "Agentic Engineering." I don't particularly love that term either, but at least it has "Engineering" in it -- meaning it implies you need some actual engineering knowledge, not just vibes.

And this is where tooling becomes even more important. Deterministic tools -- linters, type checkers, security scanners, architecture tests -- are the things that reliably highlight low-quality software. They don't hallucinate. They don't have off days. When AI agents generate code at scale, tools that can catch problems and eventually provide fixes have more value than ever before.

Automation is not the end goal. The end product is what matters. But automation is what has always enabled quality -- look at the DORA metrics. The teams that ship the fastest are also the ones that ship the most reliably, and that's not a coincidence.

I wrote this and published it from my phone... Am I vibe coding? 🤣