Where Is the Engineering Work Now? Redesigning Development Around AI

Agents can already write most of the code in a sprint. Yet we still run that sprint as if five developers were each typing their own ticket. This post is about where the engineering work actually sits today, and what happens when you redesign the development process around AI instead of bolting AI onto the old one.

I've been thinking a lot about what software development actually looks like today.

A sprint, as it really happens

On one of our full-stack Rails projects, the process looks roughly like this:

1. The Product Owner writes a PRD.
2. The Dev Lead turns it into a structured Implementation Plan: architecture, database changes, dependencies, outstanding questions, edge cases and testing requirements.
3. From that plan, we create tickets, estimate them, put them into a sprint and assign them to developers.

And then something interesting happens.

We still behave as if developers are individually "writing the code."

But increasingly, that's not what is actually happening.

A developer takes a ticket, gives the context to Cursor, Claude Code, Codex or another coding agent, gets an implementation, reviews it, adjusts it, opens a pull request and sends it for review.

Then we wait.

PR review. Changes requested. Another review. Dependencies between tickets. Someone is blocked. Someone hasn't opened their PR yet. Someone stretches a two-hour task across two days.

Eventually, everything gets merged into UAT, the PO verifies the result, and we produce some form of delivery report for management.

The agent wrote the code in minutes. The sprint still took two weeks.

So where is the engineering work?

I started asking myself a simple question: where is the actual engineering work in this process?

Increasingly, I think it is here:

• Writing and reviewing a strong Implementation Plan
• Making architectural decisions
• Resolving ambiguity before implementation starts
• Reviewing AI-generated code
• Preventing AI slop from entering the codebase
• Verifying integration and end-to-end tests
• Making sure the complete system works
• Documenting what was actually delivered

Notice what is missing from that list: typing the implementation of each ticket by hand.

If that is true, then maybe we are optimizing the wrong workflow.

Five developers, five agents, five PRs

Why should we wait for five developers to individually take five tickets, feed them into five agents and create five PRs?

Why couldn't the development environment do that immediately?

Imagine giving a sufficiently detailed Implementation Plan to a tool that understands the repository and the team's engineering rules. That tool:

• determines the dependencies between tickets,
• launches multiple agents in parallel,
• creates implementation branches and pull requests for the entire sprint,
• runs the required tests,
• applies predefined engineering and security guardrails,
• reports what succeeded, what failed, and where a human decision is required.

And then the development team starts where the valuable work actually is:

Architecture. Review. Testing. Verification.

	AI added to the old process	Process redesigned around AI
Who starts the implementation	Each developer, one ticket at a time	The environment, for the whole sprint at once
Where time goes	Waiting on handoffs, blocked tickets and PRs nobody has opened yet	Reviewing, testing and deciding
How quality is protected	Hoping each prompt was good enough	Shared engineering rules, guardrails and required tests on every PR
What management gets	A report someone writes at the end	A delivery report generated from what actually ran

Developers don't disappear

Their job moves up the abstraction layer.

Instead of spending most of the sprint producing code that an agent can already produce, engineers become responsible for making sure the right system gets built, and that the AI-generated implementation is actually good.

That is harder, not easier. Reviewing an agent's pull request well takes more judgement than writing the same code yourself. Deciding what goes into the plan, and what the agent must never touch, is real engineering. So is designing tests that prove a requirement instead of only exercising the happy path.

What we're building at Rubycode

We're already experimenting with this approach at Rubycode. Here is a short video that explains the idea and shows what we've built: one feature described in plain language, planned, split into tickets, implemented by agents, reviewed by developers and proven by tests.

From the idea to merged, tested code: the plan, the tickets, parallel agents, developer review and the delivery report.

If you believe this is where software development is heading, we can help in three ways:

• Set up an AI-driven development workflow around your existing process.
• Train your current engineering team to work this way.
• Provide an entire team if you need one.

We adapt the tooling, agents, guardrails and workflow to your existing development process, not the other way around.

Your turn

I'd be very interested to hear how other engineering teams see this:

Are we still adding AI to the traditional development process, or is it time to redesign the development process around AI?

Write to me at ivan.blazevic@rubycode.co or book a 30-minute call, and I'll show you how it would work on your codebase.