software archæologist

I have this old Intel NUC I got back in 2019 running Fedora. It never seemed that useful, but I kept it around anyways. It survived a break in where almost everything else was stolen. Fast forward to 2026 and it's now my vibecoding hub (no mac mini needed!). I can run coding agents like pi or OpenCode on it and prompt them no matter where I am in the world, for FREE, thanks to @Tailscale. It even sends me a daily briefing with news from Twitter, HN and Lobsters that's relevant to me (thanks @ashebytes for the inspiration). It really is the little NUC that could. Can't wait to use it to build more awesome stuff!

@thdxr @stolinski > but as with everything in opencode you can change it how?

@stolinski this is here because whenever we support a model that has its own harness we try to emulate the same environment so this is coming from codex cli and we haven't deviated from it yet but as with everything in opencode you can change it

I love OpenCode but "Don't rely on flat, single-color backgrounds; use gradients, shapes, or subtle patterns to build atmosphere." should not be a choice it makes for me.

@alanscodelog @stolinski @thdxr You can obviously add even more tokens to your agent prompt to override this, but that wastes context and further confuses the model which burns additional tokens where it tries to reconcile the conflicting instructions.

I have to agree. I tried to get my agent to commit frequently as it goes along, but it kept ignoring my instructions. Took me ages to realise it was due to the OpenCode system prompt explicitly telling the model NEVER to commit unless specifically asked. @thdxr says “like everything in OpenCode, you can just change it” but I’m unclear how.

i can't speak for david. what i see is this: if you let agents build or extend a codebase with only minor or no supervision, you get unmaintainable garbage, because the agent makes terrible decisions that compound, both big and small. those decisions make it hard for both you and the agent to keep modifying the code base, until eventually it's unrecoverable. why does the agent make bad decisions? i can't tell for sure, but my gut tells me that training data can currently not capture the holistic thinking needed to design and evolve complex systems. that's one part of the problem. related to that, and oversimplified: agents output the "mean quality" of the code they saw during training. most of that code is very bad. specifically tests, which humans are terrible at writing at. another part of the problem is that specification via prompt is not precise enough, so the agent has to fill in the blanks, giving it enough rope to hang itself. the more detailed your spec gets, so the agent gets constrained and less likely to produce crap, the closer you are to handwriting the code yourself, as that's the most detailed version of the spec that can exist. so then you gain nothing. back to prompt spec it is, which means the agent fills in blanks, which means we get suboptimal or truely bad results. using agents can still be a net productivity boost (see other posts in my thread), but it is not easy to come up with consistent workflows that produce both production quality maintainable code while retaining the speed advantages agents give you.

@austinc3301 Openblock? More like openblocked lol

Turns out they just committed straight-up fraud? Their package prebundles solutions for the benchmark and then gives them to the agent when it starts

@flyosity @kristinatastic 1) What

@kristinatastic quarters pounder

I've been working on this important list for a couple of years now. What am I missing?

@samlambert What amazes me even more is how much of the response time is Ruby, suggesting there’s a lot of room for improvement

GitHub's performance in 2013. The web used to be so fast.

@glcst @jorandirkgreef @_mm_pause Genuine question: why was that particular language feature so important?

on the one hand, it is true that the team matters more than the language and I am sure you'd have found a way, Joran. But on the other hand, it's also too dismissive to say that the language doesn't matter at all. When we built Scylla, it was very clear that without C++11 style captures, that would have been an herculean task.

I dislike language wars. language is only 1% of what matters. in systems programming, it's the team & engineering that count. look at tigerbeetle & bun great engineers drive huge impact. those projects could’ve easily been built in c, c++, or rust

@opencode No longer as impressed since GLM5 started randomly going off the rails and speaking Chinese to me, or just spouting nonsensical token streams once it gets close to 50% context usage

@opencode x.com/thdxr/status/2…

Kimi K2.5 felt like an approximation of Opus: friendly, a bit over-enthusiastic, needs lot of steering or it goes haywire. In contrast, GLM 5 is giving strong Codex vibes. Comes up with sensible plans and executes them meticulously, happy to keep cooking for hours. I like it! 🫡

@nateberkopec Agree that optimising a web app is much more open ended though, for two reasons - hard to define a single success metric: many possible different yet good outcomes - many inputs

@nateberkopec I guess it is in the sense that it’s optimising a single metric. But not in the sense that it’s just tweaking a single input

While this is cool, optimizing a single variable for a nondeterministic process is the simplest possible thing you could optimize. Optimizing e.g. a web-app is 100x the dimensions here, along with a far more stringent correctness requirement. We have a long way to go.

@stainless_code I do agree that simpler is better. But do you use libraries? An operating system? ISA? Those are all interfaces we take for granted. Consider device drivers. For maximal efficiency and simplicity they should all be inlined into the kernel. Why doesn’t Linux (etc) work that way?

@AgileJebrim Those details are linked in the first paragraph 🙃 but that’s completely beside the point. How do you handle time in the software you build and why is it better than this “irrelevant slop”?

@archeologistdev I was hoping this would be more technical about low level details of how system clocks work and the errors that can occur when sampling them, but this is just irrelevant slop built on top. Completely pointless.

What separates (most) software from rocket engines is that it needs to change over time to accommodate new requirements. Well-designed interfaces and modules lower the cost of change (typically at the expense of execution time and increased LOC). Beware of overfitting to today’s requirements or you’ll pay the price tomorrow.

@AgileJebrim Their design need only change to achieve greater efficiency in serving a well known and stable set of requirements. The design space for most software is vastly less constrained.

@archeologistdev Also SpaceX’s rocket engines clearly need to change their design a bunch as well.

@TheYoungJI “Just” is doing a lot of work in that sentence

@archeologistdev Pay the price all the time instead of just rewriting code later?

Even though abstractions, sometimes, can be useful and siplify things, most of the time they only makes the system harder to understand and maintain. Code that is readable from top to bottom, without jumping around or having to read in-between the lines to understand the meta structure, make it much simpler and cheaper to modify, extend or rewrite.

@AgileJebrim Sometimes you can invert the interface - but it’s still an interface! tigerbeetle.com/blog/2025-10-2…

@AgileJebrim Not necessarily. Well designed interfaces have the opposite effect. Accessing the current wall clock time is a good example. By depending on an interface rather than directly referencing the system clock, we gain determinism which helps with testing.