‹ BackHN Continuity

Thread

I asked Meta’s Muse for its filesystem and it sent me 6.8GB

356 points · 170 comments · Aeroi

  1. tolugenius · · focus · HN ↗
    > About 20 Markdown files described browser use, connectors, payments, credentials, data handling, generated files, voice, goals, and scheduling.

    This the state of software engineering in 2026.

    Edit: clarified engineering to software engineering, which is more correct

    1. s08148692 · · focus · HN ↗
      To be fair there's probably a considerable amount of engineering that went into evaluating those markdown files so the agent behaviour is statistically reliable. The markdown is the product, not the process
      1. xnickb · · focus · HN ↗
        which part of that is engineering exactly?

        Not trying to be snarky. I genuinely don't get it

        1. thornewolf · · focus · HN ↗
          Write a prompt, evaluate the prompt, understand that is succeeds 95% of the time.

          Write a new prompt, evaluate, it now succeeds 99% of the time. Measure what changes between prompt #1 and prompt #2, understand what contributed to the performance jump.

          Write a third prompt, this one succeeds 100% of the time. Increase the size of your evaluation set, find a 1/5000 error-class and a 1/10000 error-class, add some explicit code to correct for this cases.

          Roll out to production, collecting usage metrics. You make some tweaks to your harness, your prompts. Eventually you have confidence that your system has fewer mistakes than 1 in 100k.

          Now, multiply this iteration across all your different prompts and different ways that they might interact with one another.

          1. badnew · · focus · HN ↗
            It's not engineering if you're just guessing as to what is degrading the performance and what might improve it.
            1. blmarket · · focus · HN ↗
              If you can identify gradient (what direction your change will impact the ultimate goal), then just repeating the process (or reverse-process) can find local maximum.

              Still it can be a software engineering if the gradient candidate / measuring gradient / repeat process can be done at scale.

            2. tptacek · · focus · HN ↗
              Referring you back to this evergreen comment:

              <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44978319">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44978319

              &quot;Most classical engineering fields deal with probabilistic system components all of the time. In fact I&#x27;d go as far as to say that inability to deal with probabilistic components is disqualifying from many engineering endeavors.&quot;

              1. badnew · · focus · HN ↗
                This is cope and fundamentally misrepresents engineering. Engineers deal with a problem space that is probabilistic (although they try to model it as best as they can), but design solutions in a deterministic space. With LLMs the solution space itself is non-deterministic.
            3. TeMPOraL · · focus · HN ↗
              The GP didn&#x27;t wrote &quot;guess&quot; and &quot;eyeball&quot;, but &quot;measure&quot;, &quot;evaluate&quot;, &quot;understand&quot;.

              Reading comprehension 101 is a prerequisite for doing engineering, too.

            4. hermitdev · · focus · HN ↗
              &gt; It&#x27;s not engineering if you&#x27;re just guessing as to what is degrading the performance and what might improve it.

              Engineering is literally the art of making educated guesses and then testing&#x2F;proving&#x2F;disproving&#x2F;improving upon them. Nothing is exact. Everything is approximate. Iterate until the result is good enough.

              1. badnew · · focus · HN ↗
                This is false. A bridge is not built with approximations, it is built with a deep understanding of structural physics. Yes there are some unknowns, no it&#x27;s not &quot;educated guesses&quot;.
            5. samusiam · · focus · HN ↗
              You call it a guess, I call it a hypothesis.
              1. badnew · · focus · HN ↗
                Engineers do not make hypotheses, we build solutions to problems.
                1. samusiam · · focus · HN ↗
                  Hypothesis Driven Development would beg to differ.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.