"It is a mistake to optimise something that should not exist in the first place." - Elon Musk (apparently, although I would be astonished if Deming or Ohno hadn't said something similar)
Visual noise from CGI has been a real problem since at least Transformers in 2007. That's my benchmark for it, the one where I really first remember the overwhelm being a distraction. "Just because you can, doesn't mean you should" is a lesson that keeps needing to be relearned.
The movie was awful because it looked filmed at a low frame rate and they cut between views every frame or two. It was a mess to figure out who was fighting who.
So review the code. Our rule is that if your name is on the PR, you own the code; someone else will review it and expect you to be able to justify its contents. And we don't accept AI commits.
What this means in workflow terms is that the bottleneck has moved, from writing the code to reviewing it. That's forward progress! But the disparity can be jarring when you have multiple thousands of lines of code generated every day and people are used to a review cycle based on tens or hundreds.
Some people try to make the argument that we can accept standards of code from AI that we wouldn't accept from a human, because it's the AI that's going to have to maintain it and make changes. I don't accept that: whether you're human or not it's always possible to produce write-only code, and even if the position is "if we get into difficulty we'll just have the agent rewrite it" that doesn't stop you getting into a tarpit in the first place. While we still have a need to understand how the systems we produce work, we need humans to be able to make changes and vouch for their behaviour, and that means producing code that follows our standards.
Totally agree. If I don’t understand the code as if I’d written it myself, then I haven’t reviewed it properly. And during that review I’m often trimming and moving things around to simplify and clarify as much as possible.
This helps both me and the next agent.
Using these tools has made me realise how much of the work we (or I) do is editing: simplifying the codebase to the clearest boundaries, focusing down the APIs of internal modules, actual testing (not just unit tests), managing emerging complexity with constant refactoring.
Currently, I think an LLM struggles with the subtlety and taste aspects of many of these tasks, but I’m not confident enough to say that this won’t change.
I learned CAD specifically for 3D printing. It was SolveSpace that made it click, it's simple enough that you can see what any other package is trying to do.
AR glasses are perfect for this. Best if you can configure your laptop to give you a video signal while the lid is closed, which seems to be luck of the draw.
It's in the ollama library at q4_K_M, which doesn't quite fit on my 4090 with the default context length. But it only offloads 8 layers to the CPU for me. I'm getting usable enough token rates. That's probably the easiest way to get it. Not tried it with vllm but if it proves good enough to stick with then I might give it a try.
Oh, and on agents: I did give it a go in opencode last night and it seemed to get a bit stuck but I think I probably pushed it too far. I asked it to explain TinyRecursiveModels and pointed it at the git repo URL. It got very confused by the returned HTML and went into a loop. But actually getting to the point of getting content back from a tool call? Absolutely fine.
I'm thinking of giving it a go with aider, but using something like gemma3:27b as the architect. I don't think you can have different models for different skills in opencode, but with smaller local models I suspect it's unavoidable for now.
The comparison makes sense in what I am charitably assuming is the case the GP is referring to: we know how to build a tight embedding space from a text corpus, and get out outputs from it tolerably similar to the inputs for the purposes they're put to. That is lossy compression, just not in the sense anyone talking about conventional lossless text compression algorithms would use the words. I'm not sure we can say the same of image embeddings.
I've worked in a strong dev-owned testing team too. The culture was a sort of positive can-I-catch-you-out competitiveness that can be quite hard to replicate, and there was no concept of any one person taking point on quality.
It needs to be in the infrared spectrum at least to be useful for smart dust, otherwise the package size is still dominated by the size of the antenna. Even mm-wave radar is marginal here.
reply