tinthedev

I've found a bit less fun, but similar, way to present for the CLI. `curl -L tinthe.dev` is HTML, don't see why to mess with the default.

But, I did put in `<link rel="alternate" type="text/markdown" href="/home.md" title="...">` as a hint for using `Accept: text/markdown` on the same URL. Or going to .md versions of pages. Did it in a "sprint" of optimizing for other devices, screen readers, and LLMs. It is supported on the full page, posts included. Same point as the draft preview, less color.

Gets you 95% of the way there. The agents can take the .md and skip the layout. And I think `curl -LH "Accept: text/markdown" tinthe.dev` is pretty readable, too.

Yeah, I love this. We can't manage what we don't measure, and adjusting the mesurement to be on the abstract syntax level removes an entire layer of "mess" that comes from comments and formatting.

I'll bookmark it and probably adjust the measurement methods for future review purposes. I've often found my LLM workflows to produce inane and overly complex code, and allowing me to see a single figure will allow me to more easily eval generated code.

I'd love to hear people's lived experience, though. I think heuristics in this space still allow for a lot of optimizations of code generation and pipelining.

Yes and no (but mainly no).

Software Engineering is in this weird limbo where a whole subsection of the industry thinks it can be a blue-collar "I just code" type of contributor... those types are going to slowly be eliminated.

But for the majority of us, the job always was more involved than just code. And that's white-collar work, through and through.

Civil engineers never could scale to pouring concrete themselves, thus the blue/white collar split. Software doesn't have that problem.

I feel a lot of these tools are barking up the wrong tree. Solving problems that are just symptoms of a deeper root cause. Index because my codebase is too big to grep. Index to paraphrase hard_decline via card retries. Reduce tool calling to save my agent YOLO search loops. etc. etc.

It feels like trying to overcome bad codebase hygiene by throwing more tools at it, and wallpapering the mold over. I've found that codebases left entirely to LLMs suffer from this gravely, but with even a bit of effort - you'll get outsized returns. Don't let the agent smosh up everything into a giant ball of code. Separate concerns, build services, do the architecture step of the software design with a bit more care than vibe coding.

A bit of a rant, yeah, but I don't see why tools like this exist (and ask you to curl a script into bash, no less). You're doing stuff a bit wrong if grepping is the bottleneck.

Well explained. That's why I put scare quotes around "amplify" - but I couldn't find a better way to state it.

How about you compare like to like? Hmmm.

Like using a calculator. I use one, but I still use paper math too, and calculate manageable sums/multiplications in my head. I'd feel dull otherwise.

GPS. I use one, but I still pay attention to the route and keep a sense of direction. “Why bother knowing where you are when the machine can tell you?” isn't really an argument for outsourcing your own brain.

I don't like AI coding, but I can't say it's not useful. Most of the arguments in this article can be disarmed by taking the abstraction "one step up". LLM generated modules and software, microservices, whatever your level of abstraction... now need to be composited together. You go and deal with higher order problems, factories, generation, etc.

Is it a way to develop critical bits of code, depths of your business logic? Absolutely not. Can it solve a lot of boilerplate and support logic? Absolutely yes.

Seeing "AI Companies as Bad Actors"... can't fully disagree there. There's far too many far too dodgy things about these businesses, and I trust them as far as I can audit them (not very far). And the missing argument's the cognitive decline of using these things to think for us. I try to keep myself sharp by still manually doing a fair amount of things in my life. I refuse to automate _everything_ - especially the stuff I do for fun. Having an LLM manage hobby-adjacent stuff is a quick trip to burnout land, especially once fixing the thing becomes "the hobby"... and it does.

Using Jev for SRE seems like such a backwards prospect. You don't need split-second velocity, you don't need costs savings. What you DO need and Jev provides not at all - is auditability. You want to know WHY and HOW the calls were made, as with humans so with AI. Adding a black box in there seems incredibly misguided, no?

The same way I'd not trust an SRE when they've "got a feeling", I don't intend to start trusting Jev. The audit of process doesn't allow audit of reasoning.

Wonderful article. Reminds me of my experience scuba diving in Croatia. My group and I were doing a seabed waste-collection dive, and part of it was an obligatory training on ordnance. The sea there has had a fair few wars and conflicts.

I remember being astounded by how the water "amplifies" the explosions - so while a hand grenade blast is very dangerous on the surface, under the sea it becomes far more horrific prospect, due to the water transferring the blast more efficiently. Nerve wracking stuff, when you're thinking about diving down there - imagining that a bomb dozens of meters away could pulverize you.

Still pretty rare, thankfully. I applaud the diver bomb disposal squads - some of the most dangerous work there is.

Looks pretty cool, although I'm not sure I see the advantage over a skill using something like a private git repo / file store / server?

So far, I've used that, a UNIX-socket inspired approach to push/pull with a remote git (hosted on my server) that the branches/files can be tossed to, and pulled via other agent. Skill instructs them to make a copy-paste ready instruction for the other prompt.

Why'd Jotbus be worth the overhead?