Thread

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

388 points · 240 comments · zazuke

bengold14 · 1790612793 · 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've been working on a project to solve this: <a href="https://www.archme.io" rel="nofollow">https://www.archme.io if you want to know my thoughts on the right abstraction
1. verdverm · 1790613137 · focus · HN ↗
  When you say "solved coding," what does this mean, what does it look like?
  I have strong disagreement because it sounds like, by analogy or proxy, we have also "solved writing"
  1. yetanotherjosh · 1790614830 · 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 "solved" 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't think of one at the moment but I don't doubt some exist), and those forms might be good analogies for being "solvable" or "solved."
    verdverm · 1790615853 · focus · HN ↗
    > no longer are concerned with writing or editing literal code
    I'm not typing keys, but I am very much still concerned about the quality and nature of the code. Coding to me is more than pushing keys
    > if you can define a really good PRD and sophisticated technical specs
    I still believe we cannot waterfall software, the idea seems like taking a step backwards. How often do we learn about an unforeseen complexity only after getting into the implementation?
    In my experience with agents, it's better to be iterative and in-the-loop. Start with a decent description, have them research the code/issue, write up an initial plan/design, work iteratively on writing code and updating design doc, review and finalize the code and markdown. Then future agents will have some resources to shortcut understanding the code base.
    yetanotherjosh · 1790623399 · focus · HN ↗
    I'm not talking about not just punching the keyboard to type out the identifiers in the code. I'm talking about not making decisions about most classes and functions, most type definitions, most of the weedy logic within most modules, etc. If it can't be described in natural language as requirements, or in a typescript type or other data shape DSL (I think key data model types are probably still important to own), it's probably too weedy.
    Natural language test cases still define the expectations both at the product and architectural level and are essential for triangulating the agents on successful outcomes.
    A requirements and verification approach with agents is not waterfall any more than TDD is waterfall. Does thinking ahead and doing some planning equal waterfall? Does describing how a feature works to an end user, and making some key technical decisions, before you build it, mean waterfall? Does having some sense of what you're building first mean waterfall? With agents, you can specify (with PRD and technical specs) what you THINK it should do, and in minutes or hours or at most days, have the result, which you then learn from and iterate. If you didn't fully think it through, the agents will do one of three things: 1) decide for you, which you learn from 2) stop and ask, which you learn from 3) introduce bugs, which you learn from.
    It's extremely iterative.
    verdverm · 1790627643 · focus · HN ↗
    How are you thinking about technical debt in this new agentic age? (also markdown debt?)
    It's one of my bigger concerns and I use this iterative approach to try and reduce it... "go look at the ./cli directory and generate me a report of inconsistencies blah blah..." or "review ./research/something.md, validate consistency, correctness, claims, ..."
    ... pseudo prose, have we made that a thing yet like pseudo code?

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.