Skip to content

Non-Functional Requirements as Prompts

ryan-lopopolo's operational move: take the implicit knowledge senior engineers use to judge code — "500 little decisions along the way around the underspecified non-functional requirements that go into producing good code" — and write it down as agent-consumable artifacts (prompts, docs, ADRs, persona files, lints, tests-on-source-code).

"The important thing is not the code but the prompt and the guardrails that got you there."

Why it's the central move

The model has seen "trillions of lines of code that make every possible choice of those non-functional requirements." Without guidance it picks one more or less at random. Lopopolo's claim: the value-add of your team is no longer the code they write, it's the taste encoded as legible guidance that steers every agent trajectory.

The artifacts

  • ADRs (architecture decision records) — why this shape, not that one
  • Persona-oriented docs — "what a good job looks like" from the perspective of the front-end architect, the backend-scalability expert, the product-minded engineer. Every engineer on the team writes one; every agent gets the best of all of them.
  • Breadcrumbs — historical logs of tickets and code reviews, made queryable.
  • Bespoke lints — e.g. "a lint that is bespoke to my codebase that is going to look at every time I call fetch to make sure that there's a retry and a timeout wrapped around it."
  • Tests-about-source-code — e.g. file-length cap at 350 lines, as a context-window hygiene invariant.
  • Error messages with remediation steps — not "you have a lint failure" but "await-in-loop, here's the fix pattern."
  • Skills — 5–10 maturely-developed codepaths that teach the agent how to use your dev environment (launch app, boot observability, attach DevTools).

The loop

  1. Observe a durable class of failure across agent runs.
  2. Devise a systematic elimination (doc, lint, refactor, skill).
  3. Pay the short-term velocity cost to install it.
  4. Continue to observe, refine, and extend.

"To have one engineer on my team document [a QA plan] in a durable way means every agent trajectory is going to get a good QA plan. And we can do this once in a high-leverage way that we're able to stack on top of."