I’ve observed exactly these patterns with Opus and Fable as well - for example, forgetting that they can edit files and instead use python scripts as a patching tool…
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..)
The funny thing is that... POSIX ed is composable :-)
You can do a gazillion edits with it in one shot.
Of course, LLM edit tools are probably small bits of their custom code, I just find it funny. I wonder if it's a desire for certain technical characteristics that require custom code or just a lack of info on basic tools. Heck, if it's about platform availability, using an LLM to port ed to Windows (for example) should be trivial[1].
* * *
[1] And there are probably a million existing ports. Also, sed, ex, vi, whatever.
Having an agent edit 100 files means the job will definitely get done correctly. When it writes a script to bulk edit things it fucks up and spends ages debugging their script.
Have you ever counted the number of times Claude fucked up quoting/escaping and had to issue a corrected tool call? Or get stuck in some tricky quoting situation for two minutes, throwing a couple piles of shit at the wall to see what sticks. IIRC I’ve even seen it eventually using the edit tool out of frustration once.
Using python or any other stone-age approach for search and replace is stupid when your language provides you with a complete, fully typed AST, like .NET does.
Sounds like you don't have enough experience with coding agents. Deterministic scripts must always be preferred instead of LLM tool calls.
In fact, you should instruct your agents to write code to execute instead of letting them call tools.
Then why did you comment what you commented, good sir/madam. Claude and Codex are good at remembering to use scripts instead of tools these days, especially if your <32kb .md file mentions it. Not even talking about the skills designed to catch such issues.
Sounds like you completely lack all reading comprehension ability
LLMs sometimes like to execute one-off Python scripts to make edits to files rather than just calling the edit tool directly. Both are tool calls so saying that you should have it write code instead of doing tool calls makes no sense because writing code is a tool call for it...
There is nothing to disprove as you don't understand what does a word mean. Deterministic is not a spectrum, they can either be deterministic or not. In both cases, they are not.
How dared I to imply that some LLM output is more deterministic than the other, your LLM majesty. Shame on me and my entire family! For generations to come!
So sorry I implied that the code that doesn't work and has to be fixed later is deterministic in its execution and can be reused later instead of being re-generated from scratch!
They're talking about writing a file with a harness-native Edit tool. They're saying the agents aren't doing that, but are using ad-hoc methods of writing the files. (My agents seem to prefer see these days.)
Why do you think your agents prefer to create scripts instead of doing tool calls these days?
I wonder, is it easier to modify a script that agent wrote before to satisfy your prompt, or is it easier to write a new one from scratch each time a retry happens?
Are input tokens more expensive than output tokens?
My god. They are not reusing the scripts. They are adhoc, inline Python scripts just used to make a single edit. You seem to fundamentally not understand what everyone else is talking about
Nobody else is talking about the reusable scripts they create, we are talking about it using inline Python to make edits to files instead of just editing it with the Edit tool. But I don't know why I'm explaining this to you again because you clearly don't understand lol
Vibe coders like you who don't even understand basic fundamentals are pretty infuriating because you don't even understand what everyone else is talking about
Most people do not support the destruction of books - it seems like the issue in both cases is copyright forcing the destruction and non-release of the scan.
They don't have to destroy the books to scan them. There are techniques for doing it non-destructively, but they're slower and more expensive. It's cheaper to cut the spines off and drop the stack of papers on a flatbed scanner with a paper feeder.
Destroying the original makes it easier to justify that scanning the books is fair use, because you haven't increased the number of copies. See page 16 of https://copyrightalliance.org/wp-content/uploads/2025/06/Bar... : "This use was even more clearly transformative than those in Texaco, Google, and Sony Betamax (where the number of copies went up by at least one)"
Very much my own opinion, but this continues comma’s extremely cavalier attitude towards safety. PCIe connectors and GPUs are not vibration rated. What happens when you hit a bad pothole?
Soft disengage -- if the GPU fails it continues to drive via on-device model, alerts the user, and then disengages.
More generally, Comma's safety is handled by a microcontroller. The microcontroller limits steering torque commanded to a safe range for level 2 driver assistance and acts as a watchdog for the rest of the stack. Failure of openpilot causes it to disengage and sound an audible alarm.
Right, it's clear that nVidia is taking care and trying to position itself so that it can continue making sales if and when inference goes local. And it's in a much better intrinsic position to do that than the LLM SaaS vendors are: nVidia sells shovels to the army, but it also knows how to sell shovels to Walmart. Whether the financial relationships that Huang's got his company into will cause it problems if the market shifts is a different question, though.
Counterpoint to many responses here - when I have interviewed people, it’s a really positive signal if the candidate says they have already seen a problem- the we can move onto something more interesting! Not solving does not mean failure either. As a candidate myself I always mention if I have seen similar problems, such as finding primes - real example, and I was hired on that loop at Microsoft!
On the other hand, if I heard that a candidate had not mentioned they had the same question twice, or later let it be known they already knew the answer, I would lose a lot of trust in them.
Be honest; it’s more likely you will be hired by honest people.
IMO the key thing is that interviews have a heavy component of randomness.
The question your interviewer selects (both topic and difficulty), how the interview performs as far as presenting the question/giving hints, how the interviewer is feeling, any biases the interviewer might have, and so on.
You can of course 'increase your surface area for luck' by studying the questions/topics a company tends to ask, being an interviewee who comes off as well qualified.
But, if you get an interviewer who is in a bad mood, if your interview isn't competent or paying attention, etc. then you're just screwed.
---
I say this because the OP was honest and failed; you were honest and were hired. There's no 'secret' to getting in. It is a combination of:
1. Being a competent engineer (or student)
2. Putting in the time to study, leetcode, practice, etc.
I'd preface the solution and the key point before mentioning that I'd seen this problem before and then further ask if they still want me to code up the solution. This eliminates the case that I, the interviewee might be bluffing. Also they might just be interested to know if you can think on your feet by then adding a twist later. who knows not my call.
It would be dumb if the next one they throw at me is one i've also seen or is ridiculously hard for an interview. Then i'd question the value of my honesty.
> As a candidate myself I always mention if I have seen similar problems, such as finding primes - real example, and I was hired on that loop at Microsoft!
Normally I'm completely in favour of being honest about this (and would almost certainly do it myself), but in the case of something as common as "finding primes" I'd think it's OK to just do it. Does any interviewer really expect that the majority of candidates haven't look at basic prime finding and primality checking algorithms?
How many devs above 40 do you think still do leetcode to keep themselves entertained, especially if their daily work is doing CRUD stuff between corporate meetings?
We're specifically talking about people who are interviewing for jobs - I'd expect a lot of them to have done leetcode before the interviews.
Also: when we think about whether we've seen a problem or not before (in order to be honest during an interview), presumably this includes all problems we have a significant memory of, not just problems we've seen recently.
Really, do you expect folks to dust off their algorithms and data structures from 30 years ago, instead of what they have been doing the last decade on the job?
Love to know how many do build bridges, repair cars,..., on their spare time for job interviews.
Yeah, it's weird (to me and you at least) why people bother quizzing industry veterans. After 10 years in the workforce you should be able to talk shop about various experiences you had at work (NDA permitting) and drop down to technical details where appropriate. Yet some companies or interviewers insist on techniques that could be replaced with asking the potential hire to eat boogers on camera for a stronger signal of what they're actually looking for.
Capture One in my opinion has much higher output quality, better defaults, and specifically for supports Phase One backs better than anything else. I have not done a scientific study or anything comparing the outputs (maybe I should!), but it’s just really good at producing gorgeous photos.
Media management though is IMO much worse than Lightroom? No keyword search, the catalog gets extremely slow over 10k images, and no filters for different cameras or lenses, as far as I know. I use peakto instead to manage and search my 40k RAWs then open them for editing only in C1.
IMO Capture One is better suited to using separate catalogs. I usually create one per year or something similar. Having everything in one catalog is going to eventually get slow.
reply