Working with AI in Software Development: the New Workflow (and What Engineering Still Owns)

Introduction

Let me start with a scene you've probably lived before.

You're sitting in front of your editor, you get a task that sounds simple, and you think:

"this could be done by AI, right?"

You open the AI chat, paste the context, ask for the implementation…

And it delivers. Beautiful.

Then you copy, paste, run…

…and something breaks.

Or it works on your machine, but breaks in production.

Or worse: it works today, but nobody understands how — and three months from now, you'll pay the price for the decisions you never verified.

Now tell me something:

have you ever felt that working with AI got faster to do, but not necessarily safer to ship?

If so, this post is for you.

Because AI didn't come to replace engineering.

It came to change where engineering happens.

The concept: what "working with AI" really means

Before anything else, let's align on what I mean by "working with AI."

Because there's a huge difference between:

using a chatbot to help you with code, and
building workflows where AI agents participate in the entire process

In the first case, AI is an isolated tool. You ask, it answers, and the workflow stays the same.

In the second, AI becomes a participant in the process. It receives intent, plans, executes, tests, fixes… and hands the result back to you for verification.

It's this second form that's transforming software development today.

Think about it… if AI can execute several stages of the workflow, someone needs to make sure what it executes is correct. And that someone is you.

In other words:

AI accelerated execution. Engineering still owns the outcome.

The real problem: "doing it fast" without "knowing what you're doing"

This is the part nobody talks about.

With AI, generating code became absurdly easy.

But…

who makes sure the solution follows the project's architecture?
who verifies the data is secure?
who defines what "done" means before AI starts?
who maintains the system when it evolves a year from now?

If you let AI work alone and just accept whatever it produces, you end up with a silent problem:

code that works… but that nobody truly understands.

And here's the uncomfortable part:

you gained time now and you'll lose much more later.

That's exactly where engineering — that "traditional" part some people think died — becomes more important than ever.

Makes sense so far?

Now here's the good news: there's a way to get AI's speed without giving up control. That's what we'll see next.

The solution: a workflow where humans and agents collaborate

The answer is not "use more AI."

It's also not "go back to hand-written code."

The answer is a workflow where each side does what it does best.

Let me walk you through the pipeline I use in practice, step by step.

1. Human Intent (that's on you)

Everything starts with a decision AI doesn't make:

the goal.

"Users must only be able to redeem a coupon after confirming their email."

That's intent. It's not the solution — it's the why.

Before any agent starts working, there must be:

a clear goal
the requirements
the constraints (what must NOT happen, what must NOT break)

Without this, AI will invent a goal for you. And most of the time, it's not what you wanted.

2. AI Agents (the machine steps in)

This is where the agent receives the intent and takes over the work.

It's not a chat where you type and wait.

It's a process: it receives context, decides next steps, and acts.

In my case, that means agents that:

read the existing codebase
understand the project's patterns
execute implementation tasks
run tests and fix whatever they find

But notice: all of this happens inside a controlled workflow, not in a vacuum.

3. Planning & Reasoning

Before writing a single line, the agent decomposes the problem.

Instead of "implement coupon redemption," it breaks it down into:

model the data → validate input → update status → notify the user

And then something important happens:

it proposes an approach.

And who evaluates whether the approach makes sense?

You.

That's the moment to say "yes" or ask for adjustments — before wasting time implementing the wrong thing.

4. Tools / APIs / MCP

A useful agent doesn't work from memory.

It uses tools: it accesses the repository, looks up documentation, calls APIs, runs commands.

There's a standard that's been making this much easier: MCP (Model Context Protocol) — a protocol for connecting agents to tools and data in a standardized way.

const tools = [
  readFileTool,
  searchCodeTool,
  runTestsTool,
  // and so on...
];

The idea is simple:

instead of the agent "guessing" how the project is, it inspects the project for real.

That completely changes the quality of what comes out the other side.

5. Code / Data / Systems

Time to implement.

The agent writes code, models data, integrates with other systems…

But here's the detail:

it's working over real context — the existing code, the project's patterns, the available data.

It's not "writing an isolated function on a blank page."

It's implementing inside a living system.

That's why the previous step — giving the right context — is worth gold.

6. Testing & Evaluation

This is where the workflow pays off.

The agent doesn't deliver and leave. It:

runs the tests
evaluates the result (this is where agent evaluation — evals — comes in)
checks whether the requirement was met

const result = await agent.execute(goal);
await agent.evaluate(result); // tests, rules, acceptance criteria

Think of this as a gate:

work only passes if it matches what was defined at the start.

That's what separates "pasting code" from a real workflow.

Makes sense so far?

7. Human Verification

The step nobody can skip.

The engineer reviews what was produced, verifies the decisions, and owns the result.

It's not distrust.

It's product responsibility.

Architecture, security, validation, observability, long-term maintenance…

that is still yours.

The agent is faster. You own it.

Just to reinforce, because this is the point many people miss: delegating the execution is not the same as delegating the responsibility.

8. Production

That's when the work goes to the real world: CI/CD, cloud, observability, operations.

And notice something nice about this workflow:

the same loop we use to build with AI, we can also build into our products.

Humans set the intent, agents execute, engineers verify, and the systems learn.

Practical examples: from request to deploy

Let me show you how this translates into action, with two real scenarios.

Scenario 1: implementing a feature

Imagine the goal:

"add an installments field to the order form, without breaking the total calculation."

The workflow would look like this:

You explain the goal and the rules to the agent.
The agent finds where the order is modeled and where the total is calculated.
It proposes where the field goes and how it affects the calculation.
You approve the approach.
It implements, runs the tests, and fixes whatever breaks.
You review, evaluate edge cases, and approve.
CI/CD runs, and it goes to production.

At no point does the agent decide the business rule on its own. It executed. You decided.

Scenario 2: investigating a production bug

Another example: a report that "some orders are going missing."

The agent can:

search the logs for error messages
trace the order creation flow
cross-reference with what changed in the last deploy

That's an analysis task, not "typing code." And it's exactly the kind of thing AI helps with a lot.

But the decision on how to fix it — change the flow, add validation, improve the logs — remains yours.

Where this shows up in practice

This model isn't theory. It's already in:

IDEs and editors: autocompleted and generated code with context from your project
Agent CLIs: agents that navigate your repository, run commands, and edit files
Protocols like MCP: connecting agents to databases, APIs, and tools
Product systems: support assistants, internal automations, analysis agents
Evaluation pipelines: automated tests that assess agent output (evals)

And the trend only goes one way:

the number of agents working inside products will grow.

The competitive edge won't be "who uses AI."

It'll be who knows how to orchestrate AI responsibly.

How it works "under the hood"

What makes this workflow work is less magical than it seems.

Underneath, there are pieces you already know:

a model (LLM) that turns a prompt into a response
tools the agent describes and can call (tool calling)
a loop where the agent: thinks → acts → observes the result → thinks again
evaluation: criteria that define whether the result is acceptable

MCP comes in as the "plug" that standardizes the connection between the agent and the tools.

Instead of every integration being ad-hoc, you have a single way for the agent to talk to databases, APIs, and the file system.

It's like what HTTP was for the web: a common standard connecting different parts.

When to use and when to avoid

This workflow helps a lot when:

the task is well-defined and the context is accessible
tests exist to validate the result
you're inside a project with clear patterns

Now, being honest, there are moments where the right path is different:

when the business rule is too ambiguous to turn into a goal
when sensitive data is involved and you don't control what the agent reads
when the risk is high and you can't evaluate the result
when understanding why the decision matters more than speed

The most common mistake is treating AI as a final delegate instead of a supervised collaborator.

I've been through that. Trust me: the price shows up later.

Pros and cons

Pros, in practice:

real speed: what took hours becomes minutes
broad context: the agent checks the whole project, not just the open file
cheaper iteration: experimenting with approaches stops being expensive

But the cons are also real:

the result depends on the quality of the intent you provided
without tests and evaluation, speed becomes technical debt
the risk of trusting what wasn't verified grows along with the power

Notice that both sides of the scale depend on you?

That's not a coincidence.

Simple summary

If you take only one idea from here, let it be this:

AI doesn't replace engineering — it changes where engineering happens.

The workflow is:

well-defined intent → agents execute → tests and evals gating → human verification → production.

And the loop repeats: humans define, agents execute, engineers verify, systems learn.

Conclusion

We're living in a curious moment in the history of development.

For the first time, we have a workforce that doesn't get tired executing technical tasks.

But all that power only becomes value if someone is holding the measuring stick.

And that someone, even today, is the engineer.

The question isn't "will AI take my place?".

The right question is:

"am I ready to be the engineer who orchestrates AI — instead of just consuming what it delivers?"

If you made it this far, I think you already know the answer.