‹ BackHN Continuity

Thread

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

388 points · 240 comments · zazuke

  1. ecshafer · · focus · HN ↗
    AI is going to make, long term, Software Engineering more important. Getting requirements, user feedback, tests, product vision. These are key differentiators now.

    If you can really get a good set of requirements, go and write all of your test cases out, and then throw it at an AI that will one shot it. Its perfect.

    1. mattm · · focus · HN ↗
      You're basically describing a waterfall process. That never worked in a pre-AI world and won't work in an AI world. Why? Because it's just not possible to gather absolutely every requirement up front. Software development has always worked well as an iterative process. You come up with better solutions as you go along and learn about the problems you're solving and make improvements. While AI will be able to one-shot a set of requirements, you'll miss out on those improvements because you'll have skipped over those phases.

      I've tried this out. Even with relatively small applications and with spending hours reviewing the spec documents, there was always something I missed or something that wasn't quite right when seeing it live.

      1. imhoguy · · focus · HN ↗
        "Getting requirements, user feedback, tests, product vision", that also apply to iterations. Iterative processes are just a cascade of small waterfalls - either a scrum week or just a single agent session (define, prompt, plan, implement, verify)

        But today you can do even better, with AI can do true waterfall by rewriting from scratch many times.

        1. everforward · · focus · HN ↗
          > But today you can do even better, with AI can do true waterfall by rewriting from scratch many times.

          This does nothing other than ensure you end up in the "joy" of running a v0.0.1 product but for years on end instead of for a few months.

          I hear this sort of thing a lot, and I can't help but internally translate it to "I've never had to take oncall for a product directly after a rewrite". It will be broken; not even because the AI is "wrong", but because the rewrite has new edge cases. No one rewrites a project to have the exact same edge cases. Those edge cases will become outages. No one will learn anything, because a month from now it will be rewritten and those edge cases will get swapped for something else; you can pick which edge of the CAP theorem you want to live on, but you can't pick "none of them".

          1. imhoguy · · focus · HN ↗
            Absolutely, I should really put "/s" after that.

            Really I was thinking about exact example announced recently on HN: Postgres rewirte in Rust, it has 3 versions looks like each one generated from scratch <a href="https:&#x2F;&#x2F;github.com&#x2F;malisper&#x2F;pgrust" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;malisper&#x2F;pgrust

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.