‹ BackHN Continuity

Thread

What reversing, modernising old games tells us about the economic impact of AI

135 points · 90 comments · keeda

  1. CoolestBeans · · focus · HN ↗
    > The act of reverse engineering and porting decades old games to modern environments requires a complex, deeply involved set of tasks from multiple disciplines... It's the quintessential deep, skilled knowledge labor profile out there that people understood as a career protected by depth of skill and knowledge acquisition.

    Game development, especially this kind of porting, is an extremely technically demanding task. But it is far more constrained and precise in its requirements than the sort of software development that happens outside of the game world. Most developers deal with vague and (importantly for AI) unverifiable requirements that change continuously as a project develops. AI is not as good of a tool for this type of programming because unlike the tasks demonstrated in the article, there is no verification function an AI can cheaply use to validate if it is approaching completion of the task.

    In the example in the article, the bots can look at the entire memory state of the game, interact with it to see how the state changes, and then repeat the process on their working copy of the port. So long as the overall behavior of the port is getting closer to the original, the AI can validate its getting closer to its goals. Extremely impressive stuff. But this verification loop exists in a closed world. No equivalent exists for most programming disciplines. No equivalent can exist because shifting the requirements to fulfill the vague business goals is an essential job of a software developer.

    So while I am extremely impressed about what AI can accomplish every day, I also have a loud voice in the back of my mind skeptical of the actual economic impact. Because the market keeps demonstrating that these technically simpler but vague requirement tasks have a lot more value than something like game dev, at least monetarily.

    1. visarga · · focus · HN ↗
      > But this verification loop exists in a closed world. No equivalent exists for most programming disciplines.

      You can do N-version programming with coding agents and you get tests for free. It is easier to implement something than to test the same thing. This approach turns implementing into automated oracle for testing, takes less time (can implement in parallel), and every divergence between versions is either a bug fix or a requirement clarification. In order to make the N-versions more diverse we can use different model providers, programming language or libraries.

      1. shoo · · focus · HN ↗
        If the main problem is unclear & changing requirements, having 2 different implementations of a system that attempt to implement the vague / changing / missing requirements doesn't seem immediately helpful -- they'll almost certainly disagree, and then you can force one to match the other or so on, and have two implementations of some arbitrary thing.

        But none of this "implementing stuff" is making progress to solving the issue of unclear / changing / vague / missing requirements.

        1. em500 · · focus · HN ↗
          You don't try to force them to match. You show a few very different implementations that all satisfy the underspecified the requirements. Not in an antagonistic way, but to help clarify and sharpen the requirements. If any implementation would do, then there's no problem.
        2. visarga · · focus · HN ↗
          When they diverge you use the agent to classify bug one one of them or spec is unclear. You can both fix bugs and refine the spec iteratively.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.