I vibe coded for months but switched to spec driven development in the last 6 months
I'm also old enough to have started my career learning the rational unified process and then progressed through XP, agile, scrum etc
My process is I spend 2-3 hours writing a "spec" focusing on acceptance criteria and then by the end of the day I have a working, tested next version of a feature that I push to production.
I don't see how using a spec has made me less agile. My iteration takes 8 hours.
However, I see tons of useless specs. A spec is not a prompt. It's an actual definition of how to tell if something is behaving as intended or not.
People are notoriously bad at thinking about correctness in each scenario which is why vibe coding is so big.
People defer thinking about what correct and incorrect actually looks like for a whole wide scope of scenarios and instead choose to discover through trial and error.
I get 20x ROI on well defined, comprehensive, end to end acceptance tests that the AI can run. They fix everything from big picture functionality to minor logic errors.
"The “Smart Agent” Trap: I tried making agents that could “figure out” what to do. They couldn’t. Be explicit."
So what about this solution is actually agentic?
Overall, it sounds like you sat down and did a proper business process analysis and automated it.
Your subagents for sure have no autonomy and are just execution steps in a classic workflow except you happen to be calling an LLM.
Does the orchestrating agent adapt the process between invocations depending on the data and does it do so in any way more complex than a simple if then branch?
I have tried all sorts of UI based workflow and orchestration tools over the last 20 years.
As someone technical, I start, I build something simple quickly but then start thinking edge cases, exception handling, alternate flows etc and suddenly all that is easier to handle in code directly.
Much of the power of these solutions is the pre made integrations into other systems, and not the flow control to someone technical. Once you realize that, you start looking for integration platforms and not workflow.
The reasons we suffer these accountability challenges are often rooted in that anyone holding someone else accountable, may experience negative consequences to self...and those are often estimated as too high to do "the right thing".
If the governing part at the time of the Nazi trials actually held each and every person involved accountable, would they win the next election?
If a company holds their employees to the actual standards laid out by their policies or guidelines, what would attrition look like? Would they immediately be short staffed critial roles? Would they loose a key employee at a very inconventient time?
These are the real reasons preventing us from holding people accountable.
I wouldn't be surprised if someone tries to leverage this with their customer feature request tool.
Imagine having your customers write feature requests for your saas, that immediately triggers code generation and a PR. A virtual environment with that PR is spun up and served to that customer for feedback and refinement. Loop until customer has implemented the feature they would like to see in your product.
Ironically, if you look at Sysco's stock price during the dotcom days, it's often correlated with Cisco spikes because clueless traders would accidentally buy the food logistics company stock instead of Cisco.
Not really, but in the days before open source was as accepted as today, many large companies had policies against using open source. I was working as a consultant at a Fortune 500 and was starting a new project. I wanted to use Java Spring for dependency injection and its other features. InfoSec said NO.
So I billed them for the next 3 months to write a Spring IOC clone, doing exactly the same thing to use on the project.