Live data from Hacker News

Measuring the sloppiness of code

earendil.com

241–246 of 246 posts

Re: Measuring the sloppiness of code

#242

Earlier quoted context omitted.

Right. It feels like we're living in a parallel world or something. Can agents code? Sure. Can you let them code on their own for a serious production project? Not a chance.

Plenty of serious production projects are doing exactly that. Are you using GPT-6 Astra, or something older?

Yeah, Astra, not like it matters. It will gleefully make db queries that perform full table scans instead of adding an index. I need to intuit that that's what's happening and then explicitly instruct it not to be negligently dumb.

Re: Measuring the sloppiness of code

#243
post #233

Earlier quoted context omitted.

We'll invent other tools to help with the mental models, ones that are more intuitive. Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected. We're already in a sort of IDE when you think about it, we're operating a much larger mental model than any code-base, and we rarely remember that we're operatin…

> Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected. No need to imagine. Just open the README.md of many projects.

Your project README lists all of the bugs and race conditions in the application? Cool!

Re: Measuring the sloppiness of code

#244

Earlier quoted context omitted.

Yes, the tool I’m describing works on what the pdf_oxide crate returns, which includes glyph positions. Here’s a public appendix from a recent Federal Circuit case. It has a representative assortment of documents (opinions, briefs, patents, transcripts) but contains only cited pages to the appendix pagination is non-consecutive: https://www.courtlistener.com/docket/68048163/15/ecofactor-i... The underlying docket is…

Here’s the oneshot, not sure if it’s slop or not though :) https://kolinko.eu/pdf-reading-order/ But I wonder about your opinion.

I had Claude evaluate my vibe-coded extractor against yours on the EcoFactor corpus, which I didn't test on, and an internal corpus I have:

> The EcoFactor result inverts. There, on hand-authored gold over 21 pages of clean native text, pdfgeo won the accuracy checks 25/42 to 19/42 — its geometry work on multi-column patents, table cells and timestamp lanes is genuinely better, and nothing here contradicts that. But this corpus is 21,652 pages of mostly scanned, OCR'd, skewed exhibits, and at that scale pdfgeo's robustness is the binding constraint: it loses 6.4% of the corpus to two trivial crashes and an over-strict rotation test, duplicates text on 34 files, and drops 80% of wrap hyphens. lawpdf extracted every page, 7× faster, with 2.5× less furniture leakage.

It looks like the actual geometric analysis came out the same general shape, which is an ad hoc heuristic with hard-coded values attempting to figure out where the gutter is located, etc. Seems like both have some overfitting to the text data set.

Re: Measuring the sloppiness of code

#246
post #83

Coding is not just the program running in memory, its also the process of distributing the mental model of understanding among the team. If humans increasingly are kept out of coding, then who holds the mental model? If AI holds the mental model, by definition human prompts will be over lossy channel. This is true without AI too. Software quality is directly dependent on good devs that translate from business/PM spea…

Maybe I’m not even waiting for a model which is 100% at code, but one which is almost 100% at interactively exposing its (almost? correct) mental model.

If I put it like that, it seems to me we are much far away.

Post reply on HN