A year of software development with AI agents

AI coding agents did not reduce the need for engineering judgment in our team. They increased it — just in different places.

A year ago, most of my day was implementation: read a ticket, write code, run tests, open a PR, repeat. Today, the code still gets written, but my focus has moved both upstream and downstream. I spend more time clarifying intent before code exists, steering agents while they work, and reviewing the result after they produce it.

That is the real change AI agents have brought to our software practice. They have not removed the need for developers. They have changed where developer judgment matters most.

This post is a snapshot of what that shift looks like after a year with AI coding agents. It is written primarily for developers and engineering leads, but the lessons are also relevant for product owners — and worth a read for leadership teams — because the shift is ultimately about where the work happens.

Part 1 of 2: This post focuses on how AI changes software engineering work. The companion post explores the workflows and operational practices behind effective AI-assisted development.

TL;DR

• AI-assisted development moves effort away from typing implementation code and toward specification, direction, and review.

• Product clarity matters more, not less. Ambiguous tickets now generate wrong code faster.

• The teams that benefit most invest in reusable workflows, strong documentation, verification gates, and serious review culture.

The three movements

If you had asked me a year ago to describe my job, I would have said I write code. Ask me today and I would say something more specific: I still type, but less of that typing is code. More of it is specification, direction, and review.

1. I write specifications

Before code gets written, someone has to describe what should exist precisely enough that it can be built. With an agent in the loop, “precisely enough” is a higher bar than it used to be. A vague ticket that a human could intuit their way through can stop an agent cold or, worse, lead it to build a plausible version of the wrong thing.

The goal is to make two things explicit enough that implementation becomes a bounded problem: the product intent (what behavior should exist) and the technical intent (where it belongs, which patterns to follow, which existing pieces to reuse).

The product half is the one teams usually remember to write down. The technical half is the one agents most often have to infer on their own — and the one they most often get wrong. Not by producing code that fails to run, but by making architecture, abstraction, and placement choices that do not survive careful review.

Weak ticket: Add a filter to the search results page.

Agent-ready ticket: Add a status filter to the search results page using SearchResult.status. Options come from the existing status enum. Default is All. Empty results should show the existing empty state. Changing the filter should reset pagination but preserve the search query. Add tests for default state, selected state, empty results, and pagination reset.

The weak ticket produces twenty minutes of plausible-but-wrong code. The agent-ready ticket is far more likely to produce a working feature because it names the behavior, boundaries, and verification points before implementation starts.

2. I orchestrate

A capable agent can chase a problem on its own for a while, but it works best when it is pointed at the right sub-problem with the right context.

Knowing when to let an agent run, when to spawn a parallel investigation, when to start fresh, and when to pull a task back into the main session is its own skill. It is project management applied to a non-human collaborator.

In practice, this looks like starting an agent session with a focused brief, letting the agent draft a plan, spawning a side investigation when an unexpected question comes up, and stepping in when the agent stalls or wanders.

The agent does the mechanical exploration and implementation. The human still owns the direction of travel.

The concrete workflow we use — spec → grill → plan → implement → verify — is the subject of the companion post, Context Is the New Craft in AI-Assisted Development.

3. I review

This is the shift that surprised me most. A year ago, PR review was a slice of my week. Now it is closer to half of it. When an agent ships a change, I have to verify that it is the right change: safe, conventional, maintainable, and solving the intended problem rather than a plausible-looking adjacent one.

Agents help here too. We often run a separate structured review pass, preferably with a different model than the one that wrote the code. It catches missed tests, stale assumptions, and convention mismatches before human review, but it does not own the final judgment.

The net effect is less typing, more thinking, and a higher leverage ratio between hours worked and software shipped. That is what people mean when they say AI is transforming software development. It is not magic. It is a redistribution of where the developer’s attention goes.

What this means for product owners

For product owners, the biggest change is simple: AI makes ambiguity more expensive.

A human developer can often infer intent from hallway context, previous conversations, or product intuition. An agent usually cannot. If a ticket leaves a business rule implicit, the agent — or a developer working through one — may still produce code, but it may encode the wrong assumption very efficiently.

That does not mean product owners need to become prompt engineers. It means product intent, edge cases, domain language, and non-goals need to move earlier in the process.

The better the ticket, the better the output. The weaker the ticket, the more likely the team is to spend its saved implementation time on rework and review.

Agent-ready ticket checklist

• User goal: What user or business outcome should this change create?

• Business rule: Which rule, calculation, permission, or policy must the implementation respect?

• Source data: Which field, API, enum, state, or existing model should be used?

• States: What should happen for loading, empty, error, disabled, and success states?

• Edge cases: What happens when inputs are missing, stale, duplicated, partial, or invalid?

• Non-goals: What should the agent not change, even if nearby code looks tempting?

• Acceptance tests: How will the team know the behavior is correct?

• Definition of done: Which team-level readiness criteria — tests passing, docs updated, review gates cleared — must this ticket satisfy before it is shippable?

• Domain terms: Which names should be used consistently in UI, code, tests, and docs?

This also changes planning.

If implementation time falls but review time rises, the bottleneck moves. Teams should plan capacity for specification and review, not just coding. Otherwise they will generate more code than they can safely absorb.

What this changes for teams

The shift is not only personal. My workflow changed first, then the team’s workflow changed around it.

Code review becomes the central craft

When a substantial fraction of code is drafted by an agent, the reviewer becomes the last line of defense against subtle wrongness.

A structured review pass helps. Run independently — ideally with a different model than the implementer — it can spot missed tests, stale assumptions, and convention mismatches before human review begins. It does not approve the change, but it makes human review sharper.

That bottleneck has planning consequences. Faster implementation does not automatically mean faster delivery. If implementation capacity rises but review capacity stays flat, the team can create more code than it can safely absorb.

Planning needs to include specification time, plan review, verification, and PR review — not just build time.

Pairing changes shape

It is often one human and one agent, with a second human dropping in to review or grill the plan. We have found that pairing on plans produces better outcomes than pairing only on code.

The senior/junior split shifts

Work that used to anchor a junior developer’s day — a straightforward endpoint or a simple component — can now be done by an agent in minutes.

The growth path therefore needs deliberate reps in reading code, reviewing agent output, explaining tradeoffs, and tracing bugs from symptom to root cause. Teams should involve juniors in plan reviews and design discussions earlier.

Knowledge becomes more visible

Tribal knowledge now has to be written down because the agent cannot ask the person in the next chair. Teams that do this work end up with better documentation for humans too.

For leadership, investment in AI agents is really investment in the surrounding practice: review culture, planning rituals, written conventions, onboarding quality, and verification infrastructure. The subscription is rarely the hard part. The scaffolding is where the leverage lives.

What it adds up to

The skill of writing software with agents is not typing less. It is thinking more clearly about intent, context, human judgment, and the workflow guardrails that make mistakes harder to repeat.

Treating the agent as a faster keyboard leaves most of the value on the table. Treating it as a collaborator that needs clear direction, bounded context, and serious review changes the practice.

A year in, the work feels less like typing faster and more like engineering the system around the code: clearer intent, sharper context, stronger review, better documentation.

Less keyboarding. More judgment. More leverage.

The teams getting the most value from AI are not the ones generating the most code. They are the ones most disciplined about intent, review, and verification.

And yes — an agent helped draft this blog post and the image. A human grilled it.

→ Continue with the companion post, Context Is the New Craft in AI-Assisted Development, for the concrete workflow: how we curate context, run the spec → grill → plan → implement → verify loop, the failure modes we watch for, and the documentation and review practices that make it sustainable.