dgb23

The code looks nice, but when I read GUI, I want to see screenshots of GUIs.

Apparently a major dependency is "Fyne", which does show some screenshots on their page:

https://fyne.io/

It's an interesting problem for small businesses that want to sell stuff that will be used and relied on for a very long time.

In a sense, they have to make themselves obsolete. Either by making sure they are a part of a larger network, or by making sure that the org itself can own the product or service.

I think the explanation comes later in the article:

"It is graph-native - not a vector database with graph features bolted on, not a document store with a graph view, but a graph at it's core - because the multi-hop question intelligent systems actually have to answer cannot be answered by cosine similarity over chunked text, no matter how much AI you paste on top."

And

"It has a deterministic harness around its stochastic components. The language model proposes but the scaffolding verifies. Every inference, every tool call, every state change is captured in an immutable ledger as first-class data and this is what makes non-deterministic components safe to deploy where determinism is required."

Familiarity matters to some degree. But there are diminishing returns I think.

Stability, consistency and simplicity are much more important than this notion of familiarity (there's lots of code to train on) as long as the corpus is sufficiently large. Another important one is how clear and accessible libraries, especially standard libraries, are.

Take Zig for example. Very explicit and clear language, easy access to the std lib. For a young language it is consistent in its style. An agent can write reasonable Zig code and debug issues from tests. However, it is still unstable and APIs change, so LLMs get regularly confused.

Languages and ecosystems that are more mature and take stability very seriously, like Go or Clojure, don't have the problem of "LLM hallucinates APIs" nearly as much.

The thing with Clojure is also that it's a very expressive and very dynamic language. You can hook up an agent into the REPL and it can very quickly validate or explore things. With most other languages it needs to change a file (which are multiple, more complex operations), then write an explicit test, then run that test to get the same result as "defn this function and run some invocations".

> Then before you know it, the devops folks have decided that they need to put a gazillion other services and an entire software-defined networking layer on top of it.

I'm not familiar with kubernetes, but doesn't it already do SDN out of the box?

You can still do that. Not every business needs to be a hyperscaling startup.

Both will likely happen to some degree.

As for the average quality: it’s unclear.

My intuition is that agents lift up the floor to some degree, but at the same time will lead to more software being produced that’s of mediocre quality, with outliers of higher quality emerging at a higher rate than before.

Have you looked at their latest report?

They are only profitable because of subsidies. Pretty much 1:1.

If you are looking at open models, check out Pi, as its very extensible and comes with a sane default. Maybe even roll your own.

Most harnesses (claude, codex, opencode etc.) assume that you use a cloud model. There’s no sense of optimization or finer control.

> In many cases, simpler code is faster, and fast code makes for simpler systems. (...)

I wholeheartedly agree with you here. You mentioned a few architectural/backend issues that emerge from bad performance and introduce unnecessary complexity.

But this also happens in UI: Optimistic updates, client side caching, bundling/transpiling, codesplitting etc.

This is what happens when people always answer performance problems with adding stuff than removing stuff.

I like this collection. It's nicely presented and at least at a glance it adds some useful context to each item.

While browsing it, I of course found one that I disagree with:

Testing Pyramid: https://lawsofsoftwareengineering.com/laws/testing-pyramid/

I think this is backwards.

Another commenter WillAdams has mentioned A Philosophy of Software Design (which should really be called A Set of Heuristics for Software Design) and one of the key concepts there are small (general) interfaces and deep implementations.

A similar heuristic also comes up in Elements of Clojure (Zachary Tellman) as well, where he talks about "principled components and adaptive systems".

The general idea: You should greatly care about the interfaces, where your stuff connects together and is used by others. The leverage of a component is inversely proportional to the size of that interface and proportional to the size of its implementation.

I think the way that connects to testing is that architecturally granular tests (down the stack) is a bit like pouring molasses into the implementation, rather than focusing on what actually matters, which is what users care about: the interface.

Now of course we as developers are the users of our own code, and we produce building blocks that we then use to compose entire programs. Having example tests for those building blocks is convenient and necessary to some degree.

However, what I want to push back on is the implied idea of having to hack apart or keep apart pieces so we can test them with small tests (per method, function etc.) instead of taking the time to figure out what the surface areas should be and then testing those.

If you need hyper granular tests while you're assembling pieces, then write them (or better: use a REPL if you can), but you don't need to keep them around once your code comes together and you start to design contracts and surface areas that can be used by you or others.

It really depends on what you‘re trying to do and what your skillset is.

But if you go information architecture first and have that codified in some way (espescially if you already have the templates), then you can nudge any agent to go straight into CSS and it will produce something reasonable.

What is needed there are custom harnesses that don’t let the LLM decide what to do when. Use their power of pattern matching on data, not on decision transcriptions.

I think the opposite is the case. We increasingly need to care more about performance and know how to leverage hardware better.

The market is telling us that through increased hardware prices.

LLMs being very powerful means that we need to start being smarter about allocating resources. Should chat apps really eat up gigabytes of RAM and be entitled to cores, when we could use that for inference?

Thank you for saying this.

I hear it all the time in the recent two years: web development is apparently dead now, because anyone can just slap together a web site or build a dashboard in minutes etc. because of LLMs.

But that has been true for decades: Templates, component libraries and so on.

But I guess it’s now easier to adjust them if you‘re not familiar with their configuration or something.

When I was younger this actually irked me a bit. I wasn't familiar with either, so it felt burdensome to me. The tooling also wasn't as good as it is now.

However there's no doubt that this is one of the primary reasons why Clojure became relevant and widely used (for a niche language). Seamless integration (or even improved integration) is very useful.

Another language that takes this approach is Zig. My intuition is that here as well, it's a unique selling point that will help with adoption and day to day usefulness.

Here's some hope: You will figure it out. You are already a person who is very curious, competent and experienced with making stuff.

PHP's performance can be significantly lower than JS, because it doesn't have application state (in a standard runtime/setup) and needs to re-run the entire application for every request. Now there are a whole bunch of tricks both in the language and with tooling to alleviate that, but still it's inherently there. It's an advantage for other reasons though.

OK so you're saying the gibberish is a feature and not a bug so to speak? So the thinking output can be understood as coughing and mumbling noises that help the model get into the right paths?

Didn't you notice that the stream is not coherent or noisy? Sometimes it goes from thought A to thought B then action C, but A was entirely unnecessary noise that had nothing to do with B and C. I also sometimes had signals in the thinking output that were red flags, or as you said it got confused, but then it didn't matter at all. Now I just never look at the thinking tokens anymore, because I got bamboozled too often.

Perhaps when you summarize it, then you might miss some of these or you're doing things differently otherwise.

Don't look at "thinking" tokens. LLMs sometimes produce thinking tokens that are only vaguely related to the task if at all, then do the correct thing anyways.

I agree with you here. I think this is for product placement for Mythos.

This is funny on so many levels.

It's certainly interesting that they provide an email service now. In their documentation/blog recommendations they switched their recommended approach twice or three times already.

If they establish a solid email solution I will likely use that for some of the projects I'm hosting there.

Do I expect the same memory footprint from an N active parameters as from simply N total parameters?

Isn’t that security by obscurity?

The future of harnesses cannot be „resend the whole history on every step“ or whatever this terrible compaction is.

Most of the context is unstructured fluff, much of it is distracting or even plain wrong. Especially the „thinking“ tokens are often completely disjoint halucinations that don’t make any sense.

I think what will have to happen is that context looks less like a long chat and action log and more like a structured, short, schema validated state description, plus a short log trace that only grows until a checkpoint is reached, which produces a new state.

Clojure and Go are similar to this from my experience.

The last paragraph might be the most important one:

> There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without requiring anyone else you're working with to convert too. This means that there's no real downside to giving it a shot; if it's not for you, you're not giving up all of the history you wrote with it, and can go right back to git with no issues.

Also it’s the wrong tool for this kind of work.

Claude, opencode etc. Are brute force coding harnesses that literally use bash tools plus a whole bunch of vague prompting (skills, AGENT.md, MCP and all that stuff) to nudge them probabilistically into desirable behavior.

Without engineering specialized harnesses that control workflows and validate output, this issue won‘t go away.

We‘re in the wild west phase of LLM usage now, where problems emerge that shouldn’t exist in the first place and are being solved at the entirely wrong layer (outside of the harness) or with the entirely wrong tools (prompts).