OnLawn

Interesting. So this looks like a prediction model, sort of a chatGPT for spreadsheets. Its "[p]retrained exclusively on synthetic data generated from structural causal models (SCMs)". More or less a clever way of finding the right curve (causal model) to interpolate and extrapolate data in one pass based on artificially clean examples. Only since it is inferred, you will never really know what it used.

Nice article, thanks. I like how the writer came up with an economic metric for understanding code review in terms of dollars in proportion to the volume of code.

That is the right way to discuss this with upper management.

The other barrier is the illusion of objectivity. In the other comments, and in many programmers experience with AI, there are code short cuts and issues that are objective in that no one would disagree with their value and importance, but they are subjective in that they cannot be described so cleanly that an LLM or human can't misunderstand them. That it can be described so perfectly as to be findable 100% with no false positives or missed positives.

And then on top of that are the purely subjective goals like 'simplicity'. Give programmers the goal of simplicity and they wind up simply pushing the complexity onto someone else's desk. LLMs (subagents, etc...) are even worse at that.

And it goes all the way up and down, the more you elevate or granulate to architectural decisions or algorithmic decisions, different illusions appear.

Code Review has never really been 100% successful, nor has Quality Control/assurance, Testing, or any other measure. At best it just forces people to look at code with another perspective to hopefully distill myth from reality. And that is itself valuable, if not for being able to show due diligence and effort.

Which brings us back to the article's equation of value. Given production, liability, are calculated in business terms from the real dollars spent or projected to be spent holds up, its a good start, no?

If your spec is really what your computer is, you should be able to run the models you need to.

Just slow down, have patience, and be opinionated on what you want it to look like, from code to architecture to user experience.

I hit more failure modes than when I use Claude, but there are always failure modes, and the answer is always slowing down, learning what it's doing, and having an opinion.

I will use, sometimes, free web search tools to architect, plan, and generally get ideas. Their ability to search the web directly helps. And to code, I sometimes build a cheap RAG with the language documentation (nushell needs help most of the time) and that helps.

Again, in general, just slow down and take your time. Like a jr dev, just cut it into bite-sized pieces with clear goals, all of which a more capable model can help with.

GLM worked well and did some impressive one-shots. Gemma can be more sophisticated in what it writes, but Qwen is less acrobatic and stable. Ornith looks interesting but I was never able to run it.

As it happens I'm working on a chessdb.nu, which is supposed to be a set of tools and skills for llms to annotate, even Socratically coach chess positions and games.

Two observations, 1) I think the post is really just trying to explain that the LLM is not limited to the next token in its planning. It can have an idea of where it is going all the way to the last period and token prediction is just the step by step to get there. Even more interesting is that the LLM can change plans midstream (cf: seahorse emoji). And 2) without going so far as saying it is existentially making choices, it is showing complex reasoning and planning which is a few steps above a Markov Chain.

As for myself, I like the analogy of french curves and splines being fixed and added to with the LLMs internal reasoning and then walked token by token. But LLM's don't actually have to be that continuous and smooth, although in fairness when it isn't, it's usually a failure mode.