‹ BackHN Continuity

Thread

The problem is not AI code, but not knowing about system architecture or intent

388 points · 240 comments · zazuke

  1. bengold14 · · focus · HN ↗
    I see this everyday. The problem is code is the wrong abstraction for the work we do. LLMs have solved coding, but they haven't solved systems, collaboration or system maintenance.

    Edit: Since I seem to have touched a nerve - I&#x27;ve been working on a project to solve this: <a href="https:&#x2F;&#x2F;www.archme.io" rel="nofollow">https:&#x2F;&#x2F;www.archme.io if you want to know my thoughts on the right abstraction

    1. verdverm · · focus · HN ↗
      When you say &quot;solved coding,&quot; what does this mean, what does it look like?

      I have strong disagreement because it sounds like, by analogy or proxy, we have also &quot;solved writing&quot;

      1. yetanotherjosh · · focus · HN ↗
        I would say it means you are building software but no longer are concerned with writing or editing literal code. Your concerns have moved up the stack to managing requirements, context, and verification processes.

        Just to make this clear: if you can define a really good PRD and sophisticated technical specs, and a strong set of tests cases to pass, at the right level of architectural granularity, plus adversarial code review processes that triangulate and weed out most mistakes, SOTA agents can write the code autonomously, at or above the quality level of most human coding teams. I call that &quot;solved&quot; but only if you meet those context requirements. Which is still hard, not solved, at that layer.

        Solving writing is not a good analogy IMO. Writing is for human consumption, and cannot be wrapped in objective requirements and verification processes. Certain forms of writing perhaps could be (can&#x27;t think of one at the moment but I don&#x27;t doubt some exist), and those forms might be good analogies for being &quot;solvable&quot; or &quot;solved.&quot;

        1. everforward · · focus · HN ↗
          I agree with you, but it&#x27;s a moot point for software engineering.

          &gt; Your concerns have moved up the stack to managing requirements, context, and verification processes.

          This has always been the concern. &quot;Add oauth to this app, there are no requirements beyond oauth working&quot; has been an intern level task for ages. What makes software engineering hard is when the requirements start adding &quot;well it has to use this oauth backend that isn&#x27;t technically spec compliant, and the user is going to send some kind of random token you need to translate to oauth, and...&quot;. The problem isn&#x27;t in writing code that will do the thing, it&#x27;s figuring out exactly how that backend isn&#x27;t oauth compliant and what chain of API calls I have to make to convert their random token into an oauth one, and etc.

          Producing software that complies with a test suite isn&#x27;t really novel. You&#x27;ve been able to outsource that forever. This falls apart in the same places outsourcing does; I&#x27;m sure India&#x2F;Phillipines&#x2F;etc&#x2F; is more than capable of iterating on code until it passes a test suite.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.