Building with AI Agents: The Expert Still Drives, but the Journey Changed Forever

A couple of years ago, when someone asked me how long it took to build an internal tool—a dashboard, an automation script, a microservice to solve a specific team bottleneck—my answer always had the same shape: "it depends, but plan for two to four weeks if we do it right."

Today that same conversation ends differently. Plan for two to four days. Sometimes, two to four hours.

It's not magic. And most importantly, it's not that the expert stopped mattering. What changed is who does what, and when each person enters the process. That's the conversation I want to have today.

Before: The Developer as Translator

For a long time, building software was an exercise in translation. An expert understood a problem—a business process, an operational bottleneck, a customer need—and sat down to translate it into code line by line.

Most of the time wasn't spent thinking about the solution, but writing it: the boilerplate of the endpoint, the project configuration, the test that validates the edge case, the documentation no one wants to write but everyone needs to read.

The expert carried everything: the what, the how, the when, and the writing of it. It was slow because it had to be.

Now: The Expert as Conductor

When we work with well-orchestrated AI agents, the distribution changes. The expert still defines the what (what problem we solve, what success means, what constraints exist) and the how at a high level (what architecture, what patterns, what design decisions are non-negotiable).

But the agent can take on huge chunks of the how at a low level: scaffolding the project, writing the first working version, generating tests, keeping documentation current, refactoring when something smells bad.

The interesting part isn't that the agent "codes for you." It's that it frees you from mechanical work so you can spend more time on work that actually requires judgment. And it turns out the work that requires judgment is, coincidentally, what separates a mediocre tool from a good one.

Real Speed (and the Trap of Measuring It Wrong)

When we talk about productivity with agents, there's a temptation to measure it in lines of code per hour or tickets closed per sprint. That's a bad metric.

What really changes is something else:

The time between "I have an idea" and "I have a working prototype I can show" collapses. What used to be a conversation of "let me estimate it and I'll tell you next week if it's worth it" is now "give me twenty minutes and I'll show you something clickable."

That doesn't just speed up delivery, it changes how we decide what to build, because experimentation stops being expensive.

The cost of throwing away a version also drops. When rewriting a module costs an afternoon instead of a week, you stop clinging to early decisions that no longer serve you. Quality goes up not because we write better the first time, but because we iterate more times on the same idea.

And maintenance—that invisible work that eats half the budget of any serious tool—becomes manageable. An agent can help you understand code you wrote six months ago, update dependencies without breaking anything, document what already exists. Things we knew we should do and never prioritized.

The New Role: From Writer to Director and Validator

If I had to sum up in one sentence how the developer's role changed, I'd say: we went from writing to directing, reviewing, and validating. And while it sounds like demotion, in practice it's the opposite: it's more intellectually demanding work, not less.

Directing means knowing what to ask the agent. That requires having clear architecture, domain mastery, business constraints. An agent without context produces code that looks right but solves the wrong problem. Someone who directs an agent well needs to understand the problem better than someone coding it by hand, because now they have to articulate it precisely instead of discovering it while writing.

Reviewing means reading critically and quickly. The agent produces a lot of code in little time, and accepting it without question is the recipe for accumulating technical debt at record speed. Review requires having a sense for what's readable, what's maintainable, which patterns fit the rest of the system and which don't.

Validating is the part no agent can assume for you: Does this actually solve the user's problem? Is it safe? Does it perform well under load? Does it break anything downstream? Those questions require real-world context, conversations with people, intuition built from years of your own mistakes.

Responsibility Doesn't Delegate

I want to be very clear here, because it's where I've seen most teams get into trouble: technical responsibility stays entirely with the human expert.

If a tool leaks data, if a script deletes what it shouldn't, if a design decision leads you up a blind alley in six months—the person responsible is the one who approved that code, not the agent who wrote it.

This isn't a legal detail or a formality. It's what makes the work still make sense. An agent can generate ten reasonable solutions to a problem; someone has to decide which is right for this context, this team, this user. That decision rests on experience that doesn't delegate.

What changes is where you spend your attention. Before, much of it went into producing the code. Today it goes into evaluating it, integrating it, and owning that it does what you promised. Less keyboard, more judgment, but not less work.

What We're Learning at HechoX

The projects where the expert + agent combo is working best have three things in common:

1. There's a clear person responsible for each piece, with authority and context to review what the agent produces 2. The agent gets rich context at the start—not just "do X", but "these are our conventions, here's the rest of the system, these are the cases that matter" 3. There's a real review cycle, where generated code is read, tested, and questioned before it merges with the rest

The projects that struggled usually fail on the same thing: treating the agent like a junior you hand off to without thorough review. The result is code that works in the demo and falls apart in production.

Where We're Headed

My conviction at this point is this: internal tools, prototypes, and much of custom software are entering an era where they're built in hours, not weeks, and that's going to redefine which problems are worth solving with bespoke code.

Many pain points that didn't justify the cost before, now do.

But anyone still believing this means "fewer experts" is going to crash. It means experts doing more, with more reach, deciding over more things. It means the difference between a team that leverages this and one that doesn't won't be in who has access to agents—everyone already does—but in who has the discipline, judgment, and domain mastery to direct them well.

The expert still drives. What changed is the engine.

---

Are you building with agents? Tell me what you learn along the way.