# AI Engineering: From Code Generation to Factory Architecture

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-05-08

## Transcript

If your team has been running AI in a proof of concept, but you're still figuring out how to run it reliably in production, you're not alone.
That's the gap most engineering teams are navigating right now.
QCon AI Boston, this June 1st and 2nd, brings together senior engineers, software architects, and technical leaders who've already made that shift.
They'll share the patterns that scaled, the mistakes that didn't make the blog post, and what I'd actually do differently.
No hidden pictures, just senior practitioners helping senior practitioners.
Learn more at boston.qcon.al.
Good day, folks.
This is Shane Hastie for the InPokio Engineering Culture Podcast.
Today, I'm sitting down.
Half the world away with Mike Parker.
Mike, welcome.
Thanks for taking the time to talk to us.
Hi, Shane.
My normal starting point in these conversations is, who's Mike?
Yeah, so I'm the VP of Engineering here at Chirin Tech AI.
So we're a London-based cloud development platform company.
We're trying to build a system to bring the joy back into development.
And I've been doing that for the last year.
Before that, I was at Docker for seven years.
So building out Docker Hub, Docker Desktop, Docker Scout, lots of broad scale developer tools.
I'm very interested in developer tools.
Before that, I was a backend engineer interested in test driven development and clean code and all that sort of fun stuff before moving into management.
And even before that, I was in game design.
So I started off in games as a young boy, very keen on building those kinds of things.
But now today, I'm very interested in the future of AI tooling.
and accelerating developers and bringing that joy back into development.
So let's dig into that joy back into development.
Where has the joy gone?
What's happened?
Yeah, it's a really interesting question.
And it really depends who you talk to.
Some developers are having even more fun than they've ever had, especially if they're working on greenfield code bases, shipping small products, small services, where AI is like supercharging their productivity.
But there's also a lot of developers that are working on legacy code bases in large enterprises.
They might have a lot of in-house libraries.
They might have ways of working that AI is not necessarily trained on.
And getting AI to output code in those environments is very difficult.
And we're almost seeing a polarization of opinion in this space because software development is so varied.
And a lot of people tend to talk about software development as if it's just one space.
And it's not.
And so you've got people on the Greenfield side saying, wow, AI is amazing.
You can get 10,000 times productivity increase.
And then you've got people on very complicated legacy code bases, locked to old technologies.
The AI is just churning out garbage.
And these people are not talking enough.
I want people to talk more and understand that there's different code bases, there's different companies.
So I'm mostly focused on...
the people that are suffering, right?
Like these code bases where AI doesn't work, how do we make it work better?
And to a lot of these developers, what they're finding is that AI has taken over the fun part.
And the fun part is a lot of the time deciding on the structure of the code, the architecture, getting things right.
And instead we're left with code review.
No one likes doing code review.
So we're sitting there, AI generates some code, it's not right.
We review it for ages.
We tell it, no, you've done this wrong.
You've done that wrong.
We write rules files.
They don't listen to the rules.
We try a different model.
We try a different package.
And then we have to go through all this pain.
And often people say it would have been quicker to do it myself and it would have been higher quality.
And you're stuck like, do I use the new tools?
And especially when your engineering leaders are pushing these things down, they say everyone has to use AI.
And then the developers on the ground are struggling.
because they can't teach these things to do a good job.
And so I think that's where a lot of the joy has gone.
So for the engineer in the large enterprise, that joy is being sucked out of.
And you're right, code reviews is the last thing we actually enjoy doing as developers.
We want the thrill of the creativity and so forth.
How do we make this work?
I think there's two aspects to this.
I think that we need better tools to help AI produce the right code first time around.
A lot of the cutting edge AI developers are essentially building their own factory.
They're building their own AI agents.
A lot of the AI tools today, like Claude Code and Cursor, Copilot, they have huge configurability.
Use sub-agents, you can use rules, and your rules can set up more sub-agents, and you can have MCP servers, and you can do prompt engineering.
It's like kind of a new role.
You're not writing the code anymore, you're writing the factory to write the code.
And there's an emerging class of experts who have become expert in building their local factory, their own agents, their own rules, etc., etc.
But very often these things aren't widely shared amongst their team.
And so you have this huge imbalance with some of the AI experts.
And then how do you spread that joy to the team?
How do you get them upskilling everybody else rather than having their own sort of personal productivity factory?
But I'm not convinced that planning more ahead of time before it runs off and writes code is enough.
There's definitely more that we could do there out of the box to provide tools.
so that you really check what AI is going to do before it does it.
And that's helped me immensely.
I'm sort of on this side of building the factory, right?
So I've got my own home set up and I'm tweaking my rules and my agents.
And I'm very clear, like, don't do anything.
Let's decide, you know, tell me what you're going to do first.
And so I think that's one aspect of it.
It's like really nailing the requirements, the technologies, the structure before you write any code.
So better planning tools is number one.
But also when it's finished, I think we need better.
code review tooling.
Our code review tooling isn't really designed for the quantity of code that AI is churning out.
It's very hard to say, why did you do this?
Why did you do that?
Can you move that over here?
The whole review interface, I think, needs an update for this AI era.
And I think that's true across the board for the full SDLC, by the way.
A lot of these things need completely redesigning, including the IDE.
But then after code review, even after your code is merged, You know, today's code is going to be out of date tomorrow, right?
There's always going to be maintenance work and you probably have lots of legacy code.
So we need some systems to keep this code maintained over time.
Is it going to be the developers that are doing that?
And I speak to a lot of developers, they have a huge amount of maintenance work to do.
And this is really boring work, right?
No one wants to upgrade your Python version or your .NET framework or, you know, oh, this thing has been deprecated.
Oh, I need an extra parameter on this field.
And LLMs aren't necessarily trained on every single version of every library.
And if something came out like yesterday, like .NET 10 was released recently, and many LLMs are still like, .NET 10 doesn't exist.
I'm like, yes, yeah, it came out.
Like, I need to switch to .NET 10.
So I think at the end, we need better maintenance agents and tooling to help take away that burden from developers so they can focus on the creativity and the problem solving.
building business value and getting back to what I consider like the fun part of development and not so much, you know, upgrading framework versions or doing code review.
One of the things that we hear a lot is that as we generate code using the ILMs, the pull requests are getting bigger.
The quantity of code.
Now we've spent decades trying to get to smaller.
tighter pieces, microservices, design, make it small, make it tight.
Have we broken that?
Yeah, I think we have.
And it's an interesting question.
Would you rather have one pull request with 100 changes or 100 pull requests with one change?
When I was writing code, not so much anymore, but I would always open lots of small pull requests and even small refactorings.
If I was doing a bug fix and I knew there was some refactoring to do, I would roll back, I would do the refactoring, I would open a pull request, then I would do the bug fix, open a second pull request.
And so a lot of my pull requests were like 10 lines, 50 lines, very easy to review.
And if the test failed, it was obvious exactly what went wrong.
Now, does that scale in the world of AI?
Maybe.
I don't know.
It's clear from history, no one's going to review 10,000 line pull requests.
Are they going to review 10,000 pull requests?
Well, I don't know either.
You know, this is very difficult.
I think at some point we're going to have to stop reviewing code.
I think that's ultimately what's going to happen.
But for many companies, they're not ready for that.
They're not ready yet.
AI is making too many mistakes.
It needs too much reviewing.
People's factories aren't mature enough.
And we're in this awkward space where some companies and teams, they don't need review.
or at least they don't think they need review.
And other companies are very much still, you are responsible for every line of code that you write.
Make sure it's good before I review it.
And yeah, we're in that transition period and it's going to be ugly for a while, I think.
But imagine we could get to the space where we don't have to review code anymore.
Like that would be magical, wouldn't it?
Yeah.
Now we touch on a topic that I know.
It was one of the things you and I touched on before we started recording is trust.
How do I trust this code that has been produced, a human or AI or some combination thereof?
Yeah, I guess maybe we get philosophical.
Like what does trust really mean?
I come from a world of continuous delivery where...
We merge to production all the time, like multiple times a day.
And I'm a big believer in that.
Merging and deploying very small changes very quickly.
To do that, you need fantastic monitoring systems.
So if something breaks, you know about it immediately.
And so I think you need that anyway.
And whether it's a human that breaks it or an AI that breaks it, I don't think it matters.
You need to be able to respond to those things, roll it back.
I mean, this isn't true for every company, right?
You can't afford to do that if you're building.
a space rocket, right?
For a lot of people, if they're just building an e-commerce website or some server online, you know, AWS goes down often enough, right?
Nothing's perfect.
It's fine to merge and deploy some small bugs and then we'll fix it as we go.
But I think the bigger question is, if people are submitting code that is not up to standard, then what do teams do about that?
And I fall back to engineers being responsible for the code that they submit.
Ultimately, if they want to submit a pull request that's full of bugs, that's not good, right?
And they can't just blame AI.
So I think we have to take some responsibility for the code we submit.
And, you know, I'm largely happy for them to fix that in any way they like.
They can write a better factory.
They can get some review tooling, either AI or not.
They can split up their pull requests.
They can write more tests.
They can do some pair programming.
They can get some draft code review ahead of time.
You know, there's lots of different ways we can improve code quality.
And a lot of these traditional methods still apply, I think.
I guess it depends really what we mean by trust and if there's a sort of a wider issue around trust in AI.
Coming back to writing the factory, building the factory, I didn't go into software engineering to be a factory worker.
I'm an artisan.
I'm a crafts person.
How do we bridge that?
Yeah, I think the question is, can you fall in love with crafting the factory?
I wouldn't describe a lot of these people as factory workers.
I would say they're more factory architects, factory managers.
And I think there is joy to be had orchestrating these different agents and systems.
But it's one step removed from...
the ultimate customer that you're trying to serve, right?
If the customer is trying to buy your product on an e-commerce site, for example, and you're busy making your agent output better formatted code, you're one sort of abstraction away from the customer.
And historically, we've been taught that's a bad thing, right?
We want product-facing teams.
The whole agile process was about connecting customers and stakeholders much more tightly with engineering teams.
And so pulling these people away, And focusing on the factory could be seen as a step in the wrong direction because they'll lose sight of what we're trying to achieve for the business.
But I don't think everyone needs to be a factory architect.
I don't think this world is very efficient if we're all building our own factories.
I think we could see an emergence of an AI platform team, essentially, that are basically building developer tools for engineering organizations.
And they're rolling out agents and rules and structures.
so that everybody else can focus on delivering value.
So this is the platform team on steroids?
I mean, it's a little bit different because like many platform teams, they work on cloud development and a lot of these factories are being run locally.
So I do think we need a stronger tool set for rolling out like local factory configurations.
I brainstormed a bit of this when I was at Docker.
Because Docker containers and images are very interesting as a way of putting out developer tools and you've got a sandbox environment.
So agents aren't going to accidentally delete your hard drive and all this fun stuff that you see happening.
But I think there's a gap in the market and on our tooling space there.
How do we roll out these tools?
Like if I write a new rule across all of my projects, how do I give that to you in a seamless way?
Like how do you log on and just have a new set of agents and rules and everything's been upgraded and maybe I can give you a different model?
Or I can use a different model for planning versus coding.
I've got these review agents that you can run.
You know, all this works quite well in the cloud.
And so I think there's another debate to be had about how much of this should happen in the cloud and how much should happen locally, because you don't necessarily want 100 agents running on your laptop all the time.
And there's another argument to be said, like you want these agents to be working overnight when you're asleep after you turn your laptop off.
But local IDEs.
have been very sticky, right?
Lots of people have tried to build ideas in the cloud.
And some people have moved, but lots of people still love their local environment.
Even though you have to install a hundred different tools and things don't work all the time and you've got your environment and you've run out of space and you don't have enough RAM, people still love their local environment.
So, you know, it's going to be very interesting to see where this future goes.
Do we have some sort of hybrid methodology where some of these things are running in the cloud, some of the things are running locally?
Where does this factory live and what are the interface points?
What's the makeup of the team that is integrating AI today?
What's different about teams?
I think we're seeing a blurring of roles a lot when it comes to product management, design, front-end, back-end.
AI gives this ability for anybody to become not an expert, but...
knowledgeable enough so they can have the conversation.
I did a bunch of game design, but I've not done training on UI design.
But if I feel like a UI feels off, like the design, I can jump into AI and just have a quick conversation and say, what's the industry best practices for an input form?
Or like, I want people to sign up to my wait list.
How many fields should I ask them for their job title?
And how's that going to affect people signing up?
And I can immediately get world-class advice.
I mean, if it doesn't hallucinate and it doesn't lie to me, right?
Hopefully it doesn't too much.
But that means that everyone can now start participating in conversations, which I think is really interesting.
And tools like Lovable, for example, allow product managers to very quickly prototype engineering solutions, right?
So a product manager can think of a feature and very quickly sketch something out that people can actually click on.
And I think this actually brings product management and engineering closer together in some ways.
because they'll start noticing the edge cases, right?
So engineering and product management in my history, it's always been like, hey, can you just add this button?
It's like five minutes, right?
And engineering's like, that'll take us a month.
And it's like, what?
Why is that going to take a month?
Well, have you thought about this and this and this and this?
And it's like, I don't want to think about this.
I'm focused on the customer.
The customer has this problem.
Please solve it.
The danger, of course, is that you build a prototype and you think it's the finished product.
And it's like, well, I did it in five minutes.
Why are you guys taking a week?
So there's this Dunning-Kruger effect that we are also seeing where it's like, oh, I can code because I've typed something into Lovable.
So I think, yeah, there's two sides to the coin on that.
So roles meshing, AI tooling becoming part of that.
What else is changing in the team environment?
I guess the role of full stack developers.
versus pure backend frontend developer split is an interesting one.
Throughout my career, I've seen both approaches.
Before I went into management, I was very much a backend engineer, interested in infrastructure and DevOps and scaling things, really good microservice boundaries and API specs and all that fun stuff.
But now we have this ability to churn out code under the right rules.
And I think it's becoming more important to make sure our backend is extremely strong.
And then that lets you, I guess, vibe code some of the UI elements quickly.
And all the UI engineers are going to hate me for saying this, right?
So sorry about that.
But I do think also there's an enhanced need for setting up the framework to allow these tools to work.
So at Chirintech, We've got a heavy focus on what are the patterns we're going to use?
What are the libraries going to use?
And we choose these things based on what LLMs are trained on, what they're going to be good at.
And so we'll set out with a framework in mind and a code-based style, and we'll see if AI can follow that style.
And then we feed that feedback back into the loop, right?
Is AI good at following these rules?
And either we change the rules.
or we try to change AI.
But I think these things do need to work in tandem.
You don't want to be fighting against the training.
We haven't seen the end of this.
Do we have full-stack engineers?
Do we have backend?
Do we have these factory architects in teams?
We're also seeing emergence of researchers and data science engineers inside teams.
The other thing to consider is if engineering productivity skyrockets, where is the bottleneck?
And then I think the bottleneck becomes, your understanding of the customer problem.
Like it used to be the case that you could figure out what customer problem to solve and then you can spend nine months fixing it.
If that nine months becomes one month, your discovery process needs complete overhaul, right?
You can't just talk to developers about the same problem for nine months.
You've got to make decisions in hours and days, not weeks and months.
So I think there's a knock-on to...
how you talk to customers, how you collect data, how you make decisions.
And then also it shortens the loop for feedback.
Engineering has always been the most expensive way of learning.
You know, product management books always talk about stop building things to learn, right?
Just draw a diagram on a piece of paper and give it to the customer and say, you know, is that what you want?
Would that help?
Right.
And then you can get more in that 10 minutes than building the thing for two months.
But if that flips on its head and you can build a product in like a day or at least a prototype in a day and give them the prototype, that changes discovery.
If the bottleneck is product discovery, you're going to need more product managers, more researchers, more designers, and engineering shrinks as a percentage of your workforce, I guess, at that point.
This is the Engineering Culture Podcast.
What are the culture shifts, the teamwork shifts that are happening with these changes?
Yeah, so there's some good things and bad things, I think.
One of the bad things is that people are becoming a bit more isolated in engineering teams.
Everyone has their own setup.
Everyone's using AI in different ways.
And some teams are handling this really well.
I've actually seen the reemergence of mob programming on some high-performing teams, where because the code is so fast to create, team synchronization is actually becoming more important.
than the speed at which you generate code.
So I was talking to a development manager a couple of weeks ago.
They do all of their code on one computer with five people.
They basically live their life in a meeting room, discussing the problem, the structure, and then they type in the exact prompt and the plan, and then AI writes the code.
And then they all review it.
They discuss it, which I love.
That brings warmth to my heart.
People working together again and talking.
having fun.
You know, that's how development should be.
I think we all went into this profession because we like computers more than people, but yeah, we do need human connection as well.
So I think getting people in a room and working these things through together is a great way of working.
But I think lots of teams are not doing that.
A lot of teams are still stuck on their own computers and we're kind of seeing this combination of like fear, denial, bargaining, grief.
Some people are worried that they're not keeping up with the latest tools.
And they may be embarrassed to ask questions about why AI is going wrong for them or how do I get it working?
So they're more shy about working together and setting up their environment.
And they see some phenomenal gains from other people and they're worried that they won't compete.
And this drives people sort of inwards.
So you're just stuck on your own environment.
You're trying to make sense of it.
You're trying to read things.
So I think we need to break out of that and we need to connect people more.
That's the two ends of the spectrum for team culture.
I guess the other thing is how leadership communicates and approaches adoption of AI tooling.
And we're seeing various takes on this.
You've probably seen the extreme end of the spectrum where people are like, you're going to be fired unless you use AI.
Everyone has to go all in, spend a month.
All you're doing is learning AI.
And that produces like a lot of fear and worry from people, right?
And this is what these messages are intended to do.
It's really kicking people and saying, you can't just ignore this, you have to learn.
But at the same time, the people on the ground are seeing a lot of the problems that you might not read about on LinkedIn or in podcasts.
And so I think there's a growing disconnect between the level of hype believed by some of engineering leadership and the reality on the ground, and that's breeding distrust.
From both ends, right?
Like leadership, thank God, my developers are so slow.
They're not adopting AI.
I read on LinkedIn that I can do everything in 30 minutes.
Why is this taking a week?
And at the other end of the spectrum, engineering, like, have they used AI?
Like, look at our code base.
You can't just build the whole thing in JavaScript and Python.
I got .NET 2 code.
Like, it doesn't work.
So I think that's a cultural divide we need to bridge as well.
What's the important question I happen to ask you today?
I guess.
The important question for us all is, what do we want our industry to look like in five to 10 years?
And, you know, maybe me and you can't solve that here and now.
But I do think it's as important as an industry to see where this is going and agree if we want this or not.
And maybe we don't have a choice, but I do think it will end up in a better place.
I do think it's possible to build AI systems that help us return to joyful development, offload all of the boring and the mundane work, primarily running in the cloud autonomously, being able to bring teams together.
How do we iteratively get there?
I think is difficult.
And everyone's trying to make progress in these areas.
But I do think we need to agree what we want our job to be.
in five years' time?
Is our career going to go away?
Is it going to change?
Are we okay with it?
And I guess if not, what do we do instead?
Some pretty deep and thought-provoking questions there.
Mike, thanks so much for taking the time to talk to us today.
If people want to continue the conversation, where can they find you?
Yeah, I've loved this conversation.
If anyone wants to talk to me about any of these topics, I'm always interested to hear what people think.
You can reach out to me on LinkedIn, search for Michael Parker Dev at Chirintech.
And I'm happy to hear from you.
Cool.
Thank you so much.
Thank you.