I’ll tell the missing part, what comes next: the team, with teammates and managers, starts making their product decisions. If the user was anywhere near the chat and wrote a mere “ok”, they will be recorded as “user's”.
They will write tests. Lots of tests. Instead of removing any code, there will be 3 layers of backward compatibility, and tests that test presence of tests that test that backward compatibility.
The reviews will find all possible edge cases, including those that can never happen, and make the UI gracefully handle them. With tests.
The diff from any integration PR from team work will be over 10K lines, half of them bureaucracy. Zero chance to review even one – they will churn half-a-dozen per day.
For anything outside of known shape, the original hard topics become quickly displaced with shortcuts and familiar patterns.
Next, the app will break under load, and you will find that it’s caused by a quadratic sweep over the whole DB on any insert to prevent something irrelevant that you specifically told not to do.
You will ask, “wtf? why is it there?”. “It’s load-bearing, you ruled it”.
(That's not a joke. That's how I spent the summer.)
With tiny models, we're getting into the territory of horoscopes and divination. While it is possible for a sentient being to derive value by using them as a random seed for thinking, the value is produced by something different from the seed.
Have you tried and how do they compare to human models as in the average human in a review?
I wouldn't put a lot of weight into an all-clear result but if Ling tiny tells me my function lacks an essential check it will force me to consider it seriously or to explicitly clarify that such checks are not relevant.
The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).
> The harness instructs them to behave this way. Also this approach saves tokens. The scripts allow to edit files in bulk, and most of the session cost is in cache reads (e.g. for 300K context each command costs the same as 30K input tokens).
I understand the reasoning, but at that point wouldn't the LLM be better off creating `sed` commands and executing those? I mean, if it's already executing Python, it can literally do anything to the environment, so using `sed` is at least as safe, with a bonus that it (or a subagent, or a human) can double-check the intention with the sed script and flag incorrect or missing changes.
I've experimented quite a bit with giving agents python vs sed + awk. They make mistakes with both, a lot. The only thing that has stood out is that agents reach for python too quickly if it's available, and that awk causes the least problems, while sed might take several attempts to get results, similar to python.
Also it's the only way that makes sense when you need to work with big files, or large amount of files, or documents that look small when fetched through a RAG tool, but then you read one and get hit with couple megabytes of base64-encoded binary data you didn't expect because RAG tool stripped out embedded images...
Ask me how I know. Or don't. I have a standing rule for all agents warning about that failure mode (and related, doing `ls` in `/tmp` and few other directories that like to accumulate files by the hundreds..)
I was wondering why Fable's 5.1 writing in Claude Code became even more unreadable, and found that they added "No em-dashes, no parentheticals, no arrows" to its system prompt.
Claude will do this for you after a few times. But yes, I have a skill called plan-to-epic which creates a Jira epic and ticket per milestone. It helps my agents persist context and, because I’m terrible at competing with my coworkers for “visibility,” means I can point to all my work if asked.
When I was not 17 at the times of GPT2, I decided to not bother with learning how to build LLMs because it’s too expensive for an individual. This escalated quickly.
12 tok/s and almost instant response on M1 Max Mac Studio (with faster SSD than laptops) are impressive – gives hope that large models may run locally from SSDs instead of memory.
I am partial to this speed-is-life sentiment, and it made me think of this beautiful and wonderfully poignant demoscene production by Farbrausch and Haujobb: "Time Index". It is made in the memory of a friend of theirs that died.
The softsynth soundtrack includes lyrics and one of them is "we slow down" which I always interpreted as a kind of demoscener's lament since making things go fast is sorta the whole point!
I am not arguing for either side of the fastness debate, while I certainly adore fast computers I don't like the mental image of our computers all blazing away doing stuff mainly humans care about, while the the world 'outside' is steadily getting hotter and more polluted.
They will write tests. Lots of tests. Instead of removing any code, there will be 3 layers of backward compatibility, and tests that test presence of tests that test that backward compatibility.
The reviews will find all possible edge cases, including those that can never happen, and make the UI gracefully handle them. With tests.
The diff from any integration PR from team work will be over 10K lines, half of them bureaucracy. Zero chance to review even one – they will churn half-a-dozen per day.
For anything outside of known shape, the original hard topics become quickly displaced with shortcuts and familiar patterns.
Next, the app will break under load, and you will find that it’s caused by a quadratic sweep over the whole DB on any insert to prevent something irrelevant that you specifically told not to do.
You will ask, “wtf? why is it there?”. “It’s load-bearing, you ruled it”.
(That's not a joke. That's how I spent the summer.)
reply