From AI Assistants to Coworkers: Boosting Engineering Teams

Generic AI assistants can answer almost anything, but they do not understand an organization's specific code base, incident history, or how a particular team functions. This fundamental lack of context creates a significant gap between a helpful chatbot and a genuine engineering coworker. The goal is to empower AI with sufficient context to perform real work, while maintaining engineers' control over the process.

Engineers significantly increased their coding speed, reaching the pull request stage much faster than before. However, despite these individual improvements, the overall system's shipping velocity had barely moved, indicating that accelerating only one part of the workflow did not translate to broader organizational efficiency.

Once code is written, it must be evaluated, thoroughly understood, reviewed by peers, tested for quality, deployed into production, and continuously monitored for performance and issues. This entire process frequently requires multiple iterations and adjustments before the team is confident that the change functions as intended and is stable.

Out of these eight stages, only one directly involves writing code, which is the step accelerated by AI coding tools. The remaining seven stages still demand engineers to find relevant context, move information across various systems, operate specialized tools, coordinate with other teams, or make critical judgment calls, highlighting the human-centric nature of most of the workflow.

Applying Amdahl's Law to software engineering reveals that optimizing only the code editing fraction cannot transform the full development cycle. For instance, if a standard unit of work requires 100 hours, and only 20 of those hours are dedicated to coding, a five-fold speedup in coding reduces that block to just 4 hours. However, the total cycle time reduction is only 16% because the remaining 80 hours of non-coding effort remain untouched, constraining overall improvement.

The remaining 80% of engineering effort, largely untouched by current AI coding tools, is not wasted but comprises critical work that ensures the safe and correct delivery of changes. This includes decision-making, combining customer, product, and technical insights, defining problems, and choosing what to build. These non-coding tasks, along with verification and operational monitoring, represent the significant opportunity to develop true AI coworkers that can integrate into and advance these complex workflows, preserving organizational knowledge in the process.

While writing code can occur in isolation within a single repository during a focused session, the successful shipment of quality software cannot. Engineering work is inherently cross-functional, spanning multiple teams, diverse systems, varying permissions, and different time zones. Constant dependencies on others' timelines and shared knowledge are integral to the process, highlighting that collaboration, not isolation, defines successful software delivery.

Context is scattered across numerous systems, including chat threads, design documents, tickets, logs, and wikis. Engineers often act as 'human routers,' wasting significant time visiting disparate systems, reconstructing timelines, reconciling conflicting information, and deciding which sources to trust. This often leads to experienced engineers squandering their expertise on manual tool-hopping and context reconstruction rather than core engineering tasks.

The foundational layer consists of robust context and tools, enabling system understanding. The second layer involves triggers and judgment, where workflows are automatically initiated by events and decisions are made intelligently. The third layer is continuous learning, which allows the system to compound knowledge from previous actions through verifiable lessons, ensuring ongoing improvement and trustworthiness over time.

To make organizational context accessible to AI, manual steps where humans act as the API must be re-tooled. This involves capturing not just final outcomes, but also the underlying decision trees and rationales behind them. Converting meetings and conversations into searchable text, for example through tools like Scribe, is crucial, along with transforming raw traces and feedback into structured intelligence. If accessing a system requires clicking through a UI or consulting a single knowledgeable individual, the AI will be unable to leverage that information effectively.

The shift from an AI assistant to an AI coworker involves moving from AI that merely suggests actions to AI that actively executes them, participating in and advancing the workflow. An assistant might identify an issue or propose an approach, but a coworker programmatically engages. This transition entails exposing evaluation and diagnostic systems as callable tools and turning customer escalations into direct triggers for a workflow. Engineers can then begin their work with a pre-assembled problem, rather than starting from a blank page, significantly streamlining the process.

Instead of 'asking for help,' work is initiated when a need appears within the system, not merely when a human remembers to engage the AI. Autonomy should be a progressive development rather than an all-or-nothing switch. For instance, systems can autonomously summarize evidence for an issue before an engineer even opens a chat window, enabling proactive and efficient responses.

AI typically begins by diagnosing issues before proposing changes, then drafts pull requests to provide concrete, reviewable actions. Evidence-based evaluation confirms initial predictions, while the highest risk phases occur during launch and ramp-up. This structured approach ensures that AI proves its capabilities at each stage, building confidence within the team.

When faced with vague customer complaints, the system should prompt for clarification instead of fabricating a response. System caution is mandatory when evidence is weak, as a lack of evidence for improvement does not equate to evidence for success. In such scenarios, stopping the process, initiating a rollback, or escalating the issue to a human engineer are all considered successful outcomes, demonstrating responsible decision-making.

Trust within an organization is asymmetric; one negative action from an AI system can destroy trust significantly faster than ten positive actions can build it. Just as good human coworkers demonstrate judgment by recognizing when they need help, AI must mimic this discipline by identifying its own limitations. This self-awareness is crucial for maintaining and protecting organizational trust, ensuring that AI interventions are reliable and appropriately scoped.

Every stage of a workflow generates valuable evidence about what was successful, what failed, and where human intervention was necessary, from pull requests and offline evaluations to production outcomes. These lessons must be systematically built into the AI system itself, rather than relying solely on individual engineer memory. Human overrides and edits serve as critical learning signals, enabling the system to refine its decision-making. Closing the loop effectively connects production outcomes back to the next quality decision, ensuring continuous organizational learning and improvement.

The fundamental difference between an AI assistant and an AI coworker lies in their scope: an assistant merely accelerates a specific part of the workflow that produces a change, whereas a coworker truly advances the entire workflow surrounding that change. To achieve this coworker status, AI requires comprehensive context, access to callable tools, and meaningful triggers to initiate actions autonomously. Ultimately, successful engineering teams will focus on integrating AI into how organizations truly work, emphasizing holistic workflow management rather than just the size or capability of a particular AI model.