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 3 hours ago | parent [-]

> 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 an hour ago \| parent [-]
		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.