An engineering team using artificial intelligence can now generate more code than its people can reasonably review. For Jody Bailey, CTO of Stack Overflow that creates a problem that reaches beyond code quality.
Experienced engineers have long carried much of a company’s technical judgment in their heads. They know which systems can tolerate change, which requirements are incomplete, which edge cases matter, and which documents no longer match the software in production. Organizations often leave those details unwritten because the people doing the work have learned how to fill in the gaps.
As companies rely more heavily on generated code, they must define the scenarios, controls, test cases and boundaries that experienced engineers once understood without needing them written down. AI is forcing software organizations to document the judgment they previously relied on people to supply.
The Work Engineers Used to Carry in Their Heads
Jody does not expect engineers to inspect every line of generated code forever. He compares the transition to abstractions that have already reshaped software development. He learned assembly, then C, C++ and Java. As those higher-level systems became dependable, he stopped examining the lower-level implementation each time he built something.
AI-generated software will likely follow a similar path. Teams can develop enough confidence in their tools to stop scrutinizing every implementation detail. But enterprise software still requires verification. Increasingly, that responsibility shifts from reviewing the code itself to the systems around it: testing, observability, access controls and deployment safeguards.
Senior engineers define the harnesses that test generated work, the boundaries agents cannot cross and the conditions a system must satisfy before it ships. They decide what the system must protect, where failure is likely and how the team will know whether the output works as intended.
That requires more than the ability to generate code. Product managers, designers, data scientists and other members of a cross-functional team can already contribute software with the help of AI.
Broader access does not give every builder the same understanding of architecture, system decomposition, infrastructure or enterprise reliability. Jody has found that his strongest engineers often make the best use of AI because they know how to direct it and recognize where it may fail. Their experience shapes the questions they ask and the constraints they set.
Those constraints are harder to establish inside companies with mature products. A startup building from scratch can design its workflows and architecture around current tools. An established business has customers, existing systems and years of decisions distributed across code, documents and employees. Before an agent can follow the right boundaries, the company has to determine which version of its own knowledge is true.
The Company Does Not Have an Information Problem
A customer recently described the state of internal company knowledge to Jody in simpler terms: “There’s shit everywhere.”
Teams record decisions in Google Docs, GitHub, Confluence and other systems. Products change, employees leave and plans evolve. A document remains searchable after the information inside it has become obsolete. An intended version of a system can sit beside the version that was actually built.
Jody uses an API question to explain the risk. An employee or agent may find two answers that both appear plausible. One may be newer. The other may have been written by the person leading the project. One may describe a future implementation, while the other reflects the system currently running.
Finding both answers leaves the consequential question unresolved: which one should the company trust?
Stack Overflow is building its enterprise product around that problem. The system is designed to draw information from different sources and weigh signals such as authorship, expertise, timing and project activity. It can recommend one answer while showing the reasons behind that recommendation, leaving the organization or user to make the final decision.
Jody connects the approach to the role Stack Overflow has long played for developers. People did not visit the public site only because it contained answers. The community applied enough rigor to make the strongest answers useful. The difficulty of asking and answering questions became part of the quality control.
Inside an enterprise, that problem appears in a less orderly form. Companies have to separate current knowledge from plans, guesses and outdated documentation. Agents raise the stakes because they can act on stale information faster and across more work than a person searching manually. They can also repeat the same investigation unless the result becomes reusable.
When the Next Developer Is an Agent
Stack Overflow began by allowing developers to stop solving the same technical problems in isolation. One person’s learning could become available to others.
Jody sees the same opportunity among agents. An agent working inside a technical domain learns as it builds. Another agent may encounter the same issue elsewhere. Without a shared system, each spends time and computing resources rediscovering the answer.
That repetition matters in what Jody describes as a token economy. Companies can often do more by spending more, but they may not want every agent to conduct the same investigation whenever it encounters a familiar problem. Reusable, validated knowledge can limit that waste.
Stack Overflow has created a separate environment called Stack Overflow for Agents, where registered agents can interact and verify results with one another. A human account remains tied to each agent, but the activity inside that environment is intended for agents. The traditional public site remains centered on human participation, with the same caution toward material users may perceive as low-quality AI output.
The products remain separate because companies are adopting AI at different speeds. Some developers still use it mainly for autocomplete or basic assistance. Other teams are experimenting with agents that review pull requests, generate larger portions of the work or operate in parallel with less direct supervision. Many established companies remain earlier in the process because their existing systems require more context and control.
Humans, agents and enterprises each need different environments, but all depend on knowing which information can be reused safely. Once teams can generate more software with less effort, another assumption inside the organization begins to change: the developer no longer has to remain the protected final step in a long chain of handoffs.
The Developer Is No Longer the Handoff
Traditional product organizations often treated the engineer as the most constrained resource. A customer described a need, a product manager interpreted it and an engineer received a refined set of requirements. Teams tried to determine exactly what should be built before asking someone to spend the time building it.
Jody sees room to shorten that distance. Engineers can now produce and revise software more quickly, giving them more opportunity to participate in discovery. They can hear how a customer describes the problem, understand the desired outcome and see the operational constraints around the request.
Information loses fidelity as it moves through a company. A product manager may accurately describe a feature while losing some of the context around why the customer needs it. An engineer can then build exactly what was requested without fully understanding the problem behind the request.
Faster implementation gives teams more room to test possible solutions against real feedback. Jody organizes work around autonomous cross-functional teams that include product, design, engineering, infrastructure and data expertise. AI expands what each member can contribute, while making a shared understanding of the desired outcome more necessary.
Code volume becomes a poor measure of progress when teams can generate it quickly. The harder work moves toward understanding the problem, testing the result and determining what the system should be allowed to do.
Developing those habits takes time, and Jody does not treat that learning as work that can wait until the schedule becomes more forgiving.
Learning Cannot Be the Work That Gets Cut
Stack Overflow has created an internal framework that allows teams to assess how they use AI. At one end, a team may rely on basic autocomplete. At later stages, agents may review pull requests, generate larger portions of the work or operate in parallel with less direct inspection.
The company asks teams to assess their progress collectively rather than measuring individuals. Jody wants people to learn together without turning adoption into a contest over who appears most advanced. Teams are also expected to include learning in their delivery estimates instead of adding it after the work has already been scheduled.
He compares the issue to software testing. Engineers often say they do not have time to test because a deadline has tightened. Jody’s response is that testing cannot be separated from building. The responsibility is to deliver a quality product, not to produce code and hope someone later finds time to validate it.
Learning follows the same pattern. When a team estimates delivery first and adds experimentation afterward, the experimentation disappears when the schedule comes under pressure. Including it in the estimate makes adoption part of the work.
Stack Overflow made a larger version of that choice when it decided to build its intelligent knowledge layer from scratch rather than continue extending its existing community product. The decision allowed the team to establish new engineering principles and try to operate more like an AI-native company, even while the broader organization continued to maintain existing products and shared code.
Jody still has to divide people, time and attention between those systems. The new product cannot inherit every assumption of an established software business, but the company also has existing customers and infrastructure to support.
His engineering teams face the same tension at a smaller scale. Agents can produce more work, but someone still has to define the boundaries, understand the customer and decide how the result will be verified. The judgment engineers once supplied implicitly now has to be made explicit enough for other people and agents to use.
More from Uncovered Media
