Beyond AI Writing Code—What Is Agentic Engineering?

Executive Summary

AI being able to write code is not the same as being able to delegate work to AI.

No matter how intelligent a model may be, it remains unreliable for real-world work if its objective is ambiguous, it lacks the necessary resources, its permitted tools and access rights are undefined, or its results cannot be inspected. Agentic Engineering is easier to understand not as a new type of AI model, but as the engineering discipline that turns AI capabilities into work that can be delegated consistently.

Drawing on the Build With Google Day 1 talk and Lab 1 / Lab 2, this article explains three points:

• Vibe Coding and Agentic Engineering differ in purpose, not in whether one is good or bad
• As AI accelerates implementation, specifications and verification become more important
• Delegating work requires Context, a Harness, and human judgment

Where We Are in the Series

Across five installments, this series explores the question: “AI has become extraordinarily intelligent. But can we truly delegate work to it?”

1. What Is Agentic Engineering? (This Article)
2. Antigravity as a Workplace
3. Agent Skills as Operating Manuals
4. Process Design with Agents CLI and ADK Graph
5. Evaluation Through Output and Trajectory

This installment establishes the foundation that runs through the remaining four.

An Exceptionally Talented New Hire Joins the Company

Imagine that a new employee joins your company one day.

They read quickly. They can write both prose and code. They adapt immediately to unfamiliar technologies. They can even finish in minutes tasks that used to take you an entire day.

Even so, no company would let them operate its core systems freely on their first day.

The new hire does not yet know:

• What constitutes completion for this request
• Which design principles to prioritize
• Which documents are the latest versions
• Which systems they are allowed to access
• At what point approval becomes necessary
• Who will review the results and against what criteria

The same applies to AI agents. A model’s capabilities resemble an employee’s raw intelligence and skills; those alone do not make its output suitable for organizational work.

In other words, intelligence may be necessary for delegation, but it is not sufficient.

The specifications, context, tools, permissions, and inspections shown at the center of the diagram above all exist outside the model. Designing these elements is at the heart of what this series calls Agentic Engineering.

Do Not Make Vibe Coding the Villain

In discussions about AI coding, the term Vibe Coding is often used to mean “sloppy development.” Its original meaning, however, is somewhat narrower.

When Andrej Karpathy used the term in February 2025, he described building disposable weekend projects by requesting changes in natural language, barely reading the diffs, and feeding errors directly back to the AI. The important point is that this was an exploratory mode that deliberately deemphasized understanding the code and performing rigorous verification.

It is highly rational in situations such as these:

• You want to put an idea on the screen and interact with it to see whether it works
• You want to create a small, one-off script
• You want to get a feel for a new API in a short period of time
• Any failure would remain localized, and the work could be discarded immediately

The problem arises when the way a prototype is built is carried directly into production. Work involving customer data, refunds, inventory changes, or maintenance by multiple people requires qualities beyond merely “appearing to work.”

It is important not to treat the two ends as winners and losers.

In other words, the difference between Vibe Coding and Agentic Engineering is not whether AI is used, but how much structure and verification are placed around the result.

AI Does Not Accelerate the Entire SDLC at the Same Rate

Traditional software development involves gathering requirements, designing, implementing, testing, releasing, and maintaining software. This sequence is called the Software Development Life Cycle, or SDLC.

AI dramatically compresses implementation in particular. It can do more than complete a single function: it can generate features spanning multiple files, along with tests and configuration, in a short period of time.

However, the following questions do not become easier at the same rate:

• What should be built in the first place?
• If two requirements conflict, which one should take priority?
• Can this design withstand future changes?
• Does the generated artifact satisfy business rules and security requirements?
• Can it stop safely when it receives unexpected input?

Even if implementation shrinks from one week to one hour, ambiguous acceptance criteria will produce extensive review and rework. The ability to build quickly also enables the rapid multiplication of incorrect results.

This resembles a road where only one section has been converted into a highway. If only the implementation section becomes high-speed, traffic queues shift to specification at the entrance tollbooth and verification at the exit checkpoint.

Before
Requirements ── Design ── Implementation ── Testing ── Operations

What may happen after adopting AI
Requirements ── Design ── 〔Implementation〕 ── Testing ── Operations
                  ↑
              Only this stage compresses rapidly

Result
More weight shifts from “time spent writing” to “what counts as correct”
and “is it actually correct?”

The Build With Google Day 1 talk described this state as “Traditional SDLC Under Pressure.” It showed that specifications become the criteria used to evaluate Agent output directly, and that both the Output and the Trajectory leading to it must be verified.

In other words, AI does not eliminate the need for engineering; it shifts engineering’s center of gravity from implementation toward specification, design, and verification.

From Prompt Engineering to Context Engineering

When a request does not work as intended, we tend to think, “I need to write a better sentence.” But the quality of professional work is not determined by the wording of a single sentence alone.

Instead of telling a new hire to “review this properly,” suppose we provide them with:

• The SLOs this service must uphold
• Past incidents and measures taken to prevent recurrence
• Coding standards
• Architecture diagrams
• Examples of good reviews
• Available tools
• Prohibited operations

These do not constitute a “long prompt.” They constitute the information environment required to perform the work.

Technically, the information supplied to an Agent can be divided into categories such as the following:

Context Engineering is the practice of designing what information to select, when to provide it, and how broadly to make it available. If everything is always included, important information becomes buried, costs increase, and conflicting instructions become mixed together. For this reason, the third installment distinguishes between Static Context, which is always required, and Dynamic Context, which is read only when needed.

In other words, a good Prompt matters, but reliable work also requires designing the Context—that is, determining what the Agent is able to know.

Harness Engineering—Designing What Surrounds the Model

Context alone is still not enough to complete the work. Even if an Agent can read the relevant documents, it cannot be trusted with a task if its execution environment is unsafe, its permissions are too broad, or failures cannot be observed.

A harness originally refers to equipment for controlling a horse or securing a person. For AI agents, it can be understood as the surrounding system that connects a model’s capabilities to work that can be performed safely and repeatedly.

Agent system
├─ Model             Understands meaning and generates candidates
├─ Instructions      Communicate roles and rules
├─ Context / Memory  Supply required knowledge and state
├─ Tools             Act on external systems
├─ Sandbox           Contain the impact of execution
├─ Permissions       Restrict allowed operations
├─ Workflow          Control order and branching
├─ Evaluation        Inspect outcomes and paths
└─ Observability     Preserve evidence for later investigation

The advantage of this perspective is that it prevents every failure from being dismissed as “the model is weak.”

If an Agent edited the wrong file, the instructions defining its scope may have been ambiguous. If it could not reach the correct API, its Tool connections may have been insufficient. If a dangerous operation ran without confirmation, the Permission model or approval hooks were poorly designed. If the completion report was correct but the actual artifact was not, the Artifact requires independent inspection.

In other words, Agent quality is not a score assigned to the model alone; it is a property of the entire system surrounding the model.

Lab 1 and Lab 2 Were the First and Second Halves of the Same Question

In Lab 1, participants create a Project in Antigravity, manage Conversations, and work with Scheduled Tasks, MCP, Artifacts, Governance, and Custom Skills.

In Lab 2, participants use Agents CLI to Scaffold a project, read ADK Graph code, and verify its behavior through Lint, Playground, and a one-off CLI invocation.

They appear to be separate exercises, but from a design perspective, they form a continuous sequence.

One useful way to understand them is that Lab 1 creates “the new hire’s workplace and operating manual,” while Lab 2 creates “the approval path and tests for the work.”

In other words, the essence of Day 1 lies not in learning how to operate tools, but in connecting AI capabilities to the structure of work.

Effective Agent Quality
  ≈ Model capability
  × Specification clarity
  × Context relevance
  × Control robustness
  × Evaluation detection power

Key Takeaways

• Intelligence and delegability are different things. AI capabilities are converted into work through specifications, context, tools, permissions, and inspection.
• Vibe Coding excels at exploration. Agentic Engineering does not reject it; it adds the structure required for long-term operation.
• The bottleneck moves. As implementation becomes faster, deciding what to build, how to verify it, and what humans must judge becomes more important.

Next Time

To delegate work to an exceptionally capable new hire, you first need a workplace.

Where should project-specific documents and conversations be stored? How should external systems be connected? Which operations should be allowed, and what evidence of the work should humans inspect?

In the next installment, we will examine Antigravity not merely as an AI chat interface, but as an “AI workplace”.

References

• Build With Google Day 1 — Lab 1
• Build With Google Day 1 — Lab 2
• Andrej Karpathy’s Original Vibe Coding Post
• Google ADK documentation