AINEWS
An agentic dev tool is an AI product that takes a feature request all the way to a deployed change. ONA, the case study in one developer's $20 trial, shows the category still stumbles on the hard part.
The cost of writing software code has collapsed. Through 2025 and 2026, per-token inference on frontier models fell far enough that "writing the code" stopped being the binding constraint on most internal tools. The hard part of software engineering was never writing the code. The hard part is the human work around it: authentication, third-party integration, scoping, QA, deployment, the kind of execution overhead that no prompt makes cheaper.
That shift is the throughline in a contrarian post by engineer Kira Howe, published August 8 under the title Is it all just vapourware? Howe argues that the builders of agentic dev tools have not noticed the change. They dogfood with unlimited tokens and no real user friction, then ship products that fail their first paying user on the first integration. She backs the argument with a single test case.
The test case was ONA, an agentic development platform with public onboarding documentation at ona.com. Howe signed up on August 5 and walked away nine hours later with an empty wallet and no working project. The desktop client refused to log in. The web signup required eleven clicks and two redirects to reach a working terminal. The agent she eventually wired up burned through nearly all of her $20 in "ona compute units" (the platform's metered credit for running the model) trying to fetch a single Linear backlog before doing any work at all. Linear is a project-management tool software teams use to track tickets; the agent could not sync it. The model never got to write code, because it could not get past the integration.
ONA's documentation positions the product as an end-to-end agent. The product is real, the docs read cleanly, and the company has done the work of describing what a wired-up session should look like. The gap is between the documentation and the first paid hour. Howe describes that gap as a usability problem: the tool was not dogfooded against a real workspace with a real human watching the budget meter, so the first thing the agent did with a budget was burn it.
The Hacker News thread under Howe's post (item 49235859) gives the pattern a second voice. Commenters there, not Howe, argue that major open source projects are starting to ban LLM-generated contributions and that no major project has publicly attributed major productivity speedups to generated code. Both claims are community sentiment, not audited fact, and a load-bearing argument would cross-check them against specific projects. They are useful here because they say the same thing Howe's test says: the developer-tool market has been told the bottleneck is generation, and the people doing the work disagree.
The constructive read is that the next bottleneck is execution, and the companies that solve it will look less like model labs and more like product teams. Auth failures, broken sync, click-heavy onboarding, compute units that disappear on retries: these are solvable, but they are solvable by people who ship the boring product work, not by people who ship a better prompt. The category that figures this out first will not be the one with the strongest base model. It will be the one whose team treats the first hour of a real project as a first-class product surface.
The category will be measured by a single test: an agentic tool completing a non-trivial end-to-end project. No release has passed it yet. The current demos keep passing the easy part. Howe has said she will keep writing the code herself. The agent, when it shows up, will have to handle the Linear sync first.