# AI Shifts Software Teams From Capacity To Judgment

**Podcast:** Engineering with AI
**Published:** 2026-06-02

## Transcript

I think not losing the deterministic tool set is certainly smart.
But, I mean, on some level, you could use Mythos to detect these zero days.
Anyway, but I don't want to keep...
But where is Mythos?
That's a fair point.
Maybe it is self-ismith.
Where is it?
I love it.
Spicy take.
Ahmed Nisba is an independent consultant specializing in digital transformation, enterprise architecture, agile software development, and artificial intelligence.
He currently operates under Tech Cafe, which he founded in 2023.
He's also the host of the Tech Cafe podcast.
Formerly the chief architect for Orange Innovation, part of the Orange Global Telco Group, he has more than 20 years of experience in software development, most of them working with extreme programming, including lots of Python and Java.
He's also an AI researcher with a master's degree in AI earned in 2012 with seven publications to his name.
His expertise is mainly in machine learning and natural language processing.
He's currently preparing for his PhD in Arabic LLMs.
Ahmed is also a guest today on the Engineering with AI podcast.
Ahmed, thank you so much for joining us today.
Thank you for having me, Kyle.
It's a real pleasure.
It's fun to have a fellow YouTuber on the show.
I'll admit to being maybe nervous to see what critiques you have and maybe there's improvements I can make.
Yeah, let's start there.
Like, I mean, how long have you been doing the podcasting thing?
What's that been like for you?
I've been doing the podcast since 2023.
And when I started the podcast, the mission was simple, to empower the software development community through insightful and inspiring conversations.
And I was lucky to host.
A lot of great people like Jeff Langer, which you've also hosted on your show.
And also Uncle Bob, James Grinning, Craig Dave, Alistair Coburn, and Tim Oettinger.
Yeah, I was about to say, you've had some amazing guests.
So nice work, nice work.
I like the way that you're involved in the academic community around AI.
And you're coming at it from a different part of the world, too.
How do you see all this taking off?
Like in North America, here in Canada, where I am, and in the States, we're sort of constantly surrounded by all the headlines.
Maybe it's going to be an economic miracle.
Maybe it's going to be a total bust.
Maybe it's going to be the end of the universe.
Who knows?
All sorts of things that people are really fascinated with.
And I feel like we're worth this precipice where people don't know what they should be doing with it, but they probably should be doing something.
And I think here in Canada also, there's a little bit of an aim towards being like maybe sovereign with your AI and being able to have a Canadian AI or at least not have them all be U.S.
companies.
What's your experience like there?
Like, how are people responding to this in Egypt and North Africa?
The scene here in Egypt.
with regards to software development is pretty much like the rest of the world.
Mark Anderson said in 2011 that software is eating the world.
Most recently, Jensen Huang, NVIDIA's CEO, adapted this to reflect that AI is now revolutionizing how software itself is created and operated by saying AI is going to eat software.
Now, I'm not sure if it's going to eat, it's already eating software.
Everyone in the software industry in Egypt is now using AI one way or another in software development, but it's mostly in writing code.
Talking about sovereignty in AI, I think this is something that many Arab countries are now taking very, very seriously, but not everyone is on the same level, and it's mainly due to funding.
So you will see that the rich countries...
like UAE, Qatar, Saudi Arabia.
They already have their data centers and they have their foundational models trained on Arabic data.
Most recently in Egypt, we have built our own data centers and we've recently launched our own sovereign LLM.
And it's only a matter of time when you will see Egyptian companies and also the government starting to adopt that or use that to build applications rather than using foundational models coming from, you know, the rest of the world.
It's interesting times we live in right now, for sure.
Let's start with your own personal experience and let's start with the tools.
How do you use these tools?
I mean, which ones do you like and which ones have you tried?
And how have you adopted it as part of your software development process?
I mainly use Cloud Code with either Opus or Sonnet, mainly for writing the tests, then writing the code.
I'm a test first fan.
And yeah, I mainly use the agentic coding tools.
I have never used, I will never...
use the autocomplete style tools never thought they were really useful.
I think that prompting an AI tool to write a considerable piece of software is much better than writing something and it simply autocompletes.
I didn't find that quite useful, but this is just a personal preference.
I do understand that other people found it useful.
Sure.
Yeah, I mean, listen, from a productivity standpoint, I think, you know, the majority of people are with you at this point.
You can get a lot done in a conversation, in a dialogue with an AI agent.
I will admit that if I have like a large CSV document that I need to reformat in some way, like it's pretty good at figuring out like, oh, he's done the same change on three lines in a row.
Like maybe this is what he means for the rest of them.
Some of that stuff is kind of handy.
But but otherwise, yeah, I'm 100% with you.
Yeah, the agentic style, that dialogue just feels right.
You know, it's working for me, too.
Cool.
It feels new and it's very addictive.
So when we were using autocomplete, it was like writing an email.
It was the same thing.
There was nothing new about it.
But this agentic AI coding thing, no, it's much more interesting.
You know, it's like gambling.
You're on a machine and you go like, oh.
waiting for something.
So it's much more exciting than simply writing some code and then it says, ah, you're probably going to write the rest of the code that way.
No, I'm not going to write it that way.
The agentic style coding tools are much more fun to use.
Yeah.
The slot machine comparison is a lot of fun.
The slot machine.
Yeah, I forgot the name.
That's why I described how it works.
Yeah, the slot machine.
No, amazing.
I don't gamble, but...
Me neither.
I can understand the feeling.
We only gamble with flawed tokens.
Yeah, exactly.
Yeah.
Is it going to get something brilliant?
Is it going to be like nearly done or is it going to be stuck in a rut somewhere?
You never know.
Yeah.
Yeah.
Okay.
What about guardrails that you use to make the tools effective?
Do you find that there are safeties that you need in place or you already talked a little bit about test first and so on.
So what guardrails do you use as part of the process?
That's a good question.
So I use rules to make sure the coding agent follows guidelines for writing well-designed, clean code.
I use skills for teaching it how to perform certain tasks.
And I use a mix of hooks and MCP for deterministic control.
And this is where all the fun is.
So you spend a lot of time.
writing these markdown files and you're like, ah, finally, I'm getting the time to do this.
So you're basically dumping every single thing you know into these MD files and you're seeing how they are reflecting on the actual implementation.
It's really interesting and it's producing good results, but it's something that is continuous.
So you're always like, how can I make this a little bit better?
So, yeah, but anyway, these are the kind of guardrails that I use.
Yeah, I'm with you.
I think that's like where the job is now.
Like we may not be fine tuning the for loops anymore.
The agents may be handling that now.
Getting the harness right, getting the guardrails right, getting the sandboxes right, all those kinds of things.
I think that's where we're still quite needed in addition to nudging it in the right direction from time to time.
Are you finding that the tools have superpowers that you didn't expect?
Have you pleasantly surprised or radically surprised by something that it does better than you expected it would?
So it certainly minimized the learning curve.
for adopting new libraries, technologies, and even programming languages.
And it improves productivity for sure.
But when it is used right, if it's not used right, you waste time and you waste tokens equals equals waste money.
A lot of money.
And now you get to spend more time, as I've said previously, to think about the more important stuff, like how to write better specs, better tests.
design better software.
You no longer have to worry about the actual implementation.
And one other thing is that, again, if it's used right, it actually saves money.
Why?
Because in the past, when you wanted to buy this really fancy tool to do something, you can now just ask AI to write it for you and use it as part of your workflow.
And that's it.
You don't have to spend money on expensive tools anymore.
So yeah, this is where I find the superpower that, you know, AI is giving us.
Yeah, yeah, 100%.
I know a lot of folks in enterprise which are starting to question like, why do we need to buy that SaaS tool?
Like we could just make that.
That won't take that long now.
Yeah, that is definitely one of the big superpowers for sure.
Okay, so let's think about the teams you've had the opportunity to observe, teams that you serve, you know, and how we work together as teams in software development.
And personally, I find that like when I'm working with it one-on-one and when I'm working with it in a team, I start to think differently about how things work.
So yeah, think about your observations there or in your own practice, either way, but getting into the software development.
Let's start with...
product management, and story breakdown.
Have you seen changes to the way that that happens when using the AI tools that we have today?
The first thing I've observed is that the ratio of developers, testers, in comparison with people who do product management has actually changed.
So we're now seeing an increase in the number of product managers than the ratio that was before the AI era.
And there is a reason behind that, is that Many companies, of course, I'm talking about Egypt.
Many companies in Egypt have realized that the implementation is no longer the bottleneck, but it's the what do we want to build and how are we going to design it?
Okay, from a technical perspective, a software design perspective.
So it's no longer about the implementation.
The implementation is no longer the bottleneck.
We want to...
give more focus now on what do we want to build okay the product and yeah so this is one major change i've seen in that part so companies are now hiring more product managers because the productivity has gone up so now we want people to think about what we want to build rather than more people to build it This is a new bottleneck.
Yeah.
Is that other side.
Oh, interesting.
That's interesting.
Are there specific industries where you're seeing that?
Is this the kinds of businesses that are helping accelerate other businesses with software or is this enterprises?
What can you say about where you're seeing that?
Mainly product companies, not project-based companies.
Yeah.
Right, right.
So the ratio and project-based companies hasn't changed a lot in terms of product because they're not doing product, right?
Right.
They're doing something that is temporary and you do one project, then you move to the other.
But what I've described earlier is mainly in product-based companies and startups mainly.
Right.
That's interesting.
I feel like I predicted that and that others have predicted that, but it's interesting to hear a statement that it's happening.
That's really cool.
It's funny.
My own experience with all of this is that...
For one of the clients that I work with, and there's a couple, of course, but there was a period of needing to cut, of needing to reduce team size.
And their adoption of AI in a bigger way happened right after that.
And that wasn't a cynical response.
It was just the timing.
It was sort of a lucky timing.
And so there's an accidental effect, which is similar because you've reduced the number of software developers, but you didn't reduce the number of product people.
So accidentally, we've had an enrichment to product manager to software developer role.
role ratio, but it wasn't on purpose.
So it's interesting to hear that, yeah, it's maybe happening on purpose also.
Cool.
How is it changing how that works then?
If we're changing the role ratios there, are product people, I imagine, using these tools for research and those kinds of things?
There's been a thread that software developers need to understand the product more deeply now, right?
Like since the agent gets to take on the fine details of the for loop.
that maybe the software developers need to add value in terms of understanding the product.
So are you also seeing that or is this sort of allowing the software developers to stay more engineering focused?
That depends on the maturity of the team.
Okay.
So if the team is in a learning organization and the organization is giving them the time to explore and play around with these nice AI tools, yeah, they reach to a point where they realized that, okay, the engineering part is okay for now.
Let's now focus on writing better specs and having a better understanding of the product.
But in companies that are not a learning organization, it's not like that at all.
Actually, even in terms of engineering, it's getting worse.
Why?
Because in the past, developers are writing the code.
So they have an idea of whether rewriting good code or bad code.
But now there's a push even from the clients.
Okay, you guys are now using this nice AI thing.
We expect hyper productivity.
Okay, so I'm no longer going to accept you telling me two weeks, three weeks.
No, it's just one week.
Okay, so.
The developers don't yet know how to use this tool well.
Okay, so they use it badly using Vibe coding and they ship lots of bad code.
And we all know what happens with bad code.
Productivity simply goes down.
So it's all about learning.
If you give people the chance to learn the tools well.
and the emerging best practices.
I don't like using the term best practices, but hey, this is the common term.
If you give people that chance, yeah, eventually they reach to the point which you've just described, that they try to build that understanding of the product.
Yeah.
But when it's firefighting mode, quickly, guys, we need to ship.
Yeah, yeah, yeah.
I love how you're bringing the learning organization concept into this.
So that's, Yeah, that's obviously going to impact how organizations adopt it.
I'm with you.
And on some level, an organization which acts more like a learning organization maybe would encourage software developers to get involved in product thinking and not ask them to relegate themselves to engineering detail only, which might make them more useful versus the kind of organization which is just trying to maximize every dollar of productivity and not really thinking about how are we learning in this organization, but more like.
How do we get everything out faster?
That's an interesting dichotomy you're bringing to this that I hadn't thought about yet.
Thank you.
So we've talked about product management, story breakdown.
We've talked about roles already a little bit.
What about architecture and planning?
The role that you do and that sometimes I do.
How are you seeing the new tool sets changing how we do that?
AI is terrible at software architecture and design.
It used to be bad at coding, but now it's really good at coding.
But it is still terrible at software architecture.
I had Mark Richards previously on my show, and we had a really interesting discussion on that.
And we've said that the best way to use AI with software architecture is for a human being to start with something, okay, like a draft for the architecture.
And it can use AI to...
detect what's missing, suggest improvement, analyze it, criticize it.
This is where it is really good at and perhaps documented as well.
Okay.
Because AI is really good with text.
And if you're using plant UML or Structurizer or Mermaid.
It's all script, right?
So it's really good at that.
But don't ever tell AI, I'm working on this app, design me an architecture for it.
It's going to be really bad.
It's going to be terrible.
Okay, I have to ask, what do you mean?
I can imagine, but I don't want to guess.
What do you mean it's going to be terrible?
What I've noticed is that most of the time it's microservice architecture.
I mean, for God's sake, we're trying to tell people now, don't start with microservices.
It's not a good thing.
But AI, based on the training data, it's always services, services, services, services.
It doesn't work that way.
Okay.
And again, there's always a problem with context.
Okay.
Providing it with the right context.
Now, with architecture, You have to provide it with architectural drivers.
That is the business objectives, the functional requirements, the non-functional requirements, the architectural constraints, the architectural concerns, the business could say.
So you have to provide it with lots of context to get something good out of it.
Nobody has time for that.
So that's why it's usually...
like vibe coding.
Okay, so you write this prompt.
It's not a very long prompt.
So you're not providing it with enough context and you get what you've paid for.
So, yeah.
So you've written a short prompt.
You get a terrible output.
I'm with you.
What if you do spend more time with it though?
Like, does that improve things?
That's a very good question.
Now, I've noticed that we are still discovering when to use AI in the loop and when to use human in the loop.
Now, working with different teams and even the kind of work that I do on the side, I've discovered that every activity we do in software development is going to be placed under one of four bands.
So the first band, I call it the authoring band.
This is where you use AI in the loop.
Anything that has to do with Guidance, validation, verification, governance, specification, design requirements.
This is something humans should do first.
Using the things we know from agile software development, story maps, user stories, domain-driven design, all of that good stuff.
Give it to the AI for the AI to like spot gaps, missing things, stuff like that.
Okay.
And it will act as context later on for the AI.
But we don't go telling the AI, we want to do this.
I want to see the domain model.
This is not the right way to use AI.
So the authoring ban is where humans should do the work.
collaboratively and use AI in the loop.
Okay, now the second band is the implementation band.
Based on what you've done in the authoring band, now you can let AI do the work and you can review it.
Human in the loop.
Now that makes more sense because AI is just writing code, writing scripts, writing documentation, drawing diagrams.
AI can do that.
You don't have to waste your time with that as a human being.
But you have to review it.
And sometimes if you add the right guardrails, which you have written as a human being, then the implementation band is based on what you've done in the authoring band.
So you're okay.
You can do human in the loop.
You can skip it at some times.
It's okay.
The third band is the analysis band.
Now here, there's a little bit of flexibility.
You can let the AI do the analysis and you review it.
Or you do the analysis and let the AI...
Criticize it.
Okay, the analysis band is, it's okay.
AI in the loop, human in the loop.
It's okay.
And then there is the fourth band where AI is never a player.
Stuff like security patching, dependency updates.
Now, I can't imagine AI doing this autonomously.
I always imagine it's going to end up terribly.
So this is something that a human being has to do based on external triggers.
Now, you've got a zero-day vulnerability, for example, and you have to fix that.
I still can't imagine AI doing that.
How is it going to do that?
Like, is it going to be following up with the news?
And if it detects some sort of trigger, it's going to come up with a solution.
It's a zero-day vulnerability, for heaven's sake.
It's called zero-day because nobody knows anything about it.
So this is where AI, it can do the implementation, but you have to guide it.
Yeah.
These are the four bands.
And again, I may be wrong.
just something I came up with based on my experience.
I like it.
And I'm following you with authoring and implementation.
I like that.
I like that a lot.
Those are really resonating with me.
With analysis, I'm not sure I fully get it.
So authoring sounds like it's kind of kickstarting a project and getting it going, or does authoring sort of continue as software continues to mature?
How should I think about that?
That's a good question.
Analysis is feasibility studies, trade-off evaluation.
algorithm comparison post mortems root cause analysis this is analysis yeah got it so in the fourth band in security i i have a counter factual i think um and i want to try it on you so i know a group right now that um that you know they they they have a tool called sneak and their github pipeline uh and it will tell them like hey you have vulnerabilities And what they've done is they've written a piece of software using the AI tooling, cloud code specifically, that will go and say like, oh, thank you for telling me about those vulnerabilities.
And it will then go fix them.
And then it will run the entire end-to-end test suite.
And if there's problems with the end-to-end test suite, it will fix them.
And if there's problems with what it did fixing the sneak vulnerability, it will fix that.
And then it will put the whole thing together as a PR.
And at this point, you know, the most annoying part is that they have to go look at all of the PRs.
But it used to be playing this game of like how far behind are we on our sneak vulnerability.
And now it's drastically reduced the amount of effort that they have to put in and increased the quality of the result.
Maybe that would be in your implementation band, I guess, but it sounds like it's partially your security band.
So help us understand how you mean this and how that how that sits in your model.
So so as you've said, this is in the implementation band.
Why?
Because the way you discover the vulnerabilities is something that is rule based.
So it is deterministic.
OK.
And then you tell the AI, hey, look.
These are the vulnerabilities we discovered based on our deterministic tools.
Go fix them.
But there is something else.
There is this hidden band, okay, one that is related to operations.
Now, operations is a gray scale, okay?
Now, when you read AI ops and all of that, they give you the impression that...
Operations can be done totally autonomously with AI, right?
But can we really trust AI with our infrastructure and our monitoring and our auto-scaling, remediation, self-healing systems and all of that?
Okay, it can do it.
Yeah, I believe that.
But can we really trust it?
Like, just leave it?
No human in the loop?
I don't think so.
Still, even if it can do that.
We still need a human in the loop.
Now, why am I talking about this?
Because this could be something that is being checked in real time, right?
I mean, let's say you're starting to get suspicious traffic on your website.
And I did work on some AI models that would do that.
It would detect traffic coming from botnets, for example, okay, using deep learning models.
Well, yeah, but this is something operational.
It is something because operations is something continuous, okay?
And it's very human intensive because, how do I say it?
You need someone to install the tools, configure them, and basically monitor.
Okay, the automation, even before AI, could take action without human intervention.
Yeah, we know this.
Yeah, web application firewalls and things like that.
But that was all deterministic.
AI is non-deterministic.
And this is the scary part about it.
Yeah.
So here's my answer to your counter example.
Got it.
That's helpful.
I think where my brain lights up with what you're talking about in terms of, yeah, but we still have to pay attention.
We still have to be in the loop.
I think it kind of cares about what we care about.
If I find like it'll usually write unit tests on its own, but if I ask it about the unit test, it'll try harder.
If I don't ask it about the unit test, it might forget.
So I kind of feel like security is in that bucket.
Like it wouldn't pay attention if we don't pay attention.
That is for sure.
Yeah.
I think the deterministic, non-deterministic is also an interesting angle that you're bringing to this.
And I think not losing the deterministic tool set is certainly smart.
But I mean, on some level, you could use Mythos to detect these zero days.
Anyway, but I don't want to keep going.
But where is Mythos?
That's a fair point.
Maybe it is self-ismid.
Where is it?
I love it.
Spicy take.
Okay, cool.
How have you seen these tools and these new models help with testing?
How has that changed?
Interesting.
Now, you've got the...
XP people, now this is helping them a lot because they no longer have to actually write the tests.
They can start focusing on the test list or test cases.
So these guys are having a lot of fun and they're actually using tests as a guardrail and that's the right way to use them.
They always have been a guardrail, by the way.
It's not new.
We used to call it a safety net.
Now it's a guardrail.
Okay, whatever.
Yeah, but the people doing the test last thing, QA teams and the handoffs and all of that.
Well, now there is no excuse for not doing automation.
So some people were like, we don't like coding.
We were terrible at coding.
That's why we went for testing.
Now they.
Now they don't have any excuse.
Okay, now you're not going to be writing the code.
You're just going to be writing a prompt or a spec.
Yeah.
Go write those automated tests.
Yeah.
And yeah, we're starting to see a lot of people moving from manual QA to test automation, which is good.
I mean, test loss development is better than...
Nothing at all.
Now, I've always had this problem with QA teams.
Test design.
Now, when you do QA without test design, you're basically doing exploratory testing.
Okay.
And I don't like that.
There has to be test specs.
Now, you can write some test cases and let the AI augment them.
You can just write a skill on how to do...
equivalence partitioning, boundary value analysis, decision tables, and all of that, the ISTQB stuff.
And they will just go and do it.
So right now, even with classical QA, we can finally do it right.
Okay, I'm not a big fan of classical QA, but again, QA is better than no QA.
And I believe that if classical QA is not done correctly, then you have no QA at all.
So yeah, this is what's happening right now with QA.
People who are doing test first are having the best time in their lives, the XP people.
And the classical QA people, well, finally, things are starting to get done right on their site.
I know they're going to hate me for this, but...
No, I like it.
I like it.
Yet another spicy take.
This is going to be good.
Okay.
What about integration?
And I'll be fine.
trying to refine this question a little bit.
I think what I mean here is not just like, should we have a CI pipeline?
Like, yes, yes, we should.
But more in terms of like, let's say there's a new service that you need to integrate with.
Maybe it's a cloud service that provides this API to you or it's another part of the enterprise that you've never touched yet.
And it has a service that you need to use and they use different processes and they're a different team.
So what have you seen in terms of how AI changes integration?
That's an interesting question.
Well, Again, it depends.
You know the software guys, the answer is always it depends, right?
Always it depends.
Yeah.
Okay.
So if you're integrating with something that is well documented, then now AI is a blessing, right?
Because you can just go refer to the documentation and it will write the code and great.
So it's basically making integration a little bit easier.
And I don't know how old are you, but...
I have witnessed SOAP web services, CORBA, RMI.
Remember those?
Promote method and vacation, yeah.
Yeah.
And these were not really easy to work with, right?
Especially SOAP.
Right.
But if you are now, now all of the young developers, they know nothing but REST endpoints.
Everything is a REST endpoint.
GraphQL.
And now.
Yeah.
When you're integrating with legacy, what on earth is soap?
I've never heard about it.
So now AI is making this challenge, again, the learning, much more easier, right?
Because you don't have to go and read about soap or services and all of that.
Now, there's another aspect, writing loosely coupled software.
Now, you can easily tell the AI now to...
do the integration with ports and adapters much easier than it would have done previously.
Okay.
So this is another aspect.
So yeah, it's definitely making some changes in integration with learning when it comes to legacy, integrating with legacy systems.
Yeah.
And with building loosely coupled software.
Yeah.
A hundred percent.
Okay.
What about deployment and infrastructure?
What changes are you seeing there?
Not a lot.
especially with, again, people who got continuous delivery correctly and XP, not much change is there.
Okay, because they already had the pipelines, the automation.
So not a lot of differences there.
But let's say you're new to the project and you've never used GitHub Actions or GitLab or Jenkins, and there are all of these scripts.
AI is going to help you with the onboarding.
Let's say your team leader tells you, hey, we're going to be deploying this new microservice.
Go build the CI CD pipeline.
It's a learning experience.
Okay, so now you can give the AI some context, the other YAML files, and it will write you the YAML file for the new pipeline.
And there you go.
The team leader will be very happy with you.
So again, it's the learning.
Again, it's the learning.
Not much difference, but again, that's just me.
Maybe it's making difference elsewhere.
No, I think you're right.
I think that's pretty bang on.
To your point, if there was automation before, I've had guests say, like, it's really good at the automation so that it sort of eases that.
But to your point, they were already using Terraform and things like that.
So fine, that's just kind of more of that faster in a way.
But I like what you're saying about the learning process.
Like if you are still sort of doing it the old way, or haven't done it at all yet, like, yeah, it's definitely going to accelerate your process.
I think that is right.
Exactly.
Yeah.
Okay.
What about debugging, refactoring?
Are you seeing it change the way that we do those things?
Oh, yeah.
Let's start with refactoring.
Okay.
I'll get to debugging in a moment.
It's terrible at refactoring.
Okay.
Terrible.
If you don't give it the right context.
Yeah.
Now let's go back to the first band, the authoring band.
Now, we have a saying in Arabic, meaning that if you don't own something, you can't give it.
So if I haven't read the refactoring by Martin Fowler, refactoring to patterns by Joshua Kriviaski, Tidy First by Kent Beck, A Clean Code by Bob Martin, if you haven't read those and you know nothing about design patterns, nothing about good design, all of that.
you're not going to be able to write the right rules for AI to follow to write good software.
And you're not going to be able to tell the AI, hey, there's a smell here and this is the way you're going to fix it.
Because as you know, one smell can be fixed using many techniques, right?
Okay, like long methods, many techniques.
You can extract it into another method.
You can extract it into a class.
You can extract it into a strategy pattern.
All sorts of refactoring techniques, right?
But the AI doesn't know all of this.
And it's, until now, it's bad at this.
Not really good.
Yeah, like it doesn't have good taste in which ones to apply and when.
Yeah, exactly.
So you need to use your knowledge in order to guide it.
So you're going to tell it, here are the smells.
Or at least you can tell it, detect the smells.
And here are the smells I'm interested in.
Go find them.
come back and tell me how to fit okay but if you don't have the knowledge then it's you can't give what you don't know you don't have yeah no i love that i had a recent experience where i had a code base that was six seven eight nine months old and it was just you know pre-market fits or just feature after feature after feature after feature being developed and never really going back to look at tech at all.
And I finally sat down with with Cloncode and decided to try to look at this.
And to your point, I had to sort of prompt it for like what smells I was looking for.
And of course, yes, it found them in the code that it had written.
And then it puts together a fairly decent suggestion about what to do.
But then as it's applying that, it sort of created new smells.
It ended up doing a lot of like.
method injection of dependencies.
And so now all of your method calls have like the thing that the method actually cares about and the three dependencies it needs.
It's like, okay, there was another way to do that.
Like even in Python, that's not the best practice for dependency injection, y'all.
So like, okay, good job, but not quite.
So yeah, it's like, it doesn't know what to prioritize.
It doesn't know enough about what good looks like yet to be trusted with that.
I still think it can.
automate my own desire about, you know, refactoring and make it faster.
But it's, I can't leave it on its own yet all the time.
So yeah, I follow where you're going there.
It makes sense.
And the guardrails.
I've seen Bob Martin.
He loves cyclomatic complexity.
I mean, to him, this is a really good quality metric.
And he writes this tool for the AI to use.
So, again, if you haven't heard about cyclomatic complexity and you don't know what it is, you're not going to ask the AI to, okay, let's say you know nothing about smells and clean code and all that, but you know cyclomatic complexity.
It's a good measure.
So the AI can do some refactoring, which it thinks it's good.
But then, oh, no, I've made the cyclomatic complexity of this code worse.
Let's try something else.
Let's try something else.
So it keeps in this autonomous loop until it reaches a good quality metric.
Yeah.
But again, faqadushayla yotih, right?
Yeah, yeah.
Yeah.
No, I'm with you.
I'm with you.
Cool.
What are you seeing it doing to pair programming, mob coding, things like that?
How has it changed how we practice those things?
Nice, nice.
Now, I know one of your previous guests said that he doesn't think that AI is working with collaborative programming, as Bob Martin likes to call it.
I've had an interesting conversation with Alistair Coburn the other day.
I haven't yet published the episode.
It's on the way.
So you have something exclusive.
I'm looking forward to that.
Yeah.
He said something that is really good, and it's mentioned in his latest book.
So the problem with AI right now, when it's used the wrong way, is that it produces so many things that our cognitive capacity as human beings cannot take.
I cannot review thousands of lines of code.
It's beyond my capability, right?
But here's the thing with ensemble programming.
We are countering...
the sheer volumes of whatever AI is producing with adding more cognitive capacity by working as a herd, as a team.
So mob programming is more important in the AI era than ever.
Now we have five, six people against this monster, the AI.
Okay.
Yeah.
That's one perspective.
The other perspective, and this is all...
Alistair Coburn talking, not me, learning.
So right now, junior developers are like, how on earth are we going to learn anything?
Okay.
They need seniors and all of that.
Okay.
So the junior developer can sit in the mob, watch people dealing with this AI.
and learning from that experience.
And, you know, with mobbing, obviously it's not just one person working for hours.
Every hour or so, somebody else takes the driver's seat.
So it's a good learning experience.
And this is not new.
I mean, we've always had collective ownership.
It's not new.
But I see ensemble programming as a very important practice to do in the AI era.
I think you're right.
I think the, so...
I will admit that certain kinds of pairing, I feel like it sort of not replaces, but it fills a similar spot in my practice that pair programming used to, I guess.
However, like it goes so fast that I keep thinking and observe with teams that sometimes a non-programming session is exactly what the team needs to sort of become realigned with what's actually in the code, you know?
Otherwise, if it's just me and my cloud and you and your cloud, like we're all just like changing the code base very rapidly.
And how are we still in touch with it?
In my mind, mob programming is a good anecdote for that or antidote, I should say, for that.
Interesting.
Cool.
And you've had guest talk.
I'm really looking forward to the Alistair Kilburn.
That's going to be great.
Okay.
Yeah.
Cool.
Yeah.
So we talked about team roles in terms of product.
Are you seeing any other changes in terms of?
team ratios.
You've talked about different kinds of environments, like classical testing environments, you know, very manual, very human-centric, you know, old-school QAs writing the tests versus, you know, a more modern approach.
How are you, so in either one of these or both, like, how are you seeing the other role changes in their balance and ratio to one another?
Yeah, well, the Egyptian market has done something strange.
And this is all based on data.
So in the past, the ratio used to be, and this is based on data, three devs to one QA to 0.3 product manager.
Okay.
Okay.
Now it's six to one to one.
So you've got six developers per one QA per one product manager, not 0.3 as it used to be in the past.
Now this suggests a lot of things.
First of all, Egyptian companies are saying, nice, this is making us become much more productive.
So let's hire more developers to be even more productive.
And by the way, labor in Egypt is cheap.
Okay.
So the mandate cost per developer or per whatever is not like the US, is not like Europe.
It's cheaper.
So Egyptian companies can afford to...
hire more people.
Okay.
So that's one thing.
Now, QA didn't shrink.
It is changing as we've talked about previously.
Egyptian companies are starting to realize that we need more product managers because now the focus is on the product as we've discussed previously.
So a one-liner.
So pre-AI, teams were built around capacity, how much we can build.
The AI era, teams are built around judgment.
What should we build?
And is it right or not?
That is why the ratios have changed.
Now, maybe in the US, I don't know about Europe, but companies were overstaffed.
They took AI as an excuse.
They started laying off thousands of people.
They're using AI as an excuse, but it's not really the AI.
It's just economics.
We have layoffs in Egypt, too, but it's because of the economics, not the AI.
Again, AI is being used as an excuse.
But for the companies that were doing economics well, they're actually hiring more people now.
Wow.
You said a couple of times this is based on data.
Can you help us understand the shape of that data?
Now, we have an organization that is part of the Ministry of Teleco.
called Etida.
They do a publication once every month and that data is because let me tell you something.
Egypt is a resource hub.
So people from all around the world, they come to Egypt to hire good quality developers at an acceptable cost.
So it's very important to publish data regarding the labor, the resources.
So this is one resource that I use as a reference.
And also I like using Claude to go around, collect data from recruitment websites and tell me the trends.
So how many people have put developer jobs versus QA jobs versus the AI is really good at that.
That was my guess.
It's like, is he going to like monster.com?
Like, is he looking at hiring boards?
Yeah, it's.
It's good, but you can't rely on it alone.
Official data in Egypt is reliable because if it's not reliable, people are going to say, forget Egypt, let's go to some other country.
Okay.
So I trust the official report.
Super interesting.
I meant we're, we've taken a lot of your time and we're sort of heading down towards the last few questions.
Thank you so much for spending time with us today.
You don't have to focus so much on professional, on software, on AI for these sort of answer with anything from your life.
If you think of something you've had to change your mind on, something that you always thought was one way and discovered, nope, it's a different way.
Something that was unintuitive at first, what comes to mind for you?
We've talked about it previously, and that was ensemble programming.
Now, I love pair programming.
I never thought it was annoying in any way.
I've always loved it.
But to be honest, ensemble programming to me was a little bit exhaustive.
I did use it in many occasions, but I never liked it.
But to be honest, thinking about the times where we did more programming, I think that...
we couldn't have gotten things done without it.
Yeah.
That is one thing.
I'm now starting to appreciate it more in the AI era, okay, because of the cognitive capacity thing we talked about previously.
So, yeah, ensemble programming.
And again, this is just me.
I'm not saying it's bad.
It's actually good.
But I never really appreciated it.
It was a little bit exhausting for me.
But now I think we should be doing more of that.
It should be the norm.
Nice.
What's something you're most proud of?
I would say Tech Cafe and my work in Arabic NLP.
Yeah.
Yeah, we mentioned that earlier.
That's Arabic NLP for LLMs.
That sounds really cool.
I definitely want to watch the space.
Do you want to talk a little bit about what you're doing now?
Sure.
Okay.
So Arabic is what we call a low-resource language.
Okay.
So English is always ahead for a lot of reasons.
And Arabic is always behind.
So you've got lots of countries speaking Arabic.
And Arabic is a very rich language.
When you come to know about it more, it's a very, very rich language.
And you talked about sovereignty at the beginning of the show.
The only way Arab countries are going to achieve AI sovereignty is by trying to bridge the gap between whatever that is being done in English and whatever we are in Arabic.
So that is why when you asked me what I'm proud of, I think that me and other researchers are trying to work really hard to bridge that gap.
And we're reaching some really good results.
This is going to...
make it a lot better.
I mean, if you work with a country like Saudi Arabia, everything there is in Arabic.
The documentation, the exchanges, the communication.
Unlike Egypt, maybe, you know, in Egypt, we chat using something we call Franco-Arab.
So we're basically writing Arab, but using English alphabet.
We write emails in English.
We don't write emails in Arabic.
Everything else around us is happening in Arabic.
I mean, when you are doing something, you're finishing a paper like driver's license or whatever.
All of this is in Arabic.
So when you're doing digital transformation, Arabic is there.
And now that we want AI to be part of this digital transformation, we need Arabic AI.
And so contributing to that, I think, is something that is really important.
Awesome.
One more question.
What's something that's giving you joy right now?
Ah, the other day I had Nick Tune, okay?
And he told me that Eric Evans, the guy who invented domain-driven design, during the .NET bubble, he was like the careful guy.
Oh, no, wait, don't get into this.
You know, the careful guy.
Now he's all into AI.
He's like, guys, I didn't enjoy the .net, .com.
I'm sorry.
I'm saying .net.
Okay.
Sorry.
.com.
Oh, you mean economically then?
It's funny.
When you said .net bubble, I thought, oh, yeah, there was a time when .net was stealing all the ruby.
No, no, no.
It's .com.
.com.
Yeah.
Okay.
Got it.
Okay.
So at that time.
So he's saying invest.
not just invest, enjoy.
Yeah.
I think that, so before AI, it was DevOps and I really enjoyed the DevOps transformation.
And now we are enjoying this AI transformation as well.
Okay.
We're living, as you've said, in very interesting times and we need to take it all in and enjoy it.
Okay.
There's no need to be very skeptical and pessimistic and careful.
Okay, yeah, you have to be a little bit careful, but enjoy it.
Yeah, I'm enjoying everything that is happening right now.
It's an interesting time to live in.
Awesome.
In software development, everything else.
Yeah.
100%.
Thank you so much.
Appreciate you, Ahmed.
I enjoyed it a lot.
Thanks a lot, Kai.