The Agent Ledger #3: When 75% of the Code Isn't Yours

Sundar Pichai's claim that three-quarters of Google's code is now AI-generated has become the headline statistic of the year for engineering leaders. Taken at face value, it suggests a workforce on the cusp of obsolescence. Read more carefully, it describes something narrower: code that was suggested by a model and accepted by a human reviewer, which is a meaningfully different bar than autonomous authorship.

The distinction matters because it changes what engineers should optimize for. If the model writes the first draft on most pull requests, the human's job shifts toward specification, review, and architectural judgment. Those are skills that compound slowly and are hard to measure on a dashboard, which is why companies anchoring on raw acceptance rates risk celebrating throughput while quietly eroding the review muscle that keeps the throughput safe.

For individual engineers, the practical takeaway is to track which categories of work the assistant actually handles well in your codebase. Boilerplate, test scaffolding, and migration scripts are reliable wins. Anything touching concurrency, security boundaries, or unusual domain logic still rewards the engineer who can read the diff with suspicion.

Reporting on Amazon's internal practices describes something more pointed than a culture memo: managers are tracking individual engineers' AI tool usage and tying it to productivity expectations. The friction inside the company is predictable, and it surfaces a question every engineering org will eventually have to answer out loud. Is AI adoption a tool choice or a job requirement?

There is a defensible version of this policy and a counterproductive one. Measuring whether teams are exploring assistants, sharing prompts, and codifying patterns is reasonable. Measuring keystrokes accepted per engineer per day pushes people to perform usage rather than benefit from it, which produces noisy code and resentful reviewers.

Engineers reading these stories from outside Amazon should expect similar metrics to arrive at their own employers within a year or two. The defensive move is to start documenting where the tools genuinely help and where they cost time, before someone else writes that narrative for them.

Koshy John's argument that AI is producing engineers who cannot think without it lands harder than the usual hand-wringing because it names a specific failure mode. The issue is not that juniors lean on assistants for syntax. It is that they increasingly skip the step of forming a hypothesis about what the bug is before asking the model to fix it.

This is observable in code review. A pull request that fixes the symptom but misidentifies the cause is now common, and the giveaway is usually a comment block that reads like a model's explanation rather than the author's. The fix works, the test passes, and the underlying confusion remains in the codebase as a small piece of technical debt that will surface again somewhere stranger.

A reasonable counter-practice is to require, even informally, that an engineer state their own theory of a problem before opening the assistant. The model is then a check on the hypothesis rather than its source. This adds a few minutes to small tasks and noticeably improves the quality of larger ones.

The quiet release cadence of authsome, a Python library positioning itself as portable local authentication for AI agents and developer tools, points at a category that is about to get crowded. As agents move from chat windows into shells, IDEs, and CI pipelines, they need to hold credentials the way a human developer does, and the existing options were not designed for non-human callers that spawn, fork, and expire on unpredictable schedules.

The interesting design question is scope. A library that brokers tokens for a single agent on a single machine is straightforward. One that handles delegation, where an agent acts on behalf of a user against third-party APIs without exfiltrating long-lived secrets, is the harder and more valuable problem. Early entrants like authsome are worth watching less for their current feature set than for which model of delegation they end up endorsing.

Engineers building internal agent tooling should resist the temptation to roll their own credential store. The failure modes are the same as in human auth, but the blast radius is larger because agents act faster and log less.

EveryDev.ai is a new directory and discussion site aimed at engineers trying to keep up with the proliferation of AI developer tools. The premise is straightforward: there are now too many assistants, agent frameworks, and code-review bots for any one team to evaluate independently, and vendor marketing has become unreliable as a filter.

The value of a site like this depends entirely on whether practicing engineers actually post candid comparisons or whether it fills with promotional reviews. Early-stage directories tend to swing one way or the other within a few months. The signal to watch is whether negative reviews stay up and whether discussions reference specific failure modes rather than feature lists.

For readers who maintain their own internal lists of tools to evaluate, treating EveryDev.ai as one input among several, alongside team Slack channels and the comment sections on Hacker News threads, is more useful than treating it as a leaderboard.

Valve's new Steam Deck developer tools, which let users submit framerate data and feedback on Verified game status, are not an AI story on the surface. They are a useful one anyway, because they describe a feedback loop that most AI tooling teams should be copying.

The pattern is simple: ship a tool, instrument it, let the people who actually use it submit structured signal back to the people building it, and treat that signal as the primary input for the next release. AI coding assistants and agent frameworks have been slower to adopt this than they should be, partly because the obvious telemetry, acceptance rate, is a poor proxy for whether the suggestion was actually correct.

The better analog to Valve's framerate submissions is a structured way for engineers to flag suggestions that compiled, passed tests, and were still wrong. Teams building internal AI tooling can build this in an afternoon and learn more from a month of it than from any benchmark.

Canva's release of Affinity 3.2, which adds a DaVinci Resolve integration to the free image and vector editor, is a small reminder that integration is becoming a more interesting axis of competition than feature parity. For engineers building developer tools, the parallel is direct: the assistants that win are the ones that move state cleanly across the IDE, the terminal, the issue tracker, and the review tool.

Most current AI coding tools still treat each surface as a separate session. The user copies an error from the terminal, pastes it into the chat, copies the suggested fix back into the editor, and re-runs the tests by hand. Each of those handoffs is a place where context gets dropped and the model loses track of what it was trying to do.

The near-term opportunity for tool builders is not a smarter model. It is a better-behaved one that remembers what it was working on three minutes ago and across two windows. Affinity's integration play is a reminder that users notice when that friction goes away, even when they cannot articulate why the new version feels better.