# AI Accountability and Engineering Culture Shifts

**Podcast:** Engineering Culture by InfoQ
**Published:** 2026-11-13

## Transcript

How much authority should an AI agent have?
At QCon AI New York, learn how senior practitioners set permissions and evaluate agents in production.
Use their experience to decide where your own agents need boundaries and checks before release.
Join us December 15 and 16, 2026 at the Western Jersey City, Newport.
Explore the program at newyork.qcon.ai.
Good day, folks.
This is Shane Hastie for the InfoQ Engineering Culture Podcast.
Today, I'm sitting down with Hugo Venturini.
Hugo, welcome.
Thank you for taking the time to talk to us.
Thank you, Shane, for having me.
Now, we're sitting in opposite sides of the world.
I'm in New Zealand and you're somewhere in Europe.
Yes, right now I'm in Spain, in Valencia.
Nice.
You've got a beautiful, warm summer.
I'm sitting in a pretty cold winter, but we'll get past that.
My normal starting point with these conversations is, who's Hugo?
So I'm a software engineer.
I defended my PhD on the debugging of optimized code in 2008.
And after that, I joined the industry as a software engineer and I climbed the ladder, you know, one step after the other.
Senior, then eventually manager.
I was a manager at Meta, Facebook at the time.
I was accountable for the type checker and the compiler.
The right thing.
What do we mean when we say the right thing today?
Somebody is making a decision about what should be provided as a product to users.
Somebody is about to write the code.
Somebody will test it.
Somebody will make the decision to release this to prod and somebody will use it.
It can be all different people or it can be the same person at every step.
Doing the right thing to me is solving the problem to a user.
And then at every step, you got doing the right thing of that step.
And for a code generation, it is generating the proper code to some extent.
Now, somebody made a decision, but all too often today, we're seeing the abdication of that.
But the agent did this.
The code generator did this.
I think humans are in charge and humans should be accountable and are most of the time, at least.
It's what I can see.
And that's the right thing.
I'm not minimizing what it does, but AI is just another tool.
It's a very powerful tool.
And don't get me wrong, I still got these wow moments several times, not a day, but just a week.
And yet, if it fails, the one conducting this great tool is accountable, is in charge, and should answer what goes wrong.
Doing the proper thing is doing what the human asks it to do.
And when you want to generate code, code has to be, you know, to the column, to the semicolon, to the character.
And if it does not, many times the proper tooling can actually tell the AI how to loop and give the right feedback.
So when it comes back to the human, a great deal of what could be automated has been automated.
One of the things that we're seeing and various studies are pointing to this, the size of pull requests are getting bigger and bigger.
I've heard stories of the...
2000 lines, the senior engineer who's got a backlog of over 300 pull requests, each of which is hundreds of lines long waiting to be reviewed.
First, the size of pull requests is a problem which does not rise with AI.
It was already existing before.
The first thing is asking yourself, should I review everything?
Sometimes you got all that boilerplate.
We could already, before AI, automate the verification.
Let me tell you this.
If it compiles, that's already a good thing.
If it passes all the tests you've created, if it behaves the way you wanted it, do you really need to review the code?
That was already not the case before.
Second thing is already before as well, and I've lived in an organization that was working like this.
You don't have to go for a signature of a diff for every single diff you do.
Eventually, people are good enough, senior enough, or do trust each other that says, I can totally merge this diff without having anybody reviewed it.
And if it goes wrong, I'm accountable for fixing it.
That'd be okay, but I'm totally sure.
And people trust me to merge it already.
Sometimes you've got the heart of the product which you want to create, and you need to be able to review for two reasons.
First, for quality.
Second, for sharing the knowledge, of course.
And sometimes it's really just boilerplate that you can totally merge it.
With AI, big reviews always, and you can still, I believe, not go for who's got the biggest review, but who's handy enough to get your AI to create the proper diff and the proper stack of diff.
So you can only want to review what the heart of the product is.
I think with AI, because of the wow effect, some people are playing this game of the wow effect with, look, I have rewritten this entire big product in only one diff, which is just for the show.
Let's face it.
Nobody does this.
And before, at the group of engineers, if anybody were doing this, we were all telling him or her, please help us review your code.
That's one thing.
And after that, you get the number of diffs.
And that's not a problem.
How do you review the number of diffs?
I don't have any good answer and I'm really eager to have anybody telling me how do you do this?
Right now what we've decided in my team is we don't review everything.
We were not reviewing everything before and we trust people with our own good judgments that this needs not being reviewed and we only ask proactively this I want you to review it.
I'll give you two reasons for that and this I can merge it already and so this minimizes the number of tips to be reviewed by other people.
But that's an open conversation I'm sure we all want to have.
Like, how do others do about this?
Please tell me.
We'll leave that as an open question for the audience to respond.
So what are the implications of this in terms of the broader elements of quality in our product?
And we think of the architectural frameworks and so forth.
How do we make sure that we are building the right stuff?
I got a story about rising quality in an unexpected way, at least for some.
I worked at Microsoft in 2014 when they decided to merge the software engineer branch with the testers branch.
At the time, testers were doing two things.
Some were not coding, some were coding, and the software engineers were writing software and handing it to the testers for testing and was coming back and forth.
By removing the official testing step by somebody else, it actually raised the quality of the software.
And the reason I believe is because it made software engineers accountable for the final product, not one step of the chain.
Today, I got the feeling that we are...
removing the software and everybody's becoming a tester via your AI because somebody, you command some software which is written and then people become software.
But we are all again merging those two verticals as one.
And the difference is we don't see an increase of quality yet.
And I believe it's because people are still blaming the AI and don't feel accountable for what the tooling is doing.
And that's one thing we totally need to work.
on as leaders, as managers, as colleagues, as users.
I've seen some software I've been using, definitely lacking quality over the last months.
And I read in the press that those people are massively using AI.
And I'm like, maybe I see something here.
And I'd like to know what kind of feedback I can give to get them back on quality.
So we're collapsing roles.
Yeah.
So you mentioned the engineer, the tester.
What about the architect?
What about the product manager?
What about the security tester, the compliance elements?
The more people you have in an org, the more narrowed focus you have for people.
When you're in a startup company, you are everybody.
You know, the tester, the PM, the architect, and sometimes the user is a dog footer and the HR and the finance.
You're everybody, right?
And the bigger the org grows and the more...
people you need in every single vertical.
And eventually you have a PM for the front end, a technical PM for the back end.
You're going to have a handful of software engineers for the front, from the back, for the queues.
And the more it grows, and then it becomes like an army of people working on it.
And with AI, we tried to shrink it back again to when the industry was growing, to when the company was growing.
And we faced sometimes a misunderstanding of people who have never...
Being a PM, even like a bad PM, but when you have to be a PM because you're a subcompany, you eventually do the job.
And when the AI comes, it really helps you.
When you've never been, but you can be and you're asked to be, that's something you have to learn.
I believe that we need some more trainings or help for all those people because AI really, really empowers you.
But it empowers you to do things that you're not sure how to do.
And that's where AI barely helps you.
It always answers the question you're asking, but if you're asking the wrong questions and being a senior is asking the right questions, the good question that helps grow, that helps define, that's being a senior.
Senior is with experience and knowledge.
You actually ask the question that helps move forward to a solution.
And I believe we need to help people being better at asking the right questions to the AI if we really want to succeed.
It worries me that the software engineer...
being used to being asked to build this and given some sort of a spec, whether it's a set of user stories, a screen mock-up, or just a quick conversation, we're now asking that person to think of the right questions to ask.
What is the implication of that?
We've spoken about shift left and shift right for the last couple of decades.
We're shifting further left, but have we?
And how do we empower and give the people who are being now asked to do the questioning, to do that left shift, to know how to do that work?
People dare to do things if they know they will be accountable but not blamed for what happens.
And that's an organization, that's a human part of your organization.
If you empower people but they don't dare, you're just not doing anything.
And that comes back to human, to managers, to organizations.
Like, how do you empower your people and give them not only the tooling, but also the state of mind of stepping out of your comfort zone?
I'm a software engineer.
And as I said, I have to also explore broader space.
What if I don't there?
What if I can't?
Because even though I got all the tooling I have, I fear it.
I fear the organization I work with.
And that's something which is, this is a hard part.
I mean, human is the hard part of the software industry, right?
So this is culture.
This is the Engineering Culture Podcast.
How do I nurture that culture?
I'm not sure that the recipe, I know there's no recipe.
However, I got to know an example where I believe it was the right move.
The first thing is transparency and honesty.
If you are honest with your team, most of the time people start being honest.
I eventually became the CTO of a company which had a broken culture.
People would lie.
hide, steal, you know, everything was wrong.
And I was asked to fix the culture, so to speak.
And very quickly, I decided to, you know, lead by example.
So I started to have a Q&A every week.
You can ask me any question.
If I can answer, I answer.
If I can't, you have to keep me accountable for answering the next time.
And you ask me the question again.
And if I don't answer, ask it again until you have the answer.
No judgment about it.
Of course, first Q&A, I only got easy questions.
People wouldn't dare to challenge the head of the org.
And I started to come with answers such as, I don't know.
I made a mistake.
This is a good thing.
Congratulations.
But like, you don't name people.
You only name solutions and products.
You are accountable for what you're doing.
And you take...
the load whenever and coming back with the last time you asked me these questions and I found the answer and it is unpleasant, but you need to hear it.
And we are all in this together and gathering the thing.
Eventually, after a few sessions, people started to ask me difficult questions.
And eventually we started to go with even more difficult questions by allowing for an anonymous board.
So I asked my manager, what about you ask them if they have questions and if they have it on there, write it down and you ask it.
Even better, you give it to another manager, so I cannot even guess which team it comes from.
But I want the questions, I don't care who ask it.
So please dare.
And they've started to organize this, so I could never guess from which part of the organization the question was coming, but I got the questions.
And eventually, people started to vote for questions.
And it grew like this, and it becomes very interesting.
Eventually, people would stack questions before the Q&A.
What I noticed in the org is, when I write, people will lie to me, and I would see it.
And I was like, okay, you can totally, you know, confront the person you like to me.
That's value.
I said, no, no, no.
It's a cultural thing.
How do I take it as a whole and shift almost the entire culture of lying, of hiding things by being transparent and explaining things and showing them that I can be accountable and move forward and fix things?
You know, being exemplary is when you can totally break things as long as you've fixed them before and you learn a lesson and you don't repeat your own mistakes.
Being wrong and making mistakes is totally acceptable.
What is not acceptable is repeating your own mistakes because you have not learned.
So you have not grown.
And this cultural thing of allowing people totally shift the essence of this organization, which went much better by the time.
But you also have to be patient.
When you write software, you see it right away under your hands, maybe a few hours later.
With humans, you need to learn patience.
But eventually you see results.
Beautiful story and a great example of shifting culture.
What if I'm not...
high enough up in the organization to do this?
Okay.
First, there's nothing as just a team lead.
You are a team lead.
That's not just a team lead.
And at every level, you got something to contribute to and to help grow.
I've seen it work in smaller teams.
Eventually, I was in a startup company.
We were already at 1,200 in the company.
So in Scalop, you say.
And I found two teams were already working like this at their level.
They were already working on this transparency and we are a team, but we also need to be accountable.
And I've seen it work.
It was less efficient in terms of, I would say, impact because it was at the size of the one team and not the entire org, but already very interesting.
And the good thing is managers also gather together.
I mean, as a manager, you have a team, but you are part of another team.
We see the team of managers.
And that's the difficulty of being a manager that most people don't get first is you're not only manager of a team, you are now a member of two teams with sometimes different goals or opposite goals.
As a manager, you need to think outside of your own team to help the org at the size of every manager.
As a manager of a team, you need to help the team grow.
And sometimes you have to make decisions that won't please either the rest of the managers.
or sometimes your team.
And it cannot only be one way.
You have to think outside of your own team to make it grow, make it better.
And that's maybe the most difficult part of being a manager.
And at every level, you always have a way to influence right outside.
You just start to do the right thing and you actually see benefits.
You can talk about it to other managers and eventually they will follow you and do the same thing.
And eventually it will grow.
Okay, this is, you know, wishful thinking maybe.
But if you don't try, you know it won't work, right?
Yeah.
If you don't even try, you're guaranteed to fail.
The way I see it is as a manager, I'm here to help people.
So I would always not maybe always phrase it this way, but I say, help me help you.
So if you provide the right information to your manager, your manager will be able to help you.
If you hide too much, if you're too secret on some part of who you are, what you do, it becomes a little harder.
You're not only a machine coding or being an engineer, you're also a human.
And sometimes you got ups and downs.
And if you provide some information to help your manager, your manager can also totally help you.
And that works at every level.
As a CTO, I was at the COMEX and talking with the CEO, the CFO.
And if you give them some hints that they can help you because you're in a down moment or a hop moment or you're available to help them.
You become a member of the team.
And it's not a day by day.
It's an average.
It's going to be 50-50 in the end.
But it doesn't have to be you always being 50% helped and being helpful every day by the hour, by the week.
It's overall.
But it's kind of a hard thing because you don't know when it ends.
We're dealing with people.
I like to help people.
I like to see people grow.
Most of the time, stop relationship in helping people.
And that's all why I moved to the management.
leadership roles because I believe that most of people are better than I am at what they do in their job.
So if I can help them be even better, it cascades to the next person and the overall organization grows.
So the manager is amplifier.
And that's also why when you've got toxic management, it's devastating for an org.
The impact is easier when you've got people reporting to you.
But also, as easier, it's easier to destroy everything or to grow better.
We've handed a lot and given some good advice around that transparency and bringing that into culture and the culture of accountability without blame.
What is the really important question that I haven't asked you?
We've talked about management and the impact that comes with the role.
Is it possible to have the same kind of feedback without being a manager?
I've seen individuals being able to do this.
And I've been always very much impressed by their level of influence.
And I'm not sure I've deciphered how they were working.
What I've seen is those people were technically very strong, very humble.
And the common characteristic of those people were like, they were always, always listening more than they were speaking.
So yes, it is possible.
But I'm also leaning towards the conclusion that it's not everybody is able to do it.
There's something natural in those people.
And when you ask them, they're like, I don't know, I got it by chance.
For some reason, people are listening to me.
I'm like, oh, come on, dude.
You know that's wrong.
You work on your skills, but also you've met the right people.
Everybody's been mentored.
Nobody came naturally to this kind of position.
That's the one thing is you can totally grow.
It is possible.
And it can be a North Star to have this kind of influence.
And if you don't reach this kind of influence, it's maybe you're too humble to understand that you are actually at this level of influence.
And it is more probable that it is your humility that forgives you to see it than the fact that you are not at this level of influence.
But yes, it is possible.
It is a very tough career.
Some of the best leaders I've met as ICs, many, many of them tried being manager for a while and came back.
And the easiest and best seniors, staff, principal engineers I've managed knew the role of managers and knew how to help me as a manager.
So I would say, give it a go.
It doesn't have to last for your life.
I mean, you can totally give it a try for a moment.
I was an IC at Microsoft, became a manager.
Was hired as an IC at Facebook, became a manager, eventually created my company, was an IC, then again a manager, and then was hired as director, CTO.
I've been an IC for a bit more than a year.
Going back and forth gives you all the understanding of the scope of what is it to create the product that answers a user's demands.
In the end, it's just about this, I believe.
That pendulum swing across roles.
You've got a lot of really interesting and meaty stuff there.
If people want to continue the conversation, where can they find you?
They can find me on x slash x Twitter as Monsieur V.
My alias is Monsieur V.
And on LinkedIn by my name, Hugo Venturi.
Please, please come and discuss it all.
You agree, you disagree, you have another story, you have questions, you have things to raise questions from me because I'm very curious.
Please keep this conversation going.
I think it's a fascinating space and we've decided to be in this space because it's fascinating because the meeting of software and humans is an ongoing conversation that's going to be for life.
Hugo, thanks so much for taking the time.
Thank you, Shane, for having me in your podcast.
Very, very interesting conversation.