What matters in agentic coding is not whether you end up with passing tests, but how you got there and how structured the process is — agentic coding tends to produce a working 'spaghetti monster' of code that no one has actually read or understood.
Tim Scarfe argues the real risk of agentic coding isn't whether tests pass, but that it produces sprawling 'spaghetti monster' codebases (like the 500,000-line Verilog simulator) that no one has actually read or understood. ✦ AI generated
Tim Scarfe · Machine Learning Street Talk · 2026-06-28 · original ↗
starts at this moment · 8:04
my contention with this is I think that it's not about where you end up. It's not about the functions and the tests passing. Um, it's about how you got there and how structured it is. So there is this tendency with agentic coding to build a spaghetti monster which seems to work.
verbatim transcript · starts at 8:04
7:44had a functional specification of a C compiler and they had about 40,000 agents and they reproduce a C compiler. You did a similar thing for any by the way, right? >> Well, I mean that's an interesting thing as well, you know, because this is what I want to get to, right? That it's tantalizing that that there there are there are some domains that are so well evolved that we have um you know, that
8:04might be very complex, but but we have a functional specification and and it's reasonably coherent. So, so the idea is we we get a shitload of agents and we reproduce the function of this software based on these tests and we do it recursively, agentically and and so on. Now, my contention with this is I think that it's not about where you end up. It's not about the functions and the
8:26tests passing. Um, it's about how you got there and how structured it is. So there is this tendency with agentic coding to build a spaghetti monster which seems to work but because if you think about it in in this project you're talking about I think you said there's like 500 or more 500,000 lines of code and in 5 years time there's all of this code that probably you know you folks
8:49haven't read most of it you know that that sounds like a problem. Yeah, I think for a lot of this stuff we're relying on the hope of some kind of escape velocity from code complexity that um the models are going to keep improving faster than our code gets messed up. I had those three days of uh you know fable fable access and it was really good like it it definitely
9:13cleaned up a few things that GBT55 had had messed up. But but but did it though do you think it could be deceptive? Because you know um when Fable comes out all of a sudden 4.8 looks terrible and when 4.8 came out it looked amazing compared to you know um 4 4.6. So it there's something deceptive about it a bit you know it's like a parlor trick.
9:34>> Yeah. No it's true like in principle you could all be be smoking mirrors. I mean but I think that's why it's good to have also the the hard test right. So I could also see that it was actually suddenly I was making more progress on the more objective tests than I hadn't seen for a while >> um with the other models. So I guess that gives me some trust. But it is yeah
9:54it is weird to sort of not have the same in-depth level of understanding everything in your code and you know definitely miss it. And I'm interested in what the consequences of that are because you said you put this blog post out earlier in the year and then when we had a chat on the phone you said that you noticed there were some things that that were that were wrong and it isn't