Coding agents are giving everyone decision fatigue - Stack Overflow<br>Stack Overflow Business<br>Stack Internal : the knowledge intelligence layer that powers enterprise AI.<br>Stack Data Licensing : decades of verified, technical knowledge to boost AI performance and trust.<br>Stack Ads : engage developers where it matters — in their daily workflow.

There’s no doubt that coding agents have changed how software gets built. In the past three years or so, code generators have gone from fancy autocomplete to tools that can whip up a whole application while you wait. Engineers with knowledge of best practices, pitfalls, and the language of software are able to co-create code without having to futz with semicolons and unclosed brackets.<br>What’s in doubt is whether this change has been productive, cost efficient, or good for developers.<br>Easy-to-create code has put greater strain on the later parts of the software development lifecycle (SDLC): code review, DevOps/SRE, security, and infrastructure. It’s also put greater strain on the developers themselves. According to research from Smartsheet, automation intensity for their enterprise users has grown 55% year-over-year, and overall activity has increased 46%. That means the workday hasn’t grown; it’s just gotten denser with work as automations produce more without alleviating the need for humans to decide on what the definition of good is.<br>I spoke with Smartsheet’s CPTO, Pratima Arora, about what this intensification of work means for software engineers, why the new SDLC bottleneck is judgement, and how we can start reconfiguring how software is built to lighten the load on the people burdened with the new productivity.<br>Code is cheap, code review less so<br>In the pre-AI era, code was expensive because engineers were expensive. They had a ton of knowledge about the languages, processes, and paradigms that produced good software. That led to some lousy measures of productivity: hours spent, lines of code written, commits per day. These were easy to measure and sure looked like a decent approximation of results. Along the way, organizations started looking at outcomes, with schemes like DORA trying to put numbers on those.<br>Those lousy metrics are returning with a vengeance, Goodhardt’s law be damned. Not only are agentic coders bragging about their lines of code stats, but organizations have bragged about their percentage of new code written by AI. Engineers might be ranked by their token usage. The new tech bro vibes with tokenmaxxing and is AI-pilled.<br>Besides this being a wasteful measure, Arora gave an example of why it’s bad for a software org: “We had a software engineer producing 7X the code than anybody on her team. A superstar. Not only that, but also high-quality code. The check-ins and the reviews were awesome. But the other six people on the team were spending the majority of the time reviewing her code [rather] than writing the code.”<br>Code reviews require broad expertise in a codebase, especially if that review is to be effective and helpful. The best code reviews look at the change in the context of the larger system, which requires holding and understanding the context of the larger system. That requirement to pass judgement on a code commit can cause a lot of stress on a reviewer. “You're essentially asked to contribute your expertise,” said Carol Lee, PhD, now at Intuit. “So there is an element of, ‘If I mess up this review, I was the gatekeeper of this code. And if I mess it up, that might be my fault.’ So there's a lot of pressure there.”<br>Think about how much developers hate dealing with legacy code. I’ve speculated that one of the reasons that newer languages like Rust get more love in our annual survey is that they show up in greenfield projects where the developer writes the code from scratch. “Whenever an engineering team takes over an old code base, they want to rewrite it before they want to fix it,” said Arora. “It's much easier to start from scratch and write it so you understand it, and much harder to look at code and make a judgment about where did the errors happen, because you didn't write the code.”<br>Every builder is a decider<br>Smartsheet’s research found that 80% of AI-generated content is edited before it’s finalized. Those edits come from getting an understanding of the context of that code (or other content). For AI-generated code, no one wrote the original code, so the context you need to gather is greater. You can look at prompts, specs, and whatever other context your agent uses, but that’s a lot of work to produce a judgement. If we’re shifting the majority of software work from coding to making decisions, everyone is going to feel the strain of decision fatigue.<br>Before AI-enabled software engineering workflows, developers spent a significant percentage of their day (the exact figure varies wildly depending on who you asked) doing things other than writing code. Now that AI writes the code, there’s more time for the other work of an engineer....