When AI write Code, Architecture Matters More

The bottom line: The faster AI writes code, the more your job becomes defining what to build.

I’ve been using Antigravity — an AI asssited coding tool — since launch day. Before that, I used Windsurf. Both let AI agents to write code autonomously based on your instructions. You describe what you want, the agent reads your codebase, plans an approach, and writes the implementation. Delegated development.

After weeks of daily use, I’ve noticed three shifts in how I work.

More Work at the Spec Level Now

I spend more time working on artifacts that guide the AI. Antigravity makes it easier for me to work at the spec level by introducing 3 artifacts per each agent interactions.

• Implementation plans: It helps to research the problem, gather the affected code, and define architectural decisions. Essentially managing the context before writing a single line of code. The best feature is commenting. I can add comments directly anywhere on the doc for more directed interactions. More than one occasion, I ran out of the rate limit with Gemini Pro while working at implementation plan with AI.
• Task lists: Antigravity creates this based on the implementation plan. I don’t usually spend much time with this. It help the AI remember what actions should be taken next when a block of work is large.
• Walkthroughs: After the agent finishes, AI document what got built and how it was tested. This is for my future self.

This feels less like coding and more like managing an fast and literal junior developer. You have to be precise. Ambiguity produces garbage. Say “handle errors appropriately” and you’ll get something. Say “retry transient failures up to 3 times with exponential backoff, then log and surface to the user” and you’ll get what you actually wanted.

Sample Implementation Plan with Comment

Divide Work Across Agent Instances

I started spinning up many more agents (or conversations) to assign logically separate chunks of work. One agent when changing a database schema. Another agent when updating application logic.

This matters because:

• Each agent maintains its own implementation plan. When an agent only knows about schema changes, it can’t accidentally entangle that work with unrelated application logic. Its context stays clean.
• Agents don’t get confused mixing unrelated concerns.

Think of it as the single-responsibility principle applied to AI delegation. One agent, one objective. The overhead of spinning up multiple agents is trivial compared to the cost of untangling confused implementations.

The mental shift here is treating agents more like parallel workers than a single assistant you keep talking to. You’re not having a conversation. You’re dispatching jobs.

Define the Skeleton First

As coding velocity increases, defining the structural “skeleton” became my highest-leverage activity. The agent can fill in any implementation details. What it can’t do is decide what the system should look like. That matters more now.

The skeleton I rely on:

• Data models: What entities/tables should exist? What are their fields, attributes, and relationships? An agent that knows “a User has many Projects, and each Project has a status enum of draft/active/archived” can build correctly the first time. An agent that has to guess will make choices you’ll spend hours unwinding.
• System architecture: I use C4 (an architecture as code) to keep my mental model up-to-date. I would love AI assisted coding tools integrate with architecture as code solutions out there.
• Interface boundaries: I use API contracts to encapsulate components to expose and what actions each endpoint can take. Defining these contracts upfront helps debugging easier.

Sample view from C4 website

When AI can implement anything in minutes, the bottleneck shifts entirely to knowing what to implement. Architecture isn’t overhead. It’s the product. The teams that will move fastest are the ones with the clearest architectural vision — not because vision is nice to have, but because it’s the input the agents need.

Remembering the Changes

Implementation plans and walkthroughs are useful in the moment. The problem is recall. When you’re shipping faster, decisions pile up. Why did we take that approach two weeks ago? What tradeoffs did we consider?

I’m now saving implementation plans and walkthroughs to Linear via MCP. Each significant change gets linked to an issue. When I revisit code months later, the context is easier to recall.

The Takeaway

AI-assisted development has made me move faster and forced me to be a better architect. It forces me to be explicit about decisions I used to make implicitly while typing. Every vague intuition about “how this should work” now has to become a concrete spec, or the agent will fill in the blanks in ways I don’t want.

The hard part is deciding what the code should do.

This isn’t a small shift. The new bottleneck is builders who can specify clearly. Who can decompose a problem into the right pieces. Who can define data models that won’t paint you into corners. Who can see the system architecture before a line of code exists. The architecture layer is becoming the focus.