The New Waydev - Measure the full AI SDLC. From token to production.
by•
AI agents write code. Most teams cannot tell you what percentage actually ships. Waydev tracks agent-generated code from IDE to production with AI Checkpoints: which agent, tokens consumed, cost per PR, acceptance rate, deployment status. Per team, per repo, per vendor. Compare Copilot, Cursor, and Claude Code on what reaches your customers. Measure cost per shipped PR and AI ROI. Ask the Waydev Agent anything.
Replies
Creative Tim
Congratulations for this release, I know how much work you and the team put into it. Now, this version looks like a very robust solution, love it! Can't wait to plug the new Agents into our workflows and see what we actually ship 🫡
Waydev
@axelut Thanks Alexandru, really appreciate it. This release took a lot of work, so your words mean a lot.
And yes, that’s the whole point, not just adding agents into the workflow, but finally seeing what they actually ship and what value they create in production.
Excited to see what you do with it.
Token consumption tracking is interesting — how does that work in practice with something like Claude Code, which runs autonomously and can spin up multiple sub-agents mid-session? Are you capturing tokens at the session level, per file touched, or per PR? The attribution question gets messy fast when one 'task' spawns 40 tool calls across 3 agents.
Waydev
@sounak_bhattacharya Great question. In practice, session-level token counts alone get noisy very fast, especially with autonomous agents and sub-agents.
The way we think about it is:
session/run = execution context
tool calls / sub-agents = child events inside that context
PR / merged changeset = primary attribution layer
production outcome = the layer that actually matters
So if one task spawns 40 tool calls across 3 agents, we would not treat those as 40 separate “units of value.” We roll them up into a lineage, then attribute the consumption and activity to the PR, repo, engineer/team, and eventually to what shipped.
Per-file is useful as supporting detail, but not as the source of truth. The cleanest practical model is to preserve the raw trace, then normalize attribution at the PR / merge / deployment level.
Otherwise you get a lot of activity data, but no real answer to whether the spend produced better outcomes.
That is also why we care less about token volume in isolation, and more about token spend tied to cycle time, rework, deploy frequency, incidents, and production impact.
Waydev
@hamza_afzal_butt please tell us your feedback!
Is this for big enterprise or even for small startups?
Also I didnt find the pricing model. Not sure what I missed.
Waydev
@zabbar Hi Zabbar, great question. We built Waydev with enterprise needs in mind, but it can absolutely be valuable for startups too, especially teams that want visibility into what AI is actually helping ship.
Our best fit today is usually companies with 50+ engineers, but we’re happy to talk with smaller teams as well.
On pricing, you didn’t miss anything, we’re not listing it publicly yet. It depends on team size and setup, but happy to share details if you want to take a look.
measuring actual shipped % of agent code is such a missing metric — everyone's tracking tokens spent, not outcomes. how do you handle attribution when a PR goes through multiple agents + a human review before merging?
Waydev
@tijogaucher That’s exactly why token metrics miss the point. We attribute on shipped code, not suggestions. We track lineage from agent action to commit to merged diff, then split credit by what actually survives after human edits and review.
So in a multi-agent PR, each agent gets attribution only for the code that makes it through to the final shipped result. Human review is a separate layer, unless the human materially rewrites the code.
What matters is not who touched the PR, it’s what actually shipped.
I’d love to know if your platform highlights trends or just raw metrics
Waydev
@new_user___0932026a86e905cf4b2b7f7 Both, Raj. Raw metrics for defensibility, plus AI-generated forecasts and anomaly alerts on top. Acceptance rate, cost per PR, merge rate, and deployment frequency get projected 90 days out. If a vendor's cost doubles or a team's merge rate slides, you get the alert in week two, not in the QBR. Live demo here if useful: https://ai.waydev.co/demo-login
Development will very soon move to AI-first programming. We have already started doing some projects where Claude Code writes all the code, while our seniors set the tasks and monitor the output quality.
It would be useful to evaluate the efficiency and quality of the generated code. After all, while there isn't much of it, it's not a problem, but if you program like this for a year, it's not a given that the codebase will remain easily maintainable.
Waydev
@natalia_iankovych Exactly. AI-first development is coming fast, but usage is not the same as value. The real question is whether AI generated code improves delivery without hurting maintainability over time.
If a team works this way for a year, they need to measure efficiency, quality, and long term code health based on what actually ships to production.
This is honestly something I've been wanting for a while. Been tracking my AI-assisted coding output manually and it's a mess — no good way to tell if Copilot or Claude Code actually saved time vs just shifting where the bottleneck is. The "token to production" framing makes sense because that's the real question: does more AI usage actually correlate with shipping faster? Curious how you handle the attribution when a dev uses multiple AI tools in a single PR.
Waydev
@ethanfrostlove Manual tracking breaks the moment multiple tools are involved.
The right way to think about it is not per PR as a single label, but as contribution attribution across the chain. If one developer uses Copilot, Claude Code, and edits the result manually, that PR is mixed by definition. What matters is how much contribution came from each tool, how much of it survived to merge, and whether it helped the work reach production faster with less rework and fewer downstream issues.
So for us the goal is not just measuring AI usage. It is connecting tool level contribution to shipped outcomes.
This is a question I've been trying to answer internally for months - what percentage of AI-generated code actually makes it to production, and is it saving us time or creating tech debt we'll pay for later. The "cost per shipped PR" metric is smart because it ties AI usage directly to business output instead of vanity metrics like "lines generated." Curious how it handles the gray area - like when a dev uses Copilot to scaffold something, then rewrites 60% of it. Does that count as AI-written or human-written? That attribution problem seems really hard to solve cleanly.
Waydev
@ben_gend That is exactly the hard part, and I do not think the right answer is a binary label like AI-written vs human-written.
In your example, if Copilot scaffolds something and the developer rewrites 60% of it, that work should be treated as mixed contribution. The useful question is not who gets full credit for the lines, but how much AI-assisted code survives the editing, review, merge, and production path, and what happens after it ships.
That is why we think attribution has to be modeled across the full chain: suggestion, acceptance, edit distance, PR, merge, and production outcome. Once you do that, you can separate raw AI output from retained AI contribution and then connect it to speed, rework, incidents, and maintainability. Otherwise teams end up optimizing vanity metrics instead of shipped value.
This is solving a real problem I hit as CTO. When we scaled from 15 to 120 engineers, we tracked everything - velocity, cycle time, PR throughput - but none of it told us whether the work actually mattered. AI tools make this gap even wider because raw output volume goes through the roof while the signal-to-noise ratio drops. Measuring from token to production instead of just counting lines is the right frame. Curious how you handle the attribution problem when a single feature touches both human-written and AI-generated code across multiple PRs.
Waydev
@avrisimon That was the core problem for us too. Traditional engineering metrics were built for a world where humans wrote all the code, so once AI starts increasing output, volume stops being a reliable proxy for value.
On attribution, we do not try to force a fake binary answer at the feature level. In reality, most shipped work is mixed across human and AI contributions, often across multiple PRs. The right way to handle it is to track provenance at the session, commit, and PR level, then aggregate it at the feature or delivery outcome level. That lets you see not just how much AI touched the work, but whether AI-assisted work led to faster shipping, less rework, fewer incidents, and better long-term outcomes in production.
So the goal is less ‘who wrote every line’ and more ‘what mix of human + AI contribution produced the shipped result, and was it actually better?