One point for TUIs I haven't seen mentioned: they're faster for coding agents to iterate on. No need for screenshots or computer use. Agents have made GUIs cheap, but have made TUIs even cheaper, both to build and verify.
Try a coding agent for writing and tuning the OpenCV part, and have it explain its choices. That's probably the most practical path to shipping a working system.
Speaking from experience: never used OpenCV before, recently vibe coded a tool that makes supercuts of pool videos, trimming each clip from the cue ball's first strike to when the motion stops.
In case anyone was wondering, the IOCCC specifically permits LLM use in their guidelines.
"The IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques (often their own tools) to develop their code."
I'm in the no-AI camp, but for this case, I find it interesting, especially since there's little obfuscated C online, and LLMs cannot infer intention from the actual code. Did you spot any entries with LLM support?
Also, the reverse is interesting: how well can they guess the function of the obfuscated code?
Yeah, Claude, Grok and Gemini immediately recognized it as a SUBLEQ VM (and worked out from there all the details), only chatgpt got stumped and just said it was a "visual simulator".
All the big labs have plenty of proprietary (i. e. paying PhD holders good money for writing stuff) and synthetic training data now compensating for the lack of "naturally occuring" SUBLEQ and similar stuff.
This primarily affects the judges who are opening themselves up to potentially a flood of shoddy code, but given the nature of the contest, I suspect they are very good at differentiating interesting code from low quality code.
I think it's great that IOCCC accepts code that might have been built with machine assistance, because it makes the purely handcrafted winners seem even more valuable.
I don't think rule 7 would be self-contradictory since you indeed don't own the output of an LLM, but crucially, also no one else owns it. I read that rule as don't submit someone else's code without permission, which isn't violated by using an LLM.
The long tradition refers to the use of tooling in general, and could mean that, since past tools were accepted, recent tools like LLMs can be fair game as well.
But, since there can be doubts about this interpretation, them saying explicitly if LLMs are permitted or not could be beneficial. But then again, maybe they don't want to commit to an hard rule and have more freedom to decide on a case by case basis, or just don't advertise that LLMs are welcome to prevent a flood of vibe-coded submissions.
Either you view LLM code as stolen, in which case you cannot get permission of the original owners, or you accept that LLM code is not copyrightable and has no original owners.
On the “stolen” side, so far the courts have not generally agreed with that perspective except in cases where there is actually an existing copyrighted work that the LLM output is substantially similar to.
On the not-copyrightable side, the direct output of an LLM is generally legally seen as not copyrightable, but significant human modification or editing/reworking/steering/compilation (as in compiling a bunch of LLM-generated fragments into a functional whole) is still likely to be copyrightable.
