For most of his life, long-form writing was foreign to him. His primary interactions with text were limited to code files, configuration logs, and the occasional technical document. His journey with computers began at the age of ten, captivated by Microsoft Word’s WordArt—a simple, vibrant feature that allowed young minds to make text twist, turn, and dance across a screen. That childhood fascination with how a machine could manifest visual motion sparked a lifelong career path. It led him through electronic engineering, building track-following robots with microcontrollers in college, and eventually into a decade-long tenure at Microsoft. There, working on heavy enterprise infrastructure like Exchange Server and Outlook, he honed his craft, designing room-booking assistants and pioneering diagnostic tools that anticipated the modern concept of software agents.
By 2023, he had joined Docusign, stepping directly into the seismic shift triggered by the public arrival of ChatGPT. Tasked immediately with building AI-driven features to summarize complex legal agreements for signers, he experienced the thrill of the frontier. Yet, as the industry hurtles further into the age of artificial intelligence, his daily reality as a software engineer has undergone a transformation so radical that it has inverted his relationship with code entirely: he no longer writes it.
Before We Called Everything an Agent
Long before artificial intelligence dominated enterprise workflows, the complexities of software debugging demanded creative engineering solutions. During his years on the Microsoft Exchange Server team, engineers frequently wrestled with elusive bugs—transient race conditions that occurred for a single customer under hyper-specific circumstances, leaving no reproducible trail. Traditional debugging failed, forcing the team to innovate.
They built a specialized diagnostic tool. In retrospect, it was an early blueprint of what the industry now categorizes as an agent. The architecture was elegantly simple: the system registered specific runtime conditions for incoming requests, such as capturing supplementary memory dumps and writing them to secure logs whenever a designated user encountered a precise operational exception. Instead of chasing ghosts across a sprawling codebase, the team simply waited for the system to encounter the wild anomaly in production, harvest the data autonomously, and deliver the insights.
It was a rewarding era of software development, driven by the profound satisfaction of the eureka moment. Every seasoned engineer recognizes the distinct psychological weight of a grueling debugging session—staring at endless streams of server logs, discarding faulty hypotheses one by one, and finally, hours or days later, uncovering the root cause. It is a form of intellectual pursuit that has traditionally defined the engineering identity. Yet, the advent of advanced large language models has begun absorbing even those deeply personal, tactile joys of problem-solving.
I Went to Lunch
The turning point arrived during a data transfer project at Docusign. Tasked with navigating unfamiliar legacy code to integrate unsupported data and tables, he decided to test the newly released Sonnet 4 model embedded within GitHub Copilot.
Rather than meticulously reading every line of the inherited codebase manually, he outlined the data migration problem to the AI assistant. The model dove directly into the legacy architecture, analyzed the dependencies, and formulated a comprehensive implementation strategy. He then stepped away from his desk to eat lunch.
Upon returning, Copilot had already completed the plan. Skeptical of early AI outputs, he carefully scrutinized its assumptions, verified its logic, validated the edge cases, and made a few minor adjustments before approving the execution. What he had conservatively estimated would require a full week of deep-dive investigation and manual coding was effectively resolved in a single day. While local testing, peer code reviews, and standard deployment pipelines still demanded human validation, the moment signaled an unmistakable reality: artificial intelligence was transforming software engineering at an exponential velocity.
I Don’t Write Code at All Anymore
Today, that initial glimpse of automated productivity has become his permanent baseline. He no longer writes code in the traditional sense. Instead, development has evolved into a collaborative dialogue.
He plans features alongside AI, engaging in iterative loops of back-and-forth questioning, architectural proposals, critical pushback, and continuous refinement. Once a shared consensus is reached, the model takes over the heavy lifting of generation. High-level strategic decisions, intent, and architectural guardrails remain under human stewardship, but the physical act of typing out boilerplate implementation details has vanished from his daily routine.
This shift scaled rapidly within Docusign, where he and a colleague engineered an internal cloud coding agent affectionately dubbed the "coding elf." Born out of an internal hackathon, the tool was initially utilized by its creators primarily to write code for the elf itself. Soon, other engineers began relying on it for mundane, repetitive engineering tasks, such as rolling out feature flags and patching simple bugs. Eventually, the coding elf became so capable that it was writing the vast majority of its own code.
Interacting with the system became friction-free. Engineers could issue commands via a simple Slack message or assign tasks through Jira, and the coding elf would autonomously produce a fully fleshed-out pull request in roughly twenty minutes. Tasks could be dispatched from anywhere—during the workday, late at night, or while sitting at his children’s school events.
Non-Engineers Don’t Wait for the Backlog
The true disruption of the coding elf, however, became blindingly apparent during one of Docusign’s quarterly FixIt Days—dedicated periods where employees are given the freedom to work on experimental projects or resolve technical debt.
A team of corporate designers, having observed the capabilities of the coding elf, approached the engineers with an unusual request. Rather than filing standard backlog tickets and waiting for engineering capacity to open up, they wanted to know if they could use the agent directly to resolve persistent user experience issues themselves.
Equipped with the tool, the designers identified simple bugs across the platform and tasked the coding elf with generating the corresponding pull requests. Over the course of the FixIt Day, non-engineering designers submitted approximately 80 pull requests. More than ten of those fixes were successfully reviewed, merged, and deployed the very next day, with the remainder following standard review cycles. Engineers still provided the final safety net by reviewing the generated code and managing deployment protocols, but they were entirely removed from the tedious cycle of writing implementation code for minor UI defects.
The boundary separating software consumers from software creators is actively dissolving. AI is no longer merely accelerating how professional software engineers write code; it is fundamentally expanding who gets to write software in the first place.
Automating the Automator
The proliferation of the coding elf introduced a new logistical challenge: maintaining the health of the agent itself. Because product managers, designers, and engineers across Docusign had grown dependent on the system, its continuous operation became mission-critical.
He found himself spending significant time monitoring service logs, investigating exceptions, and instructing the coding elf to patch its own software bugs. He had inadvertently become the human bridge between raw error logs and the autonomous coding agent.
Determined to eliminate this bottleneck, he collaborated with two other engineers during a subsequent hackathon to build an agentic orchestration platform named Krew. Within this platform, he birthed his first specialized agent: Night Watch.
Night Watch monitors the coding elf’s service logs around the clock, automatically detects exceptions and operational anomalies, investigates the root causes, and generates Jira tasks. From there, the coding elf picks up the tasks to generate a fix, and a separate code review agent evaluates the resulting pull request.
The loop is now completely closed. Software engineering proceeds while he sleeps: an agent detects a failure, another investigates it, a third implements the remediation, a fourth reviews the code, and he wakes up to a finished pull request ready for final deployment.
This creates a profound professional irony. For decades, his greatest joy as a software engineer was the intellectual thrill of debugging—the deep satisfaction of solving complex puzzles. Yet, he has successfully engineered an autonomous system to perform that exact labor while he sleeps, effectively automating himself out of the loop. Part of him revels in the supreme engineering achievement of automation, while another part quietly questions the implications of surrendering the very tasks that made the profession enjoyable.
"Claude Said…"
As reliance on artificial intelligence deepens across engineering teams, corporate culture is shifting alongside it. A new vernacular has begun echoing through engineering channels, anchored by a telling phrase: "Claude said…"
During technical troubleshooting, engineers increasingly bypass traditional root-cause analysis in favor of direct consultation with large language models. When investigating a persistent 404 HTTP error, an engineer might dismiss initial theories about faulty feature flags because an AI model offered a different diagnostic narrative, pointing precisely to missing route registrations and specific source files in the host application.
While these explanations are frequently detailed, plausible, and accurate, the linguistic shift is subtle yet significant. Conversations are no longer anchored in personal investigation, such as tracing network calls or auditing codebases firsthand. Instead, authority is outsourced to an automated oracle. Similar sentiments surface when developers discuss complex third-party API integrations or rely blindly on AI-generated assertions regarding test coverage metrics.
While these models are rarely completely incompetent—delivering immense utility that compressed a week-long migration project into a single afternoon—their probabilistic nature introduces subtle hazards. Unlike deterministic compilers that reliably reject invalid syntax, large language models can occasionally present fabricated capabilities with absolute conviction.
This exact vulnerability manifested during research into Azure Cosmos DB capabilities regarding MongoDB change streams. An AI model confidently affirmed the existence of a specific feature, leading the engineering team down an unproductive technical rabbit hole. Only after hitting persistent friction did the engineer return to official Microsoft documentation, discovering that the capability did not operate as described.
Because AI provides exceptional answers ninety-five percent of the time, building trust becomes frictionless—right up until the moment an undetected hallucination derails a project.
When the Models Disagree
The exponential expansion of multi-agent systems introduces an entirely unprecedented philosophical dilemma: what happens when artificial intelligence models disagree with one another?
During a recent internal development cycle, one large language model proposed a specific technical fix to an active problem. An engineer implemented the recommendation, only for an automated code-review agent to flag the change as fundamentally broken. Seeking a tie-breaker, the team consulted a second independent LLM, which proceeded to validate the code-review agent’s critique.
The situation devolved into an algorithmic standoff: the initial generative model maintained its approach, the review agent rejected it, and a secondary model corroborated the rejection. As engineering organizations increasingly deploy interconnected fleets of specialized agents—where agents write code, other agents review it, and monitoring agents audit system logs—disagreements between autonomous systems will inevitably multiply.
Deciding which artificial intelligence to trust—or whether to override them all with human judgment—forces a reckoning over digital authority. If a third model is introduced as a tie-breaker, the inevitable cascade of divergent opinions eventually demands a return to fundamental ground truth.
Assembly All Over Again?
A common refrain among technologists dismisses these concerns, framing generative AI as merely the latest abstraction layer in a decades-long evolution of software engineering. Generations of programmers once wrote raw Assembly instructions before high-level languages like C, Java, and Python abstracted away the underlying machine architecture. Today, few software engineers concern themselves with the raw hardware instructions generated beneath their compiled code, and the industry has undeniably flourished because of it.
From this perspective, AI is simply the natural successor to traditional compilers. Code itself becomes the new Assembly—a low-level implementation detail where human intent is expressed at a high, conceptual level, leaving autonomous agents to handle the physical translation into code.
Yet, many seasoned engineers remain deeply skeptical of this clean analogy, pointing to the fundamental dichotomy between deterministic compilers and probabilistic models. A traditional compiler never hallucinates non-existent cloud database features or invents plausible explanations for code that does not compile. LLMs, by design, do.
Furthermore, human review habits are actively warping under the weight of AI-generated volume. Telemetry across modern engineering pipelines indicates that pull request sizes are expanding significantly. Because artificial intelligence does not suffer from cognitive fatigue after generating fifty lines of code, producing five hundred more is computationally trivial. Human attention spans, however, remain finite.
Faced with inflated pull requests, engineering review processes have adapted out of necessity. Developers increasingly rely on AI tools to conduct initial code reviews, scanning automated feedback before deciding how deeply to audit the underlying logic. Internal systems, backed by robust test suites and automated safety harnesses, are frequently merged without human eyes ever scanning every individual line of code.
The Ephemeral Nature of Technical Learning
This rapid evolution creates severe turbulence within corporate learning and enablement programs. Traditional technical education models assume that acquired engineering knowledge maintains a reasonable shelf life. Organizations document best practices, build training modules, and instruct teams on how to master emerging frameworks and tools.
In the current paradigm, however, the tooling shifts beneath engineers’ feet every few months. A meticulously optimized prompt harness and model combination that proves effective today can easily be eclipsed by a competing frontier model or rendered obsolete by architectural shifts like Model Context Protocol servers within half a year.
Consequently, engineering organizations are forced to rethink how technical capability is cultivated. Training developers on specific tools or frameworks is rapidly losing efficacy compared to teaching them how to critically evaluate, adapt to, and orchestrate the next wave of disruptive technologies.
Compounding this educational challenge is the persistent issue of institutional context. Legacy software systems contain invaluable operational knowledge that lives nowhere inside the repository—surviving instead within Jira tickets, old Slack threads, buried design documents, and the cognitive memories of tenured engineers. When an autonomous agent inspects a repository, it lacks the historical context behind seemingly irrational code structures, unwritten workarounds, or critical customer dependencies.
If software agents are to successfully shoulder the burden of production engineering, institutional knowledge must be systematically extracted from human minds and converted into durable, structured context that agents can reliably consume. The industry is rapidly moving toward shared memory architectures, where specialized agents can record, retain, and transfer learnings across operational sessions.
The Final Question of Understanding
Ultimately, the transformation forces every software engineer to confront a deeply personal question: Do we still need to understand the code?
The traditional engineering identity, forged through years of relentless debugging and architectural design, demands a definitive affirmative. The intrinsic satisfaction of tracing an obscure failure to its absolute root cause is a foundational pillar of software craftsmanship. The mere thought of an engineer casually dismissing a critical bug investigation with the phrase "Claude said so" challenges the very definition of professional accountability.
Yet, this principled stance runs squarely into the realities of daily practice. When an engineer relies entirely on AI-driven planning, automated code generation, machine-executed code reviews, and autonomous agent platforms to monitor and remediate production environments without human intervention, the traditional definition of coding evaporates.
If artificial intelligence systems eventually mature to the point where they can autonomously comprehend requirements, investigate sprawling codebases, implement changes, execute rigorous testing, review modifications, safely deploy updates, monitor production metrics, and rollback failures more reliably than human teams ever could, the necessity of manual line-by-line comprehension fades away.
Code truly becomes an implementation detail. The core competency of the software engineer shifts upward—away from syntax, memory management, and debugging loops, and toward the pure articulation of human intent, high-level architecture, business constraints, ethical guardrails, and the orchestration of autonomous agent systems.
Whether this transition represents a triumphant elevation of engineering capability or a perilous abdication of fundamental understanding remains entirely unresolved. It is a reality that is simultaneously exhilarating and unsettling, mirroring the broader cultural apprehension surrounding artificial intelligence across modern society.
The childhood curiosity that drew countless engineers into electronics, microcontrollers, and decades of infrastructure development now gazes upon a software landscape where absolute comprehension of every underlying mechanism may no longer be required. Navigating the delicate balance between knowing when to look behind the curtain and when to let go will likely define the hardest challenge for software engineers in the era ahead.
Comments (0)