Stack Overflow went agent-first. Developers responded by tackling token bills and identity grief

Stack Overflow has gone agent-first, and developers are not reacting with calm optimism. They are reacting with a very specific combo: fear of displacement, sticker shock over token consumption, and a deeper, more human problem that sounds oddly emotional for a “technical” era. At AI Engineer Melbourne, the conversations moved quickly from anxiety to adaptation, with speakers arguing that the next wave of software engineering will be less about replacing developers and more about managing incentives, costs, and identity when machines start doing tasks that used to be human work.

Several talks at the conference went straight for the money problem first, because agentic tooling runs on tokens. With organizations moving away from earlier “all you can eat” subscription plans and onto pay-as-you-go metered token consumption, costs are now a line item you can feel. AJ Fisher discussed “diffusion” models, drawing an analogy to diffusers used to generate images: they generate text at lighting speed, are cheaper to operate, and are less accurate than the pricier and slower “autoregressive” frontier models. Fisher’s practical pitch was to use a lower-quality model and make it iterate on a problem until it gets to a satisfactory solution, the classic “Ralph Wiggum loop.” The point was not hand-waving. The approach, according to Fisher’s talk, delivers the same result as a full-fat model for anywhere from one half to one tenth the spend. In other words: agents do not have to be a blank check.

But the conference did not stop at cost engineering. A theme kept surfacing in different forms: software engineers are experiencing grief because AI tooling changes how their work feels. Annie Vella, author of the seminal essay “The Software Engineering Identity Crisis,” shared what she has learned about the grief experienced by engineers as AI tooling pushes into their workflows. That emotional reaction matters because it can determine adoption outcomes as much as model quality. The field, as the conference discussion framed it, has split into “all in” and “never ever” camps, with a broad middle cautiously getting their feet wet. That split is not random. It has roots in two styles of work: some engineers look for outcomes, while others look for learning, for whom the journey into understanding is the point. If agents short circuit the journey, those engineers feel cheated.

So how do you breach the divide? Annie’s answer leaned into the human side of a machine age: sensitivity, listening, and openness to change on both sides, plus highlighting human qualities in the machine age. The subtext for leadership is important: if you treat AI rollout like a pure productivity project, you may miss the social contract that keeps complex engineering teams healthy. Teams are not just pipelines. They are collections of people who need reasons to trust the process. When AI changes who does what, trust can feel like a casualty.

Not everyone focused on feelings. Kaggle and fast.ai alum Jeremy Howard took a different tack, arguing for critical thinking and urging the audience to keep thinking while using AI tools. His message is essentially a guardrail: don’t outsource judgment, even if the machine makes the draft. He followed with a demo of SolveIT, still in beta, designed as a counterexample to environments that push users toward mindless oblivion. SolveIT combines elements from Python notebooks, Mathematica, Wikipedia, and a chatbot, aiming for an environment that helps people swim in a sea of knowledge instead of floating away.

Then came the part that felt like a sci-fi pitch until it turned practical: Daniel Rodgers-Pryor’s “Fully Automated Luxury Gay Space Engineering.” He shared a working vision for how AI can operate inside an engineering department, not just as a chat window. His CI/CD pipeline feeds metrics, messages, logs, and user feedback into a set of AI agents. Those agents quickly identify issues, find underlying problems, fix them, integrate solutions into the codebase, test them, and push changes out to users.

On paper, that sounds like a disaster recipe. But Rodgers-Pryor framed it as a formula for a self-healing, anti-fragile system that improves as pressure increases. More users is “good.” More metrics is “great.” More messages and logs is “even better.” The closed feedback loop concept is central to the argument: agents ingest all that data and use it to improve system performance. He also compared it to a 20th century production line worker dipping into the stream of bonbons, sampling a few for quality, then tossing them back into the stream. The question he ended on is blunt and practical: “This is your job now.” How can feedback loops be shorter and tighter?

That last line lands differently in 2026 than it did on day one. Software engineers have been forced to absorb more change in the last three years than in the previous thirty, and they have every right to be aggrieved about it. The conference framing suggests that adopting AI looks less like surrendering to a machine and more like exploring a new realm where the perils are real but also potentially manageable. If there is a strategic stake for founders, operators, and investors watching this, it is that “agent-first” is not one decision. It is a bundle of decisions across cost controls, developer identity, tool governance, and feedback loop design. The teams that win will be the ones that turn adoption into an engineering discipline, not a morale gamble.