# AI Code Review Governance and the Future of Developer Roles

**Podcast:** Tech Lead Journal
**Published:** 2026-05-04

## Transcript

One of the cloud giants said that they associated a big portion of their downtime due to code written by AI.
Today's guest is Idemar Friedman, founder of Codo, the AI code review and governance platform.
With millions of enterprise PRs processed monthly, he's leading the shift from reviewing lines of code to governing the agents that write them.
A lot of people who are using AI can generate massive ton of lines of code.
What do you think about these challenges?
If you want to properly harness AI, you need to skip on reviewing line by line.
Doesn't mean we do not review.
Doesn't mean that humans do not take part.
Instead of reviewing lines of code, you're actually reviewing rules, skills.
quality workflows, integrity workflows, agent traces, etc.
We're going to see every PR growing in size because agents are going to complete more end-to-end tasks.
Moreover, now that when I'm used to wake up in the morning and see five PRs, I wake up in the morning and see 57, if not 120.
PRs.
So I need a new UI.
The future looks like a huge dashboard with hundreds if not thousands of workflows that were run and verified and surfacing those lines that require human attention.
The developers are feeling anxiety.
Are we going to be replaced?
If I don't write the code anymore, just write the plan.
How many developers really are we needing?
I heard like Entropic and OpenAI saying three years ago that by the end of next year, no need for developers.
Even Jensen from NVIDIA said in two years, AWS CEO said in two years that these two years are about to end.
And I don't think that's the developers disappeared.
Eventually it will happen.
So what we need to do as a developer is evolve really quickly with the profession.
Hey, quick pause.
My goal with Techly Journal is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe to follow the channel.
It's the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here and let's get back to it.
Hello, everyone.
Welcome back to another new episode of the Tech Lead Journal podcast.
Today I have with me Itamar Friedman.
He's the founder of this code review tools, new code review tools called Codo.ai.
I don't know whether I pronounce it correctly, but maybe later on you can correct me.
So today we are going to talk a lot about code reviews.
What does it mean to do code review in this current AI era?
And what are new best practices that we can adopt?
after the introduction of AI into our software development lifecycle.
So Itama, thank you so much for your time.
Looking forward for this conversation.
Pleasure, Henry.
Really excited to be here.
And yeah, we can talk about AI code review now and soon and the future because it's coming really fast.
So we can talk about all of them all at once.
Yeah.
So one thing I realized as well, like keeping up with the pace of the change, you know, with the AI.
AI models, AI tools, software development tools.
Those things are really, really, you know, I am struggling myself to actually keep up with that.
Maybe let's start with, you know, after all these introductions of, you know, AI-assisted software development tools and all that, what kind of problems do you start seeing in terms of code review?
Yeah.
So generally about like dealing with all the noise and a lot of tools that are coming and papers, I think...
each one of us needs to hold two buckets one this is how i see the future and believe in it and at the same time being having like really good channels that are low noise uh so i just recommend like spending time on that like a little even if a little bit like how do i see the future where i want to spend my time and how do i get like low noise like for example podcasts like yours i think it's one of the best um so about code review i think It's important to agree on two things.
One is that code review is essential, but it will evolve.
Okay.
It's like, if we look on code generation, code writing is essential, but it will evolve.
I remember the days when I said in the days of tap, tap, tap, remember like 2023, everybody were excited about tap, tap, tap.
I said, it's going to be irrelevant.
Nobody's going to do that.
And people thought I'm crazy, hallucinating, you know.
But it happened, right?
But is code writing still important?
Yes.
But the way we do it actually moved from generation one to generation three and a half or like really quickly writing lines of code, writing full classes with Q&A style that gen two and gen three are agents.
And now we are team agent teams, right?
So 3.5.
I have also four or five.
You can ask me later.
And so I think the same thing going with code, like code review.
The beginning, let's say Gen 1 of code review is like giving you recommendation on code snippets.
It's the equivalent of tab, tab, tab, right?
Then Generation 2 is managing to provide like more complete code review, perhaps, for example, on a full pull request as a whole, right?
And Generation 3...
is managing already to do that across multi-repo, across multiple PRs.
And 3.5 is where we are right now with code review.
And it moved much faster, by the way, than code generation in order to catch up.
We're actually in a multi-agent code review system where you have multiple agents.
Each one of them is in charge of different aspects of what the jobs that we're trying to do when you're doing code review.
And then trying to basically surface what's only requires attention, what's only what's important and critical for the human developer to look at.
For example, one agent might be focused on verifying that your UX UI is as it is in the ground truth in Figma, that your code is according to your intent, another agent according to your intent in JIRA, another agent verifying that your architecture is according to your architecture MD or your existing architecture.
Another one requirement in Notion or et cetera.
Another one that you're not going to ruin your database because you're going to be fired, not your AI, if you do something wrong there, right, et cetera.
So that's like, and if you think about the user interface, then it's evolving from, you know, inline comment to full PR review to a new review paradigm where Actually, you need to see a story and that surfaces what's important to look at.
And that's where we are right now.
We can talk about the future.
Yeah, well, hearing what you're saying, it seems like the evolution happening quite fast, right?
I think I haven't even experienced some of the later part, you know, the 3.5 that you mentioned.
But nevertheless, I think we can see, I mean, for those who have tried using some of these AI tools, AI code review tools, you would have seen.
some of these implemented in some shape or form, right?
Depending on the tools.
And I think it can be quite exciting.
This episode is sponsored by MailTrap, a modern email delivery for developers.
It offers straightforward integration into your code using their native SDKs, along with the security compliant API and SMTP support.
Plus, you get 4,000 emails a month completely on their free tier.
And the best part...
They have 24-7 support where you actually talk to real people, not an AI chatbot.
Try it out today at mailtrap.io.
And now let's get back to our episode.
But before we go dive deeper into the code review aspects, right?
But one challenges that some people would still think when they use AI is the hallucination problem.
And, you know, speaking about code review.
and code generation, right?
They will think that AI would not be able to produce great code as great as a human can do.
So maybe from your experience, what do you see so far?
Are the models already capable of producing good quality code without necessarily irrelevant bugs and things like that?
Yeah.
So I think when you're thinking about AI assistance for soft development, they have layers.
The foundation is built on top of a large language model in LLM that was trained and specialized for coding, and it's getting better and better.
If you just use it plainly, you will get a lot of hallucination.
It's kind of similar to bringing a developer and asking it, a new developer, sorry, that you hired into your company and asking it after one minute finishing reviewing a piece of code.
to now spit in five minutes a new function or a new feature, right?
It will hallucinate, or he or she, in this case.
But there's more to that in AI Assistant for software development.
There is tools and products and even platforms, and they help us.
For example, shameless plug Kodo is one of them.
They help us to move from vibe coding to...
viable coding or grounded coding?
I'll explain.
Vibe coding is all about the flow.
You know, as a developer for the first time, the goal is to flow with my work.
Before that, we did, for example, I don't know, test-driven development, and the goal was the correctness.
BDD, the goal is behavioral correctness.
the like s spec driven development like each one of them had a different goal and finally with it's so fun with vibe driven development it's like the flow isn't is the goal but that's not sustainable that's that probably will not bring to high quality code so but we don't want to lose the flow it's so fun and efficient to some extent we want to make it also really efficient for long term for example with quality so In order to do that, to turn it from vibe-driven development to viable or grounded, you actually need to add proper planning that is already reviewed at the stage of the planning, coding in a flow manner, like vibe coding to some extent, but with background agents and processes that slapping the coding agent always towards the right.
direction because it could go to so many directions that are not in high quality.
And finally, high quality review that that is like basically opinionated is not an LLM that is with its internal knowledge that learned on the entire open source.
Rather, it's a code review that is already was trained and tuned.
into the company specific standards and biases and so it's like a really governance governance layer that's how you turn vibe coding into viable coding proper planning already reviewing it vibe coding yes but grounded with quality workflows that make sure that almost every class decision etc is according to what is expected and then having even a deeper analysis that is even you know more subjective at the point that you review and then close the loop if there is need needs to be refined and fixed right you just open up uh you know the term vibe coding you know so many people are raving about it right so you know the non-tech people can also now code and we have seen in the news you know they are popular you know inventions that some of these people create, but also there are some popular disasters that, you know, some people also create, right?
So I think the vibe coding definitely is associated with like, you know, some kind of level of quality of the code produced.
Before we go into the vibe coding itself, you mentioned about, you know, the governance, the rules and things like that that we have to put in place.
You mentioned about like BDD tests and all that.
Usually when we do software development in the past, we actually use...
You know, maybe like static analysis check, you know, like our linters, maybe the test as well.
Is this something that is still relevant or is this something that has to evolve as well?
Oh, yes, no.
Maybe so.
In a sense, exactly what you say need to evolve.
It's relevant because we still want to check all those more deterministic checks that could really help improve quality.
The problem with, or, you know, it's not sufficient.
The problem with them, they're very, you know, heuristic about specific lines or function.
They don't have, these tools don't have the big picture of what's the intent, what's the requirements, what's the architecture design.
And if we don't like, these tools have to be encapsulated, needs to be part of a bigger platform.
Okay.
At the day we started Kodo, that's the opportunity that we saw.
that we have more than 10, maybe even 100 tools.
Each one is in charge of something small related to quality in our code, quality in the biggest sense of it, like including like security, compliance, et cetera.
And there's an opportunity to build one platform, let it be Coda or someone else for just, you know, not to advocate only for ourself, that you get one-stop solution for a governance layer.
Because you do need to have all these like linters and statical analysis, and that's part of what needs to be checked.
But without the more semantic understanding, then you're not covering all the jobs to be done that are being done during the code review.
And then code review will be the bottlenecks.
Quality will be a bottleneck.
And we cannot really...
harness AI for software development.
A good example is verifying versus intent in JIRA.
Another good example is, for example, architectural design.
Another good example are specific rules and policies that were learned the hard way, you know, that are very semantic, that are written sometimes in documents of RCA, root code analysis.
And some of them in developers' mind, and they're very semantic.
This is how we do things because that's how we maintain performance or, you know, managing to avoid like one's point of failure that is so hard for LLM to real or static analysis and analyze without that tribal knowledge that happened in the past or people experience.
Yeah, I think you brought up something kind of novel, I would say.
Some people in the past, they never codify all these RCA, architectural that are being discussed.
So now with the...
invention of LLM, actually, now we have the capability of analyzing languages, the written text or the verbal and all that, and actually check that against maybe our code base, maybe our architecture and all that.
So I think definitely it opens up a lot of use cases.
Speaking back to the Vibe coding, I think many Vibe coding are kind of like solo developers.
Maybe they don't care so much about the quality aspect.
They just want to do one shot and...
create the application but maybe let's put those kind of people aside we just want to talk more about the maybe enterprise kind of use case one challenges with the ai now is that there are a lot of people who are using ai and can generate massive ton of you know lines of code so to speak right this can be associated with the number of pull requests that gets raised as well so if we are doing the traditional way of doing code review There will be a lot of massive bottleneck that I assume will happen simply because humans cannot review all the lines of code that are produced by AI.
What do you think about these challenges?
Should we be having some new invention or new workflow of tackling this problem?
Yes and yes.
So basically what we're seeing, and we're processing millions of PRs a month at this point, you know, with...
Fortune 500 companies like Walmart, Intuit, Ford, Texas Instrument, Red Hat, et cetera.
And what we're seeing is that the size of PRs is growing and the amount of PRs is growing.
So it's like really huge mental load on developers to deal with all that lines of code.
And basically, if you want to properly harness AI, you kind of need to skip on reviewing line by line.
But that's...
That's really challenging in a sense that if you care about your customers, you care about your users, and you don't want to have catastrophes.
I just read that yesterday one of the cloud giants said that they associated a big portion of their downtime due to code written by AI, etc.
So it's kind of challenging mentally to...
Give up on reading line by line, but you have to.
And that's why we do need to change the paradigm on how we review code.
It doesn't mean we do not review.
It doesn't mean that humans do not take part.
I actually don't think that that's going away.
It's just like how it's going to change.
And the big change is instead of reviewing lines of code, you're actually reviewing rules.
skills, quality workflows, integrity workflows, agent traces, et cetera.
You build them.
You use tools to create them, to create verification loops, et cetera.
The future looks like a huge dashboard that's such that for a bunch of PRs that are stacked together, you have a dashboard.
with hundreds if not thousands of workflows that were run and verified accumulation of rules and and and relevant skills and quality workflows that verifies that that those could be thousands of tens of thousands lines of code and surfacing then those lines that require human attention i think that's that's where we're going to um that won't happen in a day.
We need to have a very mature product and technology that takes that tribal knowledge that we have in our heads and in the code base and codify them into rules and skills and workflow.
And these needs to be continuously learned.
So the UX UI is going to be totally different than the UX UI of reviewing line of code.
It's like a dashboard, just an example to imagine.
where rules are surfaced to tech leads because there's a new learning by the AI that this rule would help the review.
And the developer, the tech lead will say, I agree with that rule or not.
And then the day after the developer sees how this rule actually holds the water for a new code for your existing code base and decide if that's good enough or want to update that, et cetera.
So it's similar.
to some extent, how we progress with cloud.
I'm old enough remembering the days where we need to build racks or whatever and monitor them.
Today, you monitor completely different things and you don't build anything out of hardware.
So we won't look on the cables.
We don't look on the cables anymore.
We look on the cloud.
We won't look on line by line or not each line.
I'm not saying not at all.
So I think that's a paradigm shift.
Turning into like herding agents, rules, skills, verification loops at scale with a very designated independent governance and review layer.
So yeah, maybe for those people who are still kind of like stuck in their old habits of doing code review and traditional software development, right?
I think usually what they do is like they raise pull requests or merge requests and then they have like, I don't know, like pre...
push check or something like that that runs to verify their code is working okay.
Some are using CICD as well to have kind of like build steps to verify depending on the checks that they want and kind of like give a thumbs up or thumbs down whether their code changes are actually okay.
So maybe you mentioned a few things just now, like you mentioned about rules, skills, you know, quality, workflows, maybe intent workflows, those kind of stuff.
How do you actually implement that or how do you actually implement that in the new way of doing code review?
Yeah, amazing.
So I think it's a great framework.
At the beginning, we don't need to change much, right?
Like for example, in code generation, which started with autocomplete.
It's like, I'm about to complete, start to write a line and it's completing for me.
At this point, we're doing code generation, many of us, not everyone.
In some cases, by the way, it doesn't work right at all.
So we're doing it by prompting.
agents even without looking on the code supposedly right so that's like totally different paradigm so in code review imagine what you just said that the you know the holy sorry imagine what we just said that where the basic user interface is the github pull request or gitlab and merge request or bitbucket etc azure develops pull request page and this is where developers uh being surfaced with the diffs with the chunks of coded was changed and a chat interface where they discuss with each other uh whether on marking the code or outside it like on on things that they think need to be changed and the first step is we basically simply saying use an llm to go over those lines of changes And surface comments the same way that a human reviewer would do.
That's Gen 1.
Gen 2 is that it's not simply running those diff on an LLN.
It's much more, let's say, comprehensive and capable on reviewing complete functions and a complete PR.
But it will still push comments the same way as a human review.
The good thing about it is that you get that review in five minutes or 15 or 20, depending on the tool that you're going to use.
You don't need to wait sometimes a day or more.
Then the Gen 3 is that where the comments are very knowledgeable, they are designated to catch different aspects.
There is much more tool usage.
and context engineering and context and AI harnessing, et cetera, such that the level of those suggestions are getting to the level of a senior developer.
But the user interface is supposedly the same.
In order to get to those levels of a senior developer, that's where you do need to do some work.
For Gen 1 and 2, You use tools that just wisely exploits LLM on your context.
But in gen three, if you want those agents to get to the level of the seniors, you need somehow to dump the knowledge, right?
From the tribal knowledge that are within the heads of your senior developers and in the code base and extract them.
And then you can either do it by yourself or Sorry for a shameless plug.
You can use Kodo.
Kodo is the only tool out there that automatically learns the rules and skills for you.
And it first learns, then surfaces the rules and skills, enables tech leads to agree or disagree or edit, and then enforces those rules and track how much these rules are actually being caught and used and enforced, et cetera.
So you can do it by yourself.
Or that's the whole idea of a Gen 3, 3.5 code review tool, that it turns the comments, the same comments, into a level of a senior.
But that's where we are today, and it's not scalable enough.
Because the amount of code that some companies are already getting and some other companies are going to get in half a year, and PR is so many of them, that maybe...
This step that we are today, that Codo and other code review tools are leaving comments as humans is not enough.
And we need to completely change the UI.
Like we changed the UI recently with the coding that we moved out of the ID, out of even the CLI into a whole new app, a agentic development environment ID.
We would also move to agentic review environment.
That's where we're going to.
Okay, so that's how you should expect the evolution of your team also.
I wouldn't start with the end.
If you're new to it and you now want to start using and harnessing AI for code review, start with simple tool that gives you comments on your pull request, then the most advanced tools there are there, and then shift to, you know, agentic review outside of GitHub, GitLab, Bitbucket, etc.
Yeah.
Thanks for such a good explanation and the evolution as well.
I like the way you always explain in like Gen 1, Gen 2, Gen 3, and so on and so forth so that people can have like a gradual progression on how sophisticated the code review can become.
So I think a few things that I like, and you mentioned about the kind of like the UI of how we are doing code review now is still kind of like pull request based where you are surfaced, you know, change requests with the diff and maybe some comments and people are commenting with each other.
I think some people might have seen, you know, such, I don't know, coding assistant tools that can also review the PR and give comments as if like they are human as well.
I think this is quite popular these days, right?
And I think the other one is about agentic review, right?
Which is probably something that is coming up.
And I like the one that you mentioned that sometimes when we run this static code analysis, it can really take a long time because, I don't know, it has to build a syntax tree and things like that.
And it's just like heavyweight.
But somehow with the AI model, it seems to run much faster.
So I think this is also another aspect that probably will come.
Like the code review might not be such a heavyweight process anymore.
So speaking about the UI, do you think this current UI of pull requests and how we actually raise code review requests, will it still continue or will it move away?
Yeah.
So as we said, we're going to see every PR probably growing in size because agents are going to complete more end-to-end tasks.
Like you don't necessarily need to break.
a user story to five just as inventing a number dev stories maybe you can do end-to-end user story with five dev stories but in one pr because the breakdown was done at all at once and implemented all at once and then getting those like comments one after another might be very exhaustive and not you know healthy for mental mind for developers so we want might want to uh like make it a two things a little bit more like the story to focus on the business logic in the pr there will surface all the facts that this code should work according to and if there are issues let's go through them so it's much more focused on verifying that the requirement and the intent and the business logic is there, rather verifying the lines of code.
I believe that PRs very soon are going to much more clearly include all the requirements for them and including the traces of the coding agents, because that's part of how you verify, you know, the code is working as expected.
But moreover, now...
that when I'm used to wake up in the morning and see five PRs, I wake up in the morning and see 57, if not 120 PRs.
So I need a new UI because I don't know if you're familiar, many team members before they leave work, they send some agents to work.
And on the weekend, why do you waste time?
Do you send some agents to come Sunday or Monday morning?
That's the worst case scenario in a good way that you have like hundreds of PRs.
are waiting for you.
And if you're not there yet, don't worry.
You'll get there by the end of 2026, my prediction.
And now we need to start reviewing, have a UI that fits everything all together.
So for example, at Kodo, this is really coming soon, probably maybe even by the time we publish it, there's like a new user interface where Kodo like stack a few PRs in one review as one.
interface or actually stack prs according to mutual issues for example pr 7 17 27 and 47 had a issue with how our agents are doing logging and see those issues in one thread although there's totally different prs and then you can ask to fix all of them all at once okay so that's a whole new interface to how we're going to deal with this amount of features and code.
Why do we have so many lines of code and so many PRs?
Because we're trying to complete more feature quickly.
So we have to verify and surface much more clear the business interface.
That's one UI that needs to change.
For example, our PR is going to be full of videos and images and verification flows that you can click and get a proof.
You click here, you get a proof that the agent ran that flow for you and then go back to the PR if you like, et cetera.
And the second big change is that stacking and looking at things are much more holistic.
This is my prediction on UI change.
Oh, that sounds really cool, right?
So I think...
Definitely looking forward for a more such advanced case.
And especially like now with the LLM models, they understand multi-model, right?
Like you mentioned video, maybe audio as well.
We might start seeing new patterns, new ways of doing the code review.
And yeah, very excited.
Maybe now is a good time to actually talk about Kodo itself, the platform that you're building, the new way of doing code review.
Maybe to kind of give a high level, how does Kodo differ with other code review tool?
Kodo is the code review and governance layer for code changes and code base health in general.
Koto is both better and different.
Koto is better that the precision recall of Koto is the best.
And it's really not easy to do because some elements of code review are objective, but some of them are subjective.
And the second thing is that we're very unique in how we help.
enterprise understand their rules skills their code base health the quality of their code to begin with in order to be able to enforce code quality including its subjectiveness the first thing is that you need to be able to surface semi-automatically if not automatically what are the standards what are the best practices what are the rules what are the skills of organization most of them do not know And even if when they thought they knew, they were built for humans and not built for AI.
And you need a mix of them because that's what we want to create clarity.
So Kodo is a tool that you can install in your Git, GitHub, GitLab, Bitbucket, even Garrett, Azure DevOps, because we're very enterprise focused.
And that's where enterprises live.
And Kodo leaves comments that are the senior level.
Because it's really good in catching bugs, but also catching, finding and enforcing subjective standards and rules, etc.
Basically, that's the first interface of Kodo.
The second interface is the dashboard where tech leads, director of platform, director of engineering continuously get insights from Kodo, like new rules that needs to be applied because something bad happens or...
Kodo notices something before it becomes a mistake in production.
There's good and bad code that were pushed.
A tech lead left a comment to another mid-level developer and Kodo catch caught that and turned it into a rule.
Continuously learning what are the standards and the rules.
And that's a different dashboard with insights, including surfacing what is currently the quality of the pull request, et cetera.
That's where we're different.
to really, like, enable code review.
And then, of course, there's also skills that enable to connecting Kodo to Cloud Code, to connecting Kodo to Cursor, et cetera, connecting Kodo to JIRA to get already reviews in the planning, et cetera.
So a lot of, sorry, a few skills and interfaces, MCPs, CLI tools, et cetera, to do shift left and shift up.
Kodo is...
The first flagship interface and capability is being the gateway and the gatekeeper at the point of merge at GitHub, GitLab, Bitbucket, et cetera.
And then after we establish what code quality means for reorganization, then we also code enables shift left and shift up with pushing those quality guardrails and rules, et cetera, towards writing code and planning.
Well, so when you mentioned shift left, I assume this can also run on the developer machine themselves or maybe, I don't know, like using the cloud code this day, right?
When you ask it to make the changes, can you actually do it that way?
Or also when you mentioned shift up, what does it mean by shift up?
Yeah, thank you for asking that.
I was hoping.
So shift left means exactly what you mentioned.
reviews from kodo in order to do shift left we connect really well to cloud code an example mostly and also of course cursor and copilot etc they're great and i believe they will have new one by the way by the end of 2026 and and kodo basically runs supposedly on the machine it doesn't mean that kodo doesn't call the back end doesn't call like capabilities like cloud code code calls apis from for llms in the background right Also, Kodo will call Kodo backend, et cetera, but it runs on your work tree or in the local machine if you like, for example.
Shift up is where I think the future is very exciting and where we're heading towards.
Imagine a world where we want to enable a technical product manager to write down a specification, launch a coding agent, get the code ready.
push the production and seeing the code, you know, in the hands of the users.
In order to do that, two things are important, that the plan already in the planning phase is well reviewed.
That's a shift up.
And the second thing is that the code is being rigorously reviewed with all the agents, designated agents that needs to run, with a dashboard that's showing all the proof of work.
And everything that was need to be checked that was designed by or guarded or built by the developers so that this system is up and running and we trust it.
The shift up means that the technical product manager is getting AI assistant to write proper plans with all the required details such that it's almost easy.
for coding agent to just execute it.
If you think about it, it's like basically squeezing the V-shaped model of software development.
If you go in Wikipedia and look for V-shaped model for software development, what you will see is the following.
X-axis is time.
Y-axis is executability.
When the V, you start with not executable, planning.
Then you go down in the V and you actually write code, which is executable.
And it takes more time until you complete that.
Then you go back up on the V where you write tests, you do code review.
These are either not really executable in the application or not executable at all.
And what we're saying is squeezing the V.
Basically, if you properly review the plan, then writing the code is almost like instantly happens right after and you can run.
So that's what we call a shift up.
Wow, this sounds like the next level of vibe coding, right?
With proper guardrails and governance and all that, right?
So not just engineers who can write the code, but maybe like what you said, technical PM or non-technical people.
As long as you have these guardrails, anyone can maybe push something to production.
But yeah, this also...
requires the planning, you know, maybe coming back to this trend spec-driven development.
I think some people are kind of like raving about it.
You know, you plan first without actually doing one shot, generate the code, right?
So the plan actually helps you to break down the tasks as well and figure out aspects that are important before then you let the AI agents to execute them.
So I think this is definitely one way of doing software development.
Another way of doing software development that I can see rising as well, like people now open up I don't know, five, 10 terminals and make changes all at the same time in parallel and let them all even submit as a pull request.
The other one is actually this trend of open claw where they build small, small agents that run something dynamically.
So how do you catch these trends?
How do you ensure that the quality actually is also up to mark?
Yeah, a small remark.
You kind of compare it between shift up and spec-driven development.
And I do agree to some extent.
I think the small differentiation that I'm making with the shift up, that spec-driven development, to some extent, it's still owned by the developers or written by the developers.
And the shift up is like, if you like high level or spec-driven development, it's like, if you like, the AI is doing the spec and verifying that it's correct.
And the technical is like basically prompting to have a spec.
So it's like spec-driven development, but a bit upper, like managed by technical people that are not necessarily developers.
I'm not saying that a non-technical CEO should do that, not in 2026, maybe in 2029, but definitely technical people.
It basically means that companies that have like right now 20,000 developers.
and 20,000 technical people that are not developers, maybe by the end of the year, basically what it means they have 40,000 developers or more accurately, 40,000 technical people that are able to contribute to shipping new features.
It does require meaningful resources and thoughtfulness from the engineering team to put all the guardrails that we talked about.
Using many agents, I'm coming...
from the machine learning world kind of remind me of the good old days where almost everyone trained models.
I know, maybe I'm exaggerating.
Many people train models, not just the foundation labs or boutique labs.
Like at Kota, we fine-tuned models, et cetera.
Like a lot of people were training models and basically it was like a little bit more like slot machines.
You remember like you kind of like do five experiments.
If you're a mental model and you're organized, you can go 50.
If it's not too costly or you have the budget, you can go 50 training all at once during the night or even during the day.
It's like, okay, let's send those machine learning and see what works.
I think part of what we're seeing is that.
You're saying, okay, let's imagine that I need this feature.
Then let's think about three different implementations.
Let's go.
Instead of me overthinking it, why should I overthink it for two days?
Let's implement it and then test it and perform and test it or whatever.
Just an example.
So it's not a bad idea, maybe even a good one.
But that's one, let's say, paradigm that I see.
And the other one is kind of like paralyzing a few tasks that could be paralyzed.
And the interesting thing is that we see the rise of different techniques or capabilities that looked a little bit, unneeded in the past like work trees like how can i have the same branch but basically split and all at once so so you can work without those conflicts and just merge at the end or or so and and i think that's another paradigm where people like are trying to do much more like features all at once and i think it has some like there's some glass ceiling because the glass ceiling is the human capacity to have a mental load of what are all the features that I'm developing right now and who do I need to communicate in the company and what is the target and do they contrast each other and et cetera.
But I think that it's much more than we could do in the past.
If in the past we would do two project older ones, maybe I got stuck here, I'll do that.
Now maybe I'm doing 15 or am I exaggerating and I'm doing five to seven.
The thing is that we do need to remember that right now, Like these agents are basically subsidized.
Like you are paying 50 to 200 while very probably it does cost 2000 or so to the vendor.
So either we'll see a major reduction in compute, et cetera, which I believe will happen.
And or we will be a bit more efficient and thoughtful about which agent we're going to send.
Because it's not going to cost as little as right now.
So it's going to meet somewhere in the middle.
That's my experience.
The way I suggest is be much more thorough about planning.
And think about parallelism in the way you break tasks.
It was useful anyway.
But now it creates superpowers.
If you put efforts into...
guiding your planning, whether you do it yourself or LLM into working work packages that are can be paralyzed.
I think that's the best because then you don't need to run 17 different features all at once.
You actually run five or three, but you do them much faster because all the work, some of the work packages are paralyzed and you completed completely much faster.
So that's my recommendation.
And last thing is that the more you do that, less you can read your code.
Then you have to put and use AI for code review, verification loops.
This is becoming really critical at this point.
Yeah, speaking about paralyzing work, I myself try my best to...
paralyze as many as possible, but my head just couldn't cope.
I think the kind of like switching the tasks, also like looking at each of the agent that comes back and ask me something back, right?
You know, juggling those things is definitely very taxing and you get very tired quite easily.
So I don't know how we could imagine, you know, having so many features being built at the same time.
But I guess, you know, the way of working probably is going to be different as well.
We don't probably, you know.
reply to agent much frequently or maybe look at the lines of code anymore.
It's all going to be more high level, right?
So you mentioned about something in the past that you do with machine learning, right?
I know that previously you were working in Alibaba when your company got acquired, right?
So I think I want to maybe switch gear a little bit and ask, what do you think about the China advancement of AI?
all people know these days is about, you know, DeepSeq, you know, open source model that somehow could produce the same similar, you know, result compared to the, you know, like the, you know, I don't know, like the Western model that is seems to be more expensive than them.
So maybe from your view being there at first hand, right?
So what is your view about China model and where is the trend going with them?
Yeah.
First, an anecdote, it looks like the China versus supposedly versus U.S.
uh llm is a lot about closed source versus open source um you know we wish it wouldn't be like that and sometimes we even have a hope for example uh you know open ai open sourcing one of their models or back in the days when meta did immense like you know effort into being such a foundation lab but it looks like it's all gone or they're cooking something and we'll get it later There is a new promising open source, perhaps from the US, which is Nemotron from NVIDIA.
It's still up and coming and more to show.
But I can tell you that at Kodo, we did a lot of tests on their latest Supernova 3, which is being announced these days.
And it's actually very surprisingly how well it's doing and especially considering its efficiency.
So I still think that until today, there is like very anecdotal that it's US versus China is almost like closed versus open source.
But that might change.
But it does tell you a lot about the differences.
I think a lot of the moat of OpenAI and Entropic, et cetera, is on the LLM.
If you think about the foundation labs in China, a lot of the moat is actually the business.
Like, who are those that are creating their, like, I know there's some, like, foundation labs, but I think still that the biggest one are, for example, Alibaba.
And their business is much more than that.
It's a cloud.
It's like the equivalent of, like, Gemini, you know, like in Google.
Like, Gemini, obviously, is not the business.
And that's in their advantage.
And then it pushes them also towards going open source, etc.
I think that China has great, great talent.
And they have the capacity to think for the long term.
If you think about where they were 2016 versus where they are now, then you could claim...
that you're seeing like a curve that is going to cross the other curve.
But in my opinion, what's really going to happen is just that these two curves, they close the gap and these two curves are going to run together because there's also great talent in the US.
And I think that maybe not government born, but there are huge initiatives that are by the companies that are running.
And then I think the only thing that is actually left for the government, although maybe, I don't know, US companies will take over that as well, is the energy.
I know we're trying to improve on energy efficiency.
I know that NVIDIA are doing their best.
Look on some competitors of NVIDIA.
I don't want to mention names that are up and coming in inference and training devices.
And I don't call it GPUs because they call it differently.
But having said that, I think energy is one of the next biggest frontier, if not the biggest frontier.
And I don't think you solve it on a company level, albeit I might be surprised.
And here, I think China has a very big advantage.
So on one hand, I think on the algorithm side, on the AI side, supposedly, I don't think they're really crossing.
I think it's more like closing the gap.
But at the point where putting AI into scale, when you will need a lot of energy and let's assume that they solve the problem of generating, creating GPUs, manufacturing GPUs themselves, I think that there's might be like an advantage there unless something is happening in the US that I'm not aware or something will change.
I will say something related.
I think it's interesting.
It looks like we're in exponential growth on technology.
But if you zoom in, it's basically S curves such that the time between S curve to another is shrinking.
So I'll be a little bit romantic.
The time between the invention of the fire usage of fire to wheel maybe took a lot of time in between, you know, creating the first like a neural network to attention and all you need, like transformers, whatever.
So it's shrinking.
But when you look at it, it's basically like S-curves of innovation that burst.
And there's always a new innovation coming that's required to continue that exponential when you zoom out.
And I think energy is essential as one of those S-curves that could keep the exponential.
I would even claim that in order to let AI start creating AI, like let AI really innovate math and science, et cetera, we probably need to go through like a S curve of energy and then being able to release AI to start being equivalent of running millions, if not a billion of human brains that are running for a century.
And in order to do that, that's why like what I think like energy is so important.
Yeah, you bring a very interesting aspect, you know, about energy, right?
Because I think many software developers, when we are, you know, subscribing to this, even multi-models, right?
You know, OpenAI, Anthropic, Gemini, and all that.
We just spam, you know, them with our code base without actually thinking, you know, the sustainability aspect, the energy that is required to actually produce the lines of code.
Sometimes even just to change a few lines, we are kind of like lazy.
We ask AA to do it.
So I think that's definitely going to be a turning point where, you know, this might not be a sustainable thing.
we might need to come up with a new invention in the energy space or maybe a new way of doing things.
So I think thanks for bringing that up.
So speaking about model, I know that there seems to be an arm race.
Sometimes this model is ahead of the others.
When the other model released a new version, they seem to go ahead.
Maybe from your point of view, maybe also looking from your wide variety of customers.
Are there some models that perform really, really well, maybe in terms of code quality or code review?
Maybe can give us a little bit of Gleam's perspective from here.
Yeah.
The short answer is that right now what we're seeing is that different models, frontier models, like the best models are better in different properties.
And I think that it's going to keep that way and actually maybe even go you know, towards more specialized models.
This is a bet.
Okay.
Like, and I think longer answer is that for 20 years, we had models, designated models, each one of them specializing in something else.
Sometimes these models could not even compete.
Like they don't have the input output capacity to compete in other models like tabular versus, for example, visual or or so um today you can push a lot i think the gpt 3.5 one of the most and then four one of the most interesting interesting thing about it is that suddenly you had model that was better on everything if you remember those graphs where open ai released the x-axis was like different professions like history math whatever the y-axis versus human like uh competitors or you know practitioners etc and it was amazing like You don't even compare it to models because you already need to compare it to human because it was better than any other model out there.
And then I think we had that moment with Sonnet 3.5, right?
And 3.7, where there were betters on coding.
And that was a moment where, like, Agmoni, like, for two years of one model, like, better on everything, starting to, like, maybe on Tropic is...
actually better on coding, and OpenAI better on other things.
And today, I actually think that Entropic is better on some aspects, or sorry, Claude models are better on some aspects of coding, and GPTs are better on other aspects of coding.
By the way, at this point, it's even to some extent subjective.
It shows you how similar they are.
I have team members that prefer to write code with Claude and then Sonnet, for example, and plan with Opus, but write documentation and review with GPT.
And I have team members the other way around.
They're saying, yeah, maybe GPT 5.4 is a little bit less, for example, 5.4 is a little bit less creative than Untrap, like the Claude's, but it actually does what I'm telling it to do.
Things like that.
I think we got an era of properties.
Even more, you're seeing now companies that are developing models for tabular data.
And you're seeing Kodo developing models that are specific for indexing metadata and code for quality and governance like a layer.
And even fine-tuning OpenAI models and fine-tuning Entropic models, which makes them a unique model.
for code review and et cetera.
And we have more surprises that we'll share later on about this.
So I do think that this is where we're heading.
Now, I have one caveat or one prediction that I didn't put a number on yet.
There could be a breaking point for one of the labs that they actually change the architecture.
Right now, their main paradigm is data.
And compute is all you need.
And you just need to scale.
You hear Dario, the CEO of Antropic, still saying that.
But if one of them is secretly working on a new architecture, I don't think we said the last word on it.
Thinking that the architecture that was found, quote unquote, in 2016, 17, or cetera, with that.
uh like a little bit maybe improved and later on 18 etc with the transformers is is it like the attention layers etc is all you need uh i i doubt it i think like we could put ai to work it's it's called auto ml to some extent neural architecture search and and i think that right now everybody forgot about it but it will come back and then maybe suddenly you see another era where a new model Let's call it Kodo V3 opens a totally new ball game, but then it will last for two years or so until people capture like cope.
Yeah, that's my thinking about models.
And by the way, we didn't talk about open source like Kimmy and Quinn and, you know, that they're great.
And I think like I would expect maybe I'll say that I actually put my money that.
maybe the innovation will come from there.
Why?
Because when you're number two, I'm a sailor, I'm a skipper.
And when you're number two, the wind is the same wind.
Architecture, same architecture.
You have to change your moves to do something different than number one.
So actually those that are working in open source, they're number two right now in accuracy.
They might actually innovate.
And you see Alibaba and Quen models are actually innovating there.
Did they break the glass ceiling yet?
They did not.
But I actually think that they might.
Yeah, seems like all these arms race, very competitive, right?
It keeps changing from time to time.
Very tiring to keep up as well, knowing like which models should I use.
Sometimes I just wish everything is auto, you know, they just decide, you know, what model is best for my case.
But you can do that.
All you need to do, all you need to do, sorry for maybe I'm too simplifying, is with these models, what are you using them for?
For example, at Kodo, that's part of our advantage of being a third party, we use a cocktail of models according to their best properties.
If you use Kodo and you won't go under the hood and configure it differently, probably we'll do a mix of Entropic models, OpenAI models, and even Google models, depending on the deployment.
We're very enterprise-oriented, so we have cloud param, single tenant, multi-tenant, etc.
If there's no issues from the client side, from the customer side, I mean, then we're very probably like you'll get a mix and then who cares?
Like we will do the checks for you.
Sometimes it's really surprising.
There's a new model and it's not better.
Like we, we didn't find, I don't want to say which, like one of the Entropic OpenAI models, they did a little big, like, and then it wasn't better for code review.
And we just kept our older one until the second one was actually better, et cetera.
So just an advice about that.
Yeah.
Speaking about model changes, yeah, I also experienced myself.
So for example, I have the same skill, but applying it with different model, even just a different version, right, could give you a seemingly different result.
And if you layer it with the agentic behavior as well, it could be even more different, right, in terms of results.
So definitely everyone's.
use case is different.
So the insight here is model will keep changing.
I guess you would need to keep up with those changes as well.
So I want to probably bring up the discussion.
We have seen so many advanced use cases, invention.
But at the end, the developers are feeling anxiety.
We are feeling like, OK, what's our task in the future?
Are we going to be replaced?
If I don't write the code anymore, just write the plan.
How many developers really are we needing?
What's your view on this?
Maybe do you have some take that you can share with us as well?
Do you remember that people said that automatic cars, autonomous driving is coming 2020, 2021, 2022, et cetera?
You know, it did come eventually, right?
I mean, we're 2026, which year are we?
It's like starting to scale, right?
By 2030, which is 10 years later, then I think it will be a large scale across the US.
And I think Karpati, which was in the Tesla AI team, said that he thinks that we're in the agents era and software development automation will take as much as it took autonomous driving, where it started.
2010, it depends if you count DARPA already like announcing on a 2090 or something like that.
But there are a lot of big efforts like it started 2010 and took until 2030, let's say.
I think that software development will be solved by 2041.
Think how different than I'm saying it, different versus like other CEOs.
I heard like Entropic and OpenAI saying five years or three years ago that by the end of next year, no need for developers, but no need, the year after in six months, no need for developers, you know, et cetera.
Now they're saying for a window of time, of a time window, we might actually need more developers.
If you heard that, but they're saying it for the first time after like three, four years claiming that there's no need for more developers.
Even Jensen from Nvidia said in two years, AWS CEO said in two years that these two years are about to end.
And I don't think that the developers, disappeared.
But hey, I am claiming.
But notice what I'm claiming.
I'm claiming that eventually it will happen.
So what we need to do as a developer is evolve really quickly with the profession.
By 2030, it's going to look completely different than it was in 2025.
2025 was quite different in 2020, right?
So we do need to evolve with it and Interestingly, I think that by 2030, actually, the knowledge that we had still need to be the same.
This is a big claim.
It's very different than what others are claiming.
Because I claim that in order to put those rules, put those skills, put those guardrails, monitor the coding agent and the verification agent, you need to know software development properly.
not in 12 months, not in 24 months.
I even think like in three years, you still need to be a developer.
Hey, but at the same time, one developer could do a work of 100 developers, right?
So like at some point, I think 2030, we're going to some, maybe a tipping point where software is obituous.
Like anyone can develop like simple software and And software development reached a pick.
And currently, it's actually growing, I believe, despite all the firing and et cetera.
But at that point, I think we're going to start seeing decay and decay and decay over time.
And it's even like the software development role will evolve.
And eventually, it's really hard to predict.
I think it's going to be completely new jobs.
It's a totally different world.
Forget about software development.
Once we got to that future, it means that we're a totally different level of automation.
Software development, on one hand, is the easiest because it's formal to some extent.
On the other hand, if you completely automated software, you probably automated a lot of other stuff that we do and use.
And then we'll see.
very new roles and adopting and working with AI, I think will bring you two into those roles, in my opinion.
Yeah, it's always exciting to predict something, right?
But definitely, you know, the key message for people is to keep evolving, you know, reinvent yourself, especially this change is not like a tool.
related change right this is like the whole paradigm change right capability will change and in fact the profession the software development profession itself will evolve by a lot maybe we don't even call ourselves software developer anymore maybe it will be something else who knows but yeah thanks for sharing your perspective uh here appreciate that so uh itama um i think we are reaching the end of our conversation uh but before before i let you go i have one last question i call this the three technical leadership wisdom Just think of them as like an advice you want to give to the listeners.
Maybe if you can share your version today, that would be great.
Yeah, awesome.
So one advice, very important one that I already gave.
Do keep learning software development, even programming language.
Of course, architecture decisions.
all those senior level decisions that need to be made.
But don't give up.
Keep doing that.
It's going to be very important for us as a community and for you and your career all the way to 2013.
As you progress, a lot of soft skills, business skills, product skills are going to be really important.
How you collaborate with your colleagues, with the world, with partners, with...
with management, et cetera.
So invest in that.
That's almost like counterproductive for developers in their old world.
Like, you know, where's my hoodie?
I don't want to talk to anyone.
Give me my task and let me code.
And right now, like you need to be really good in communication and business and product, like understanding, et cetera.
So I definitely like recommend that.
And I would also recommend investing.
Take part of your money and invest in those companies that I think are going to be like a big part of the future.
So it's almost like insurance.
If that future comes that we're claiming that, you know, like in 2035, 41, like everything is automated.
Right.
And let's assume that you don't have a job.
I think it's just going to be evolving.
Right.
But let's.
So what's your insurance is like betting on, you know, the right companies.
The thing is that these two tips goes along together.
If you are a good developer and you learn your skills, soft skills, et cetera, and business and product skills, you get better intuition and you're in the market to understand who are the promising companies so you can invest in them.
I think many people invested in NVIDIA before it became a thing when they realized that this is going to be something big, et cetera.
you want to you being in this market i think gives you that that opportunity as well i'm not a uh invest investor per se or i'm not allowed to give any investment uh so take it with a grain of salt and everything i'm supposed to say in addition to that well that's that's my advice Wow, very interesting angle about investing.
So probably this is the first time somebody mentioned about that, but I think you do have a point as well, right?
So if all this new innovation comes to fruition as predicted, definitely the valuations that they have is something quite massive.
And if we can take the ride with them, I think that will be also something.
Maybe one persona, one that I missed in this is that we, I talked a lot about like the developers.
If we go one level higher to the tech lead, to the managers, et cetera, with everything that is in X and, you know, social networks, this future is coming, but you know, it's coming and you're responsible and make it happen.
And this are two different things.
I, with subjectivity about like, shameless plug for kodo as being one of the if not the leader in this you have to invest in quality workflows and putting the guardrails and rules etc to bring that future for you take a look at what ramp is doing what block is doing um i mean on the part of automating like software development on firing people etc and and uh and and notice how that the tech leads are investing in it don't wait for i don't know like Cloud or Cursor bring you the tools.
Understand your entire software development and bring the tools to the right bottlenecks.
That's where Coda, for example, is playing with the code review and governance.
But it doesn't have to be that.
Maybe you need an SRE agent.
Maybe you need like, you know, product design agents, etc.
That's my other advice.
Quality and workflows are the moat and will be your advantage versus competitors.
don't wait for it to come to you invest in it thanks for the plug i think that's really nice right so for people who are like in the leadership manager tech lead position right you do have responsibility as well to make this future happen.
And also, yeah, not getting kind of like laid off simply because, you know, we don't need middle managers anymore, but I think you guys play a big part as well.
So, Itama, thank you so much for this exciting conversation.
I really learned a lot, and especially I love hearing the new advancement that you share.
If people love this conversation as well, they want to reach out to you, connect with you online, is there a place they can find you?
Yeah, of course.
I'm Onyx.
It's I-T-A-M-A-R underscore M-A-R.
And on LinkedIn, Itamar Friedman.
Generally, you can just search Itamar Kodo, Q Audio, and you'll find me.
By the way, Kodo stands for Quality of Development.
Nice.
Thanks for adding that.
So, okay.
Thank you so much again for your time, Itamar.
I wish you good luck in, you know, revolutionizing how we do software development and code quality and code review.
So thank you so much for spending your time today.
Thank you, Henry.
It was really a pleasure.