|
|
Log in / Subscribe / Register

Detecting AI obfuscated porting

Detecting AI obfuscated porting

Posted Jun 2, 2026 9:16 UTC (Tue) by khim (subscriber, #9252)
In reply to: Detecting AI obfuscated porting by skissane
Parent article: Ombredanne: An AI agent ported our codebase from Python to Rust

> You could do the same thing with coding agents - agent 1 summarises the architecture and algorithms of the existing tool into a document; agent 2 takes that document and generates a new document proposing intentionally distinct architecture and algorithms; agent 3 then generates an implementation which passes the original test suite but using different architecture/algorithms – that is unlikely to be detected by tools trying to detect cross-language translations of existing code.

If you do that then you are infringing right there, at the step #1. Remember the story with Java? APIs were not lifted from the realm of copyright. “The architecture and algorithms of the existing tool” is protected as much as the source of original. What court have decided is that small amount of it (0.4% by the findings there, but we don't know where an actual border lies) may be “fairly used” to implement new work.

Now, step #2… that's where “fair use” should arise, isn't it? Well… it could, but then step #3 would have to be done by a human or an entirely different agent from year 2050. Or maybe year 2035 if we are lucky.

LLMs today are just a pretty decent translators. They may translate from English to Ruby, or from Python to Rust… but that's pretty much it: design is way beyond their capabilities and we have no idea if they would ever be able to do that. They probably would, eventually, but not as fast as their proponents like to preach.


to post comments

Detecting AI obfuscated porting

Posted Jun 2, 2026 9:47 UTC (Tue) by jorgegv (subscriber, #60484) [Link] (4 responses)

> design is way beyond their capabilities and we have no idea if they would ever be able to do that. They probably would, eventually, but not as fast as their proponents like to preach.

I have to disagree here. LLMs are definitely already designing architectures. Perhaps not complicated ones, not humongous projects, but they are definitely there. I'm talking on experience here, not feelings.

I'm using them currently for work and personal projects, and Claude was able to design from scratch (and is currently implementing) a retro computing emulator. My emulator is fully working at this point, and I'm fixing bugs.

Detecting AI obfuscated porting

Posted Jun 2, 2026 11:08 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

> I have to disagree here. LLMs are definitely already designing architectures. Perhaps not complicated ones, not humongous projects, but they are definitely there.

They are very nice at stealing existing code and translating it to work in new place.

But the limitation is still the same: 200-300 lines code should give you something working and testable. That's not “designing an architecture”, that's “finding a place where someone's else architecture may fit”.

And yes, it's really impressive, they like to graft massive amount of code to repeat the same architecture that they found somewhere again and again.

But that's an attempt to build a skyscraper by piling twigs into a large pile. You may build a hut that way or maybe evem, evetually something similar to the ant's nest… but that's not an architecture, that's still pile of pieces not connected in any sensible order.

> I'm using them currently for work and personal projects, and Claude was able to design from scratch (and is currently implementing) a retro computing emulator. My emulator is fully working at this point, and I'm fixing bugs.

So Claude have duplicated something that was done thousands of times and was able to amalgamate that into something kinda-sorta-working… what's the big deal? It's very easy to see when it does that: try to ask it to add something that needs a component that is not there yet, and it would start with calling it, then trying to compile — and only then finding out it needs to be writtem. But try to do something differently from how other projects do thing, on average — and you'll discover that it would ignore your requests and would return “design” back to the average between other projects of similar nature.

Detecting AI obfuscated porting

Posted Jun 2, 2026 22:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I disagree. I'm running experiments with a local model, and it can design an LTFS FUSE filesystem from scratch given the specs and detailed requirements. It could even design a decent SCSI interface with a real tape drive!

It took it a bit of walking around in circles, but in the end it could one-shot it. And this is a _local_ model!

Detecting AI obfuscated porting

Posted Jun 7, 2026 4:47 UTC (Sun) by fwyzard (subscriber, #90840) [Link] (1 responses)

Curious, what model?

Detecting AI obfuscated porting

Posted Jun 7, 2026 23:01 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

The recent dense qwen 3.6, with subagents running several other models. There's also a "supervisor" agent that monitors the harness for looping detection.

Detecting AI obfuscated porting

Posted Jun 2, 2026 10:55 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (4 responses)

Clean room reverse engineering has been a valid technique since the 80s. Oracle v. Google was about copying the API declarations, analyzing the code and not publishing the result anywhere (only feeding it to another group of humans or agents) would be a completely different thing.

NEC v. Intel was not even completely clean room and yet was accepted as valid just because the result was different enough.

Detecting AI obfuscated porting

Posted Jun 2, 2026 11:11 UTC (Tue) by khim (subscriber, #9252) [Link]

> NEC v. Intel was not even completely clean room and yet was accepted as valid just because the result was different enough.

But that's precisely and exactly what LLMs couldn't do! If you don't drive it tightly it would return to the “average amalgamation of blog posts” if topic is popular enough or, if not, would simply copy one example that it may find.

Detecting AI obfuscated porting

Posted Jun 2, 2026 19:02 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

Oracle also *lost* that case.

Frankly, the whole comment by khim is completely incomprehensible to me. It reads as if it slipped through a wormhole from a parallel universe where the law is entirely different.

Detecting AI obfuscated porting

Posted Jun 3, 2026 4:29 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

Well, it also has to be conceded that Oracle lost it on fair use grounds if I don't misremember. Fair use is complicated to evaluate and it took the supreme court to sort it out.

But still the case was not about the clean room reimplementation, which was fine, but about the copying of APIs beyond java.lang.

Detecting AI obfuscated porting

Posted Jun 3, 2026 13:38 UTC (Wed) by khim (subscriber, #9252) [Link]

> Oracle also *lost* that case.

It lost in on the fair use grounds. Which is pretty much an admission that organization and shape of APIs is something copyrightable (and thus requires a permission from the copyright holder) except when restrictions on it would do more harm than good. Straight from the discussed case:

Given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public. Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the Sun Java API’s declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that extent, the lock would interfere with, not further, copyright’s basic creativity objectives.

Do you see an admission that API is uncopyrightable, here? On the contrary, it's an admission that API is copyrightable, but when someone else depends on your API you couldn't use it as a lock, because the lock would interfere with, not further, copyright’s basic creativity objectives.

This works for public APIs, but when LLM copies internal APIs that were never exposed to public it flies right out of the window: it's not public, it couldn't be used a lock, it's use is not “fair use” in any shape or form.

> It reads as if it slipped through a wormhole from a parallel universe where the law is entirely different.

No, from parallel universe where people actually read documents and not just titles.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds