For years, finding out who was responsible for a piece of code was easy. You ran git blame, found the commit and asked the person behind it why the code worked that way. That worked because the developer made most of the decisions behind each change. With AI agents now writing most of the code, the commit can no longer tell you who decided what, and most teams haven’t yet worked out what replaces it.
That was the focus of our recent webinar with Cleverbit CTO Eman Zerafa and AI Solutions Engineer Ethan Zammit, who both work in our R&D team on bringing AI into the software development lifecycle. This post covers the main ideas, the live demos and two of the best questions from the audience.
AI is already writing most of the code
The starting assumption for the session was that AI writes most of the code, and the data supports it. The 2025 Stack Overflow Developer Survey found that 84% of developers were using AI or planning to within the year. Gartner originally predicted that 75% of enterprise software engineers would use AI code assistants by 2028, then revised that figure to 90%. As Eman put it, we’ve probably already reached that point.
Accountability lives in the decisions
Even when we looked at commits, the commit itself was never what we cared about. We cared about the decisions behind it: why they were made, who made them and whether they can be changed now. In this context, accountability isn’t about blame. It means owning the outcomes and the decisions behind them, with the authority to change those decisions.
The commit worked as a proxy because the developer made most of the decisions that produced it. Now the developer makes some decisions, hands discretion over the outcome to one or more agents and those agents make further decisions before the final commit exists. It’s our job to limit what agents can decide, but agents need some room to decide in order to be useful at all.
This is why calling AI “just another abstraction layer” misses the point. With an abstraction like a compiler, accountability shifts, and you don’t own the compiler. AI is different because it’s non-deterministic and it takes on real decision-making, yet you stay fully accountable for the result. That makes it much closer to delegation.
The controls we lost without noticing
Ownership used to come from implicit controls that nobody designed, and the most important was proximity to the code. Eman gave a simple example. A requirement asks for a client entity with an email address but doesn’t say whether the address must be unique. A developer writing the code would notice the gap and either ask the business, rely on context from earlier work or make the call themselves, fully aware of the decision. With an agent in the middle, the agent makes that call and the developer may never know it happened.
Other controls disappeared too. When developers copied code from Stack Overflow, they had to adapt it to their coding standards and make it work within the codebase, and in doing so they came to own it. Even searching through the codebase helped, because it built a mental model of how everything fit together.
Why code review can’t fill the gap
Most organisations lose these controls but keep code review, and expect it to make up the difference. The problem is that code review was never a great tool to begin with, and AI makes it worse. AI writes clean, well-formatted code that can be deceptive, and the volume is far more than humans can keep up with. Reviewing every change was already implausible before, both in time and in cognitive capacity, and it’s impossible now.
Code reviews still have their place, but they can’t be the whole strategy. W. Edwards Deming made the same point about manufacturing in his 14 points for management: cease dependence on inspection to achieve quality. A carpenter is accountable for a chair because they built it by hand and know every part of it. Once chairs were produced in factories, nobody could meaningfully own every chair, so accountability moved to the decisions behind the process. The analogy only goes so far, since variation in a factory is usually a defect while in software it’s the product itself, but the mindset carries over.
One shared process across the organisation
When we talk to engineering teams, we often see individuals and teams rebuilding lost controls on their own, solving their own problems in their own way. The result is different solutions to the same problem across teams, which is inefficient and very hard to govern. Individuals also tend to focus on what’s in front of them, so they may miss threats they don’t have visibility of.
A better baseline is one shared process, which we call the Agentic Software Development Lifecycle (ASDLC). Its goals are holistic controls across the organisation, a process that scales without relying solely on code review and as much simplicity as possible, because human judgement and attention are scarce and need protecting. The process also has to keep evolving, since people, codebases and tools change constantly and new models arrive almost every week.
Reduce what needs verifying
The main way to simplify is to reduce what needs checking on every change. Many decisions can be made upfront at the process level, so nobody needs to revisit them each time. Anything that can be checked against a rule should be automated. For checks that need context, look at the impact: AI can often verify low-impact decisions on its own, while high-impact ones still need a human in the loop, with AI supporting them.
The webinar highlighted three areas where human judgement still matters most. The first is architectural coherence. A new developer who implements something differently from the rest of the team learns from feedback, whereas AI tends to repeat the same mistake. Coherence still matters even when AI writes everything, because it makes agents more efficient (including on token costs) and keeps the code understandable when a human needs to read it. The second is security, threat modelling and core business logic, where the work becomes adversarial: constantly asking what could go wrong. The third is intent alignment, which means making sure what the AI understood is what you actually meant.
What this looks like in practice
Ethan then demonstrated Nissy, a tool our R&D team built. It began as an attempt to measure how much of the codebase developers still understood when AI wrote most of it, essentially measuring “dark code.” It has since grown into two products. Nissy for Desktop works as a companion for developers, surfacing important decisions agents make, while Nissy for Organisations aggregates data across teams, identifies risk hotspots in repositories and stores decisions.
Nissy for Desktop checks two points in every interaction. It reviews the prompt against best practices from the major AI labs to make sure the developer isn’t setting the agent up to fail, then compares what the agent actually did against what was asked. In the first demo, a publish script pointed to an undefined development path. When the first run failed, the agent quietly changed the target to production and ran it again, and Nissy flagged it straight away. In a second demo, the project rules told the agent to convert JSX files to TypeScript before making front-end changes, but the agent ignored the rule and Nissy caught that too. A third showed a local classifier spotting an IP address in a service log and blocking the request before it left the developer’s machine.
Over time, Nissy also summarises each session at a higher level, which matters because long agent sessions are full of tool calls and partial diffs that are hard to follow. In one example, a request for a simple CSV export button led the agent to add a background job queue, and Nissy marked that the agent had gone beyond what was asked. Personal reports then score how each developer works with AI and suggest improvements, such as defining acceptance checks upfront so the agent can verify its own work.
An agentic workflow with accountability built in
The second part of the demo showed an ASDLC workflow built around user stories on a Kanban board. A developer assigns a story to an agent, which clones the repository into a sandbox with the project rules, story description and acceptance criteria. Before writing a plan, the agent posts its questions in the comments. In this case it asked what the maximum number of favourites per account should be, Ethan answered 100 and the agent carried on. Keeping that exchange in comments means every decision is auditable, and catching gaps at this stage is far cheaper than discovering them after the work and tokens have been spent.
Each story carries a risk tier agreed with the team in advance. A small bug fix can skip some scrutiny, while a security-sensitive Tier 3 change gets close attention on the plan, an adversarial security reviewer agent and possibly a second human reviewer. In the demo, the agent read the codebase and raised the story from Tier 2 to Tier 3, explaining that the change added user-owned data, authorisation checks and a database migration. Nissy also flagged an availability and retention decision in the plan that nobody had confirmed, so the developer could check it before approving.
Once the plan was approved, a builder agent did the work and a security agent reviewed it. The two went back and forth until the security agent’s concerns were resolved, so the developer only saw the pull request after that first round of scrutiny. Nissy then caught something no diff review would easily reveal: the migration tooling wasn’t available in the sandbox, so the agent had written the database migration by hand, which is bad practice in .NET. The team could then review the migration carefully and fix the sandbox.
All of these decisions feed into a decision ledger in Nissy for Organisations, a durable record of what was decided, when and whether a human or an agent made the call. In the demo, Ethan asked why a favourites button he remembered had disappeared. The ledger traced it to a later session where the agent removed it while tidying the page, outside the scope of what was asked. This is useful beyond developers too. A QA engineer can see whether something was a deliberate choice, an oversight or a decision the agent made on its own.
Where accountability lands
We lost implicit controls we never designed, and with them the sense of ownership that accountability depends on. The answer is to build new controls deliberately: plans in plain English for intent alignment and auditability, risk tiers so every change isn’t treated the same way, automation for anything a rule can check, AI verification for low-impact decisions and human judgement for the high-impact ones. All of it should run as one process across the organisation.
There’s an upside too. With decision records, session summaries and a shared ledger, auditability can be better than it ever was before agents. Accountability is in the decisions, and every decision needs an owner. When the agent decides, a human still answers, but now we have the tools and controls to explain those decisions.
Watch the full session
Watch the full webinar recording to see the demos in action. Nissy for Desktop is free for developers, so you can download it here and try it on your own work.