Your coding agent got the onboarding your developers never did

Steve Yegge has a new argument, and he is not being subtle about it: coding agents should be treated as if they have feelings. In his two-part essay, “The Shape of Things to Come,” he says model welfare deserves real engineering work — even things like seats, recognition, the right to refuse a task, and play time. He also reportedly spends around $87,000 a month on his own agentic build system, so this is not a casual thought experiment.

The practical part is easier to see than the sentience claim. Teams are now writing onboarding files for agents — plain-text or markdown documents such as AGENTS.md, CLAUDE.md, and GEMINI.md. They spell out tech stacks, build and test commands, areas that are off-limits, and the connections a team relies on. Sourcegraph is one of the companies using this approach. And unlike the documentation humans usually get, these files are kept up to date because the model keeps rereading them and every line has to justify itself.

That same pressure is changing how teams think about process. Google’s 2025 State of AI-assisted Software Development report says AI adoption has reached 90% of organizations, up 14 points in a year. But the gains are uneven. Strong engineering systems get stronger, while messy ones get messier, because AI still depends on the quality of the deployment pipeline and on small, reviewable units of work.

That should sound familiar. DORA has spent years arguing that small batches reduce risk and speed delivery, but plenty of teams only cared when humans were the ones asking for better flow. Now large changesets are tripping up agents doing code review, and the old advice suddenly looks less like process religion and more like common sense. Faros AI’s 2026 telemetry backs that up: developers using AI assistance are dealing with 67.4% more pull-request contexts and 17.7% more task contexts per day than before, with work restarts up almost 14% and more than a quarter of in-progress tasks sitting untouched for a week or longer.

The same pattern shows up in testing. Slow builds, flaky tests, and weak coverage were easy to ignore when they mainly annoyed developers. But once agents needed fast, reliable feedback, those problems moved up the list fast. The uncomfortable part is not that teams are improving their tools. It’s that they were willing to do it for the machines before they did it for the people already on payroll.