In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Hugo Venturini about who is accountable when AI writes the code, how AI is reshaping code review and traditional engineering roles, and how leaders build a culture of transparency and psychological safety.
Key Takeaways
- AI is a powerful tool, but humans remain accountable for the decisions it makes possible and the code it produces.
- Pull requests have been growing for years; AI didn't create the review-scale problem, and teams should apply the same trust-based judgement about what needs reviewing that worked before AI.
- Merging the software engineer and tester roles at Microsoft in 2014 raised quality by making engineers accountable for the whole product — AI risks reversing that gain if people blame the tool instead of owning outcomes.
- AI collapses traditional role boundaries (PM, architect, tester), pushing engineers to ask better questions — a skill that defines seniority and that organisations need to deliberately teach.
- Cultures of transparency — honest no-blame Q&As, anonymous questions, naming solutions rather than people — let people dare to take accountability, and this can start at any level of the organisation, not just the top.
Subscribe on:
Transcript
Shane Hastie: 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.
Hugo Venturini: Thank you, Shane, for having me.
Shane Hastie: Now, we are sitting in opposite sides of the world. I'm in New Zealand and you are somewhere in Europe.
Hugo Venturini: Yes, right now I'm in Spain, in Valencia.
Shane Hastie: 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?
Hugo Venturini: 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 one step after the other. Senior then manager. I was a manager at Meta, Facebook at the time. I was accountable for the type checker and the compiler of the hack language. Eventually I decided to try to create my own company, grew it, then joined another organization, was the CTO of Qwant, the search engine, 90 people in the organization from network engineers to AI researchers. And right now, I work in a software company, startup company that deals with tooling for AI, to help AI do the right thing, so to speak.
Defining "The Right Thing" With AI [01:58]
Shane Hastie: The right thing. What do we mean when we say, "The right thing", today?
Hugo Venturini: Somebody's making a decision about what should be provided as a product to users. Somebody's 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.
Shane Hastie: Now, somebody made a decision, but all too often today we are seeing the addiction of, "Yeah, but the agent did this. The code generator did this".
Hugo Venturini: I think humans are in charge and humans should be accountable and are, most of the time, at least to 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 at least 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 to the colon, to the semi-colon, 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.
Growing Pull Request Sizes [03:44]
Shane Hastie: One of the things that we are 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, a senior engineer who's got a backlog of over 300 pull requests, each of which is hundreds of lines long waiting to be reviewed.
Hugo Venturini: First, the size of pull request is a problem which does not rise with AI. It was already existing before. And 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 do 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". And 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 get only one 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 got the number of diffs and that's another problem.
How do you review for 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 give you two other reasons for that. And this, I can merge it already. And so this minimize number of diffs 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?" And please, tell me.
Rising and Stalling Quality With AI [06:41]
Shane Hastie: 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?
Hugo Venturini: I got a story about rising quality in an unexpected way, at least for some. I worked with 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 going 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 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 month. 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.
Collapsing Roles: PM, Architect, Tester [08:43]
Shane Hastie: So with collapsing roles, so you mentioned the engineer, the tester. What about the architect? What about the product manager? What about the security tester, the compliance elements?
Hugo Venturini: 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. The tester, the PM, the architect, and sometimes the users, the dogfooter and the HR and the finance, you're everybody. And the bigger the org grows and the more people you need in every single verticals, and eventually you have a PM for the front end, a technical PM for the backend. You're going to have a handful of software engineer 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 try to shrink it back again to when the industry was growing, to when the company was growing and we face sometimes some misunderstanding of people who have never been a PM, even a bad PM, but when you have to be a PM because you're a startup company, 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 you really want it to succeed.
Asking the Right Questions: Shifting Further Left [10:38]
Shane Hastie: It worries me that the software engineer who's 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?
Hugo Venturini: 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 the human, to managers, to organizations. 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 a broader space. What if I don't dare? 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?
Building a Culture of Transparency and Accountability [12:07]
Shane Hastie: So this is culture. This is the Engineering Culture Podcast. How do I nurture that culture?
Hugo Venturini: I'm not sure that the recipe... Sorry, I know there's no recipe. However, I got some good examples 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, everything was wrong. And I was asked to fix the culture, so to speak. And very quickly I decided to 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 you don't name people. You only name solutions and product. 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 managers, "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 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 arrived, people would lie to me and I would see it. And I was like, "Okay, you can totally confront the person, 'You're lying to me, that's bad.'" 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?" 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 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.
Leading Culture Change at Any Level [15:29]
Shane Hastie: Beautiful story and a great example of shifting culture. What if I'm not high enough up in the organization to do this?
Hugo Venturini: 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, a startup. We were already at 1200 in the company, so it was scale up, 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 also 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 which is a 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 and 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. If you 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 wishful thinking maybe, but if you don't try, you know it won't work, right?
Shane Hastie: Yeah. If you don't even try, you're guaranteed to fail.
Hugo Venturini: 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'd say, "Help me help you". So if you provide the right information to your manager, your manager would be able to help you. If you hide too much, if you're too secret on some part of who you are or 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 are in a down moment or hub moment or you are 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 hard thing because you don't know when it ends.
Shane Hastie: We are dealing with people.
Hugo Venturini: I like to help people. I like to see people grow. Most of the time, staff relationship in helping people, and that's all why I moved to the management and 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.
Shane Hastie: So the manager as amplifier.
And that's also why when you got toxic management, it's devastating for an org. The impact is easier when you got people reporting to you, but also as easier, it's easier to destroy everything or to grow better.
Influence Without a Manager Title [19:28]
Shane Hastie: 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?
Hugo Venturini: We've talked about management and the impact that come with the role. Is it possible to have the same kind of impact 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.
Hugo Venturini: 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, maybe you're too humble to understand that you are actually at this level of influence, and it is more probable that it's 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 became a manager, and then was hired as director, a 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 demand. In the end, it's just about this, I believe.
Shane Hastie: That pendulum swing across roles. You got a lot of really interesting and meaty stuff there. If people want to continue the conversation, where can they find you?
Hugo Venturini: They can find me on X/XTwitter as monsieurv. It’s French. My alias is monsieurv. And on LinkedIn, by my name, Hugo Venturini. 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 decided to be in this space because it is fascinating because the meeting of software and humans is an ongoing conversation that's going to be for life.
Shane Hastie: Hugo, thanks so much for taking the time.
Hugo Venturini: Thank you, Shane, for having me in your podcast. Very, very interesting conversation.
Mentioned:
- Hugo Venturini on LinkedIn
- X/Twitter as monsieurv
