We Gave Developers AI Agents. But Kept Their Old Jobs.

I've been building solutions with software for decades. With today's coding agents I can sometimes get things done in hours that previously took weeks.

We've given our developers access to these tools too.

But the tools don't transfer my domain knowledge, architectural experience or understanding of our customers.

We spend so much time discussing AI capabilities and productivity gains. Much less time discussing whether our engineers and organizations are actually prepared for what comes with them.

We trained developers to close tickets

For years, many development teams worked in a pretty simple way.

Someone defines the requirements. Someone breaks them into tickets. Developers implement them. Tests pass, PR gets merged, next ticket.

Now we give these developers coding agents.

And suddenly we expect them to understand the business domain, challenge requirements, design architectures, guide agents and take responsibility for the outcome.

That's a different job.

Of course, good engineers have always done much of this. But plenty of organizations have spent years separating technical implementation from business decisions.

We wanted developers to focus on their tickets. And now we're surprised when they don't think beyond them?

I don't think every developer needs to become an architect or business analyst. But teams need to rethink where decisions are made and who owns the outcome.

In one of our own experiments, agents produced a buildable workflow. Looked promising. Except an important filter had disappeared.

Expected three rows. Got six.

The implementation looked fine. The business result was wrong.

You need domain knowledge to catch that. And you need to know what to verify.

No amount of generated code changes that.

And then there's the fear

I totally understand why some engineers are worried.

Imagine doing something for 10 or 15 years. You're good at it. You know your tools, your routines, how to approach problems.

Now your manager demonstrates that an agent can finish certain tasks in a fraction of the time.

What does that mean for your job?

AI will change how much engineering work organizations need and what kind of work they value. I don't know exactly how far that will go.

Telling everyone that AI will only make their jobs better would be dishonest.

And people don't change overnight.

Even in IT, where we work with new technology every day, we get comfortable with our routines.

Someone who spent years becoming a good implementation developer might not enjoy suddenly being asked to think about business strategy or architecture.

We can't expect people to make that shift just because we provide better tools.

And we shouldn't underestimate what fear of being replaced does to someone's willingness to experiment, make mistakes or challenge their manager.

What we're doing in our team

I'm in the middle of this myself. I don't have some perfect transformation strategy.

Our developers have access to Codex, Cursor and Claude.

We've also built a shared skill set in Git covering our architectures, standards, best practices and lessons from things we've repeatedly had to correct.

Knowledge that our engineers and agents can reuse instead of fixing the same problems over and over again.

It's part of our harness engineering approach.

In our regular catch-up sessions, I share my experiments. What worked, what failed, where agents produced convincing nonsense and where my expectations were simply unrealistic.

Now we're adding a weekly Agentic Engineering Lab.

60 minutes. Real workflows, hands-on experiments, failures and discussions.

I want to see how our engineers actually work with our harnesses. Where they struggle, what gets in their way and what they would do differently.

And I want critical feedback.

Not everyone agreeing with me because I'm the founder or because I've been doing this longer.

Ideally they'll find approaches better than mine.

We're just starting. We'll see how it works.

Changing how we decide what to build

This is another experiment I'm currently working on. And probably the harder one.

For years, most of our product direction came from me.

Customer feedback, market research, presentations, demos, discussions with customers. I would connect these things and decide what we should build next.

What creates value? What problems are worth solving? What belongs on the roadmap?

Now I'm trying to change how that works.

I still want to provide strategic direction. But I don't want to initiate and drive every feature myself.

I want engineers involved earlier. Understanding the problem, challenging the business value, proposing alternatives and taking more ownership.

We're experimenting with the whole pipeline, from an initial idea or customer problem to a finished feature and release.

Who identifies the problem? Who evaluates it? When do we prototype? Who makes the decisions? And who owns the result?

We're trying different approaches, gradually shifting responsibilities and seeing what works.

And this is where I have to challenge myself too.

I know our domain, the architecture, the history and our customers.

How much of my productivity with agents comes from AI, and how much from that accumulated knowledge?

How do I transfer it without becoming the person everyone still depends on?

And if I want engineers to challenge requirements, do I actually give them the authority to do so?

I also need to accept decisions I might have made differently.

That's something I have to learn as well.

Because giving people more responsibility while keeping all decisions with management doesn't make much sense.

Neither does expecting higher productivity while keeping the same processes, roles and measurements.

If engineers aren't allowed to challenge requirements, Codex won't change that.

So how are you dealing with this?

We're experimenting. I don't know yet what the right organizational setup will look like.

And there are questions I still don't have answers to. What happens when an experienced developer doesn't want this new role? How much ownership can we realistically distribute? And how do we measure whether any of this actually works?

I'm interested in hearing from both sides.

Engineering leaders: What are you changing beyond providing AI tools? Are you changing responsibilities and decision-making, or just expecting higher output?

Engineers: How are you preparing for this shift? Are you getting more ownership? Do you even want it? And what is your employer doing to support you?

Especially interested in what you've tried that didn't work.