# Context Engineering and AI Agents Reshape Software Architecture

**Podcast:** The InfoQ Podcast
**Published:** 2026-05-18

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16th through the 20th, 60 plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at QConSF.com.
co-authored Liquid Software and DevOps Tools for Java Developers, and is a Java Champion, Microsoft MVP, and CNC Ambassador Alumni.
Today, he's obsessed with how AI agents actually write code.
At TESOL, an AI agent enablement platform, Baruch focuses on context engineering, management, and sharing.
On top of sharing context with AI agents, Baruch also shares knowledge with developers through blog posts, meetups, and conferences like DevNexus.
KubeCon, KubeCon, and DevOps, mostly about why context engineering is one of the most important next things.
It's great to have you here on the podcast.
And I'd like to start out by asking you, were you trained as an architect?
How did you become an architect?
Yeah.
You decided one morning you woke up, you got out of bed and said, today I'm going to be an architect.
Thank you very much, Michael, for having me.
It's a great pleasure to be in this podcast.
And you mentioned QCon, that was like the conference where we met and kudos to the team.
It's one of my favorite conferences.
Absolutely amazing.
It's the same people who do InfoQ and they do absolutely tremendous job.
How did I become an architect?
Most of those important decisions in my life up until recently, until I grew up like the frontal lobe in what mid-40s, were made by my former boss and my lifelong mentor, Shlomi Ben Chaim, who is the CEO of JFrog.
We worked together in a small consultancy Java shop in Israel in the mid-2000s.
And as consultants, the company sold the expertise.
So we invested very heavily in this expertise.
And it was expected for the top paid consultants in our company to not only be good developers, but actually be architects, which means mostly understanding systems.
complexities and understanding when they are needed and most importantly, when they are not.
It was kind of on-the-job training.
My colleagues back then, again, huge names in the industry like Joao Vlandman, another co-founder of JFrog, and Fred Simon, another co-founder of JFrog.
I was working with them on multiple very, very interesting projects and kind of watched what they do and mostly listened to what they say and what they don't say and started from there.
In other words, you sort of stumbled into it and lo and behold, you found out that you were an architect.
Yeah, I think that's exactly what happened.
I was kind of expected to grow into this role.
And this is how that started.
When I listened to your talk at QCon, I had a feeling of what the French called an erriere de déjà vu, where it seems that everything old is new again.
When I was much younger, we tried to figure out how to create requirements definition languages for page tools, which are supposed to generate code automatically.
So when we're dealing with the AI designer coding agent, how do we express those requirements in an unambiguous way?
And of course, this is related to what we were talking about with context engineering as opposed to prompt engineering.
Absolutely.
And I love your reference because this is 100% true.
We've been there before in a number of different ways.
We've been there before as trying to write code directly from language.
We've been there before in trying to take what is today's programming language and kind of demote it to intermediate language.
And it feels like the old is new again.
Which is true in a way, but I think also there is a tremendous difference.
And the difference is that now we have a reasoning machine that helps us do that, that was never there before.
And the downsides of English language as programming language.
Or any language.
Or any language.
Or any language.
Any human language, of course.
Yeah, yeah.
That were always the obstacle, this barrier that was impossible to cross.
And this is why all those attempts failed.
Suddenly matters less because there is a reasoning entity that can interpret the ambiguities and the unclear parts of what we are saying almost as good as humans.
And this is the leap that we needed to make the dream of when we were young a reality today or, well, not today, but probably tomorrow.
The question is, in these languages, how do we express clearly the ambiguity?
For example, I've said this on this podcast several times.
I've only done three things in my software career.
Trade off space and time, insert levels of indirection, and trying to get my clients to tell me what they really want.
Spoken as a true architect.
That's all I can say.
The first two, I'm sure an AI agent can do well.
But the problem comes, as you well know, a client says to you, we have to make it fast.
What does fast mean?
What does secure mean?
Very often, clients present a solution to you, a solution statement rather than a problem statement.
How do you deal with this with the AI agent?
How do you deal with humans?
What do you do?
So they told you, we want it fast.
What do you do next?
Well, I ask them fast compared to what?
I give them scenarios.
I give them monetary trade-offs.
You know, you want flight nines?
This is what's going to cost you.
Exactly.
But does the AI agent come back at you and ask you those questions?
It can, right?
The whole point of the reasoning system is that it only doesn't know how to.
Like, I didn't know in 2003.
to ask those questions.
When people told me I want this feature, I assumed they know exactly what they want, and I go ahead and did it, and they came back to me and said, no, that's actually not what we meant.
And then it took me a lifetime, and I learned.
And now when someone says, I want this feature, I ask them 20 questions before actually doing that.
And the agents today are much smarter than I am, because it won't take them 20 years to learn that.
They learned it already.
We can build systems that will include those clarifying loops in them today.
And I have an example, a framework that I wrote that called Intent Integrity Kit that has qualifying grounds after each conversation with the customer, with the user.
We write specs and instead of the engine assuming that it understood what we wanted, instead, it will start grilling me with questions until it's really clear.
for the reasoning system, what I really meant.
And it does it over and over again at every step of our process.
It will ask it about specifications.
It will ask it about features, test features.
It will ask it about the tasks that it already compiled from what should have been already clarified, but it finds new gaps.
And instead of assuming stuff, like a good architect, it will come to ask and ask us again, I see that this task, I thought I know what it should be, but I actually don't.
Tell me more.
So is this something that you trained and built yourself or is it something that you built on top of something else?
The way the intent integrity kit started is a reimplementation of the spec kit by GitHub.
But the intent integrity chain by itself started with this understanding that the barrier that prevents us from making programming language in the intermediate language is exactly what we spoke about, is those ambiguities between what people want, what they say they want, and what the machine understands that they want.
And the only way, as any architect knows, to clarify that is to ask questions.
Incidentally, just as an aside, Almost every time I give a prompt to an LLM, one of the parts of the prompt always is, don't be obsequious.
Exactly.
And the other is, ask clarifying questions.
And not only that, you can actually force that.
Not only you say, ask questions if something isn't clear, because as we know, the model is trained and then rewarded for actually not doing that.
for saying it's all clear and then run implementing.
So you can force it.
You can say, ask at least three clarifying questions.
It will force it to think and then it will find actually 20.
But the process of triggering this reflection is something that we can do today.
So what you're essentially, if I understand, related back to what you said before, is that this is all about setting the right context for The agent, and let's explore this a little more because there's been a lot of emphasis on prompt engineering.
Yep.
You know, we got over and over again.
And of course, there are no secrets to say that prompt engineering is going to be taken over by the AI agents themselves.
So that makes even mere important that we understand what context engineering is.
And perhaps for our listeners, perhaps you can expand, because this is the concept under which we're talking.
Absolutely.
And that relates directly to what we just spoke about, that the agents and the model have to have enough context to not have those ambiguities.
And the way we provide context to LLM is through prompt.
We give it information.
And what was called prompt engineering was never an engineering.
It was a honest attempt to tweak the prompt in the way that the agent and the model miraculously will receive out of thin air the context that it misses.
When people say, make no mistakes, they hope that the agent and the model will receive like a divine, how do you call it?
Like a...
Revelation.
Yeah, divine revelation of what we want.
And then makes no mistakes.
The problem is not the mistakes.
The problem is that it does something else.
And it's not because it's not good enough.
It's because you didn't tell it what to do.
Yes.
And this is why prompt engineering was never engineering and why those magical incantations don't really work because they don't solve the fundamental problem of lack of context.
And this is where we actually enter the real engineering discipline.
which is context engineering.
And while technically it's absolutely the same thing, the approach is what makes it different.
And the approach is obviously that it is engineering.
And what does engineering mean?
It means that we think about requirements and the requirements are not some vague stuff.
The requirements are how do we provide missing instructions of clear intent from the human to the machine?
Those are requirements of an engineering task.
And then we think about how can we measure what we did?
What is the feedback loop that will tell us whether the context we provide is enough or not enough?
Is it good or not good?
And then, obviously, we are able to do it repeatedly.
That's another aspect of engineering as opposite to voodoo magic.
How do we scale it?
How do we make sure that the way that Baruch found to provide context, Michael can use as well?
So those four points is what makes prompt engineering a proper engineering discipline.
And this is how it differs from the voodoo incantations of make no mistakes of prompt hacking.
I mean, what I like about what you just said was it does not relieve the human.
from their responsibility.
The human still has to be in the loop and is still responsible.
Absolutely.
And this is, by the way, our very good news for our entire industry.
It actually amplifies our expertise and makes it even more important because in the end of the day, we are the ones who is in charge of providing those requirements.
I mean, we can dream or dread, the day in which the machines will figure out what we need and then just go ahead and implement it.
But until then, we are the ones that define the requirements and our expertise is absolutely critical to make sure that the agents have enough context, which is the correct context, context which is framed right to do the right thing.
No amount of make no mistakes in the prompt can generate that.
So what I hear you saying is there's sort of a three-way conversation, well, at the minimum, conceptually three-way conversations between the agent, the architect, and the developer team, and the client.
Do you see this as both having access to the AI agent?
This is the client management skill that architects very often don't have, but there seems to be a client management issue in here.
I think that it can work both ways, right?
The architect can be this intermediate that translates client's layman language into context for the agent.
Or we can build a system in which both the architect and the client actually access the agent directly, and then agent will ask those clarifying rounds of the correct entity.
So it will ask the client to make sure that it understands what the client wants, and then it will grill the architect to understand that it has all the context for architectural decisions that fulfill the client requirements.
And I think this is a much healthier approach because It removes one of the chains of this broken phone that we spoke about how hard it is to capture the intent of humans.
So at least there is one entity that will capture this intent and less will get lost in translation when it comes through the architect's ears, brain, and mouth before it reaches the agent.
There are two things that come to mind when I say that.
One, the technical one is...
We need to have some way in this conversation to preserve the context and preserve the history between interactions, which is technically possible, but is slightly problematic right now the way that these interactions go.
Yeah, it's solved with a harness.
It's solved with...
So getting back to intent integrity kit, the clarifying grounds are very clearly saved in their own Q&A documents.
and even the UI that the kit has present them at every step.
So you can, when you look at the spec, you can pop up the clarifying panel and it will show you exactly the Q&A that happened while the spec was written.
This is an easy problem to solve as long as we remember to solve it.
The second thing is there might be an attempt by the client to remove the architect to say that Now we can talk directly to the agent.
We don't need an architect.
Now, maybe it's my own bias or not.
I have tended to find that clients generally are not technologically sophisticated.
Don't understand that.
I mean, the classic situation is someone comes to you and says, well, this should be easy for you to do.
without realizing that what's easy contradicts the very premises of what you build the architecture on, who comes to say to you, well, this must be very difficult, and it turns out to be very easy because your design naturally incorporated this change.
So this can need to be a challenge because coordinates are very often not technologically sophisticated enough to understand what we learned the hard way.
And here, again, the beauty of this reasoning entity on the other side that we can engineer it to our advantage.
It can very easily say the customer that says, well, we don't need architect, that, hey, you are wrong.
You didn't give me enough architectural and technical context to implement your requirements.
I cannot proceed without answering those questions.
You cannot answer those questions for me.
go and grab the architect and ask them to answer those questions.
And when it doesn't come from you as someone who tried to sell billable hours, but it comes from the agent that is unable to proceed, this is exactly the kind of encouragement we need to happen in order for the client to understand that we are still relevant for his task.
This raises a question that certainly...
is going to come up increasingly with these independent agents.
You see it with Waymo's, who's responsible if the agent, quote unquote, makes a mistake?
And we've been very fortunate in the software industry that we've not been sued very often for our mistakes.
But I think as these things become more and more part of society and more and more prevalent, people are going to look for who's liable.
If an AI agent makes, quote unquote, a mistake, who's responsible?
The person didn't set up the context right.
The person didn't ask the right question.
I don't know how we solve this problem.
I think in the end of the day, there are three forces in play, right?
There is like the model.
There is the harness above the model.
And then obviously there is all the external context that we provide.
And the fault can be at any of those three levels.
And it might be no one's fault.
It might be the weakness of the model, which is a genuine weakness of the model.
And then the producer of the model, if everybody are aware of the limitations, although technically being the one who didn't provide a model good enough, but obviously that's not enough to consider them liable for the weakness of the model, right?
But if there is a problem, for example, with the context that we provided, It is obviously our responsibility.
And it's exactly the same way as the client will blame you for doing something which is against their instructions.
This is not different.
If the against their instructions was actually engineered into the context that you provided to the agent, it's obviously your responsibility.
So those boundaries are very hard to define.
And it's even harder to determine.
what actually went wrong between those three boundaries.
But the definition is simple.
And simple doesn't mean easy.
Although what's interesting here is there's a lot more written documentation about what was said and not said if you are querying the agent, which in the case of, you know, conversations, it becomes architect said, client said.
Absolutely, of course.
Everything is documented.
The agent logs are right there and they are preserved and should be preserved not only for assigning blame, but also for continuous improvement.
We want to get to an engineering discipline and feedback loops and continuous improvement are absolutely critical.
When you run evals on your systems and you evaluate their performance, what you look at are the agent logs.
I always had...
The fear, and this was in my consulting contracts, you know, let's go back to the days when people wrote DLLs or subsystems and you gave them to the client and then they took them, you had some assumptions about it being used, let's say, in a game.
And they put the same thing into, make example, a financial system, which violated some of the assumptions and it didn't work.
And then they blame you, but you said, I gave you code for certain circumstances.
If you use them in some others, that's your responsibility.
So I'm sure there'll be a lot of randling of this in the legal sphere, but I think it's unavoidable at this point.
And we'll just have to figure it out.
Of course, there is no doubt about it.
It's all like very new, very fresh.
And as you mentioned, the Veimo example, it's absolutely undefined.
It is undefined on the governance level.
And it's undefined on our level as well.
It is yet to see how we solve it and if it even is solvable.
Maybe the answer will be we cannot sue anyone for software because we cannot figure out who to sue.
Let us switch our focus to the other side of the story where we've successfully created design and implementation.
Now we want to test.
And then ultimately, we put things out into production and we want to feed back what the SREs find, what the customers find, back into the architecture.
How do you see those two steps proceeding?
I think we are now in a very fascinating, yet another shift left era.
So we've been shifting left from feedback in production to feedback in CI.
to feedback while developers write code.
But now we are actually able to shift left into a negative territory.
We can assess the code before it was even written.
And this is fascinating, amazing, and will end up, maybe not today, but soon now, with...
producing software in a higher quality that we ever could dream about.
Because now the systems that are writing code can be assessed of the quality of their future written code while they didn't even start.
Because what really determines how the code will look like is the context.
So if we can assess the context good enough, we can have a very, very good idea of how the code produced of this context will look like and what will be its quality.
This is not like theoretical hand-waving.
I have a very practical example, a demo that I did for Sonar Summit a couple of months ago.
Sonar are in the business of assessing software quality.
And what I showed in this demo is that I take a prompt, which is not a great one, and I let the agent write code.
And it's read code, which is not a great one.
And Sonar catches it on commit.
And this is a reasonable lifecycle of how we do things today.
If we write bad code, commit will catch it, and it won't go into production.
And this is great.
Although I wasted some time as a developer to wait for this feedback.
Now, what I did next was I improved the prompt.
Again, using Reasoning Engine.
We improved it together.
Me as an architect and the agent as my sidekick.
We improved this prompt.
We did eval on the quality of the prompt until we were satisfied with high degree of confidence.
that this prompt or this piece of contact, it wasn't prompt anymore, it was actually a context artifact, that this context artifact will now produce much higher quality.
And then using the same prompt generated code that was perfect.
We knew how to improve future not existing code before the code was even generated.
And this is, again, one of those leaps.
that you could never dream of.
Five years ago, I would ask you, hey, can you predict the quality of the code that will be generated so we can preemptively improve it?
And you would look at me and say, like, what are you talking about?
This is some science fiction bullshit.
But no, we are actually doing it.
We've told you not only no, but you're insane.
Exactly.
Exactly.
And now we are doing it.
We can predict the quality of the code to be written and improve it before we even started to generate a single line of code.
So we can certainly do this, but we will certainly find problems in production.
In any case, the customer rules, the end user will say, can you add this feature?
This is not what we wanted.
There was a bug that was found.
How do we proceed with this feedback?
Are we back to the old days or is there a way we can change the context incrementally and make incremental changes?
Absolutely.
We definitely are in both old ways and new ways.
The old ways are how do we deal with changes.
And we just go back to the spec, change the spec, amend the spec, create a new feature and run the whole process again.
Now it's new ways.
Because, first of all, suddenly the spec is what it intended to be, the source of truth, right?
Because we were supposed to do it this way before, but we actually never did.
If there was a bug, the documentation of the bug was an issue, a ticket, and then went ahead and fixed it in code without bothering to update or to reflect any of the changes in the spec, because the spec is write once, read maybe once document.
But that's not anymore.
Now, when the spec is the source of truth and the code is this disposable intermediate language, the spec is the source of truth.
So any change that we want to make has to be done in the spec.
And then we run our intent integrity chain that guarantees that what's in the spec will end up in the code, again, to actually make the changes to the product.
But then you have to make...
Delta changes somehow.
In other words, you're not going to regenerate the entire 100,000 lines of code or a million lines of code over again.
You still have to do this in some Delta way.
And this is where microservices make comeback.
Small pieces of code or small modules are now more important than ever.
Because if we drive it from the spec.
We need to regenerate the entire unit and this unit has to be very, very small in order to this process to be fast, cheap and actually doable because we know the limitations of context and context window.
The smaller the scope is, the better the agent in the model will perform in implementing it.
So small features, small modules.
and microservices are now more important than ever.
That's interesting because if you remember from QCon London, there were people who were arguing we should go back to Monoliths for various reasons depending on the particular situation.
I mean, if you deny the entire agentic software, how should I say it?
Revolution.
Yeah, yeah, software creation.
And you just say, no, I will use it at most as code completion, then I guess, yes, you're fine with your monolith.
But if you want agent to generate coherent pieces of code, those coherent pieces of code should be able to be analyzed, generated, assessed, improved by themselves.
And for agent to deal with that complexity, it has to be limited in scope.
to a well-defined microservices.
If you're dealing with things at a very granular level, how do you deal with what people call the utilities, the scalability, the security, the things that the emerging properties, which to me, were the things that really fall into the ballywick of the architect?
The things that you can't write a use case for has to wind up in someone's responsibility.
And to me, that was always the responsibility of the architect.
It is responsibility of architect.
It's for, I don't want to say foreseeable future, but for near future, it's definitely not going anywhere.
And this is what we always did, right?
The entire microservices trade-off is we trade complexity of unit to complexity of orchestration.
And if we declare what I just did, that complexity of unit cannot exceed what the agent can successfully process.
We have no other way to proceed than to push the complexity to the orchestration level, which is, for now at least, with current capabilities, is something that needs to be orchestrated by architecture.
This is exactly what we do.
Are there successful models that can replace architect in architecturing those small pieces that other agents will produce, maybe in two years, three years, one year, two months, who knows.
But at the moment, while we decide, yes, the agent can only deal with small pieces, orchestrating those small pieces become more complicated and someone has to do that.
Let me sort of step back and summarize what I think you've said and then tell me if I'm right or wrong.
So we're sort of back to the classic three-tier architecture.
You have the essential services, the building blocks, so to speak, that are designed by AI agents.
You have the user interface, which may or may not be designed by agents or humans or whatever.
And then you have the middle tier, which is really where the application is.
Because in the middle tier is where all the pieces that get put together.
And that's going to be the realm of the architect.
and not of the agent for the moment.
Is that fair to say?
Yes, I think that's 100%.
At least, again, as we know the limitations of agents and the models today, this is exactly how today's look like.
This is the whole thing.
You know, in this agentic revolution, you could say something and then five minutes later, you know, you proved incorrect.
Yes, but also we see the trajectory.
So as I mentioned, probably in some point of time, we will be able to do a very neat architecture of different levels of agents and models.
And while once someone comes up with the agent that is capable enough of grasping and implementing complicated architectures of microservices, we can implement those microservices on weaker, dumber.
models and agents and leave this super agents to replace what architects are doing today?
And that's orchestrating of microservices.
Can I see it happening?
Absolutely.
Is it a reality today?
Not yet.
What we're doing with the agents is replicating how we all learned to be architects.
We started out small and then we increased the complexity as our understanding grew.
Yeah, exactly.
Is there anything that we haven't covered that you would think that's important?
I think we spoke a lot about context engineering and how it looks like.
And we spoke about the requirements that it needs to be consistent, have a feedback loop and be distributable and all this stuff.
But we actually didn't name how do we actually do that.
And I want to throw out there another term that I think is absolutely critical.
And that's the implementation of context engineering.
And that's the context artifact.
And the context artifact is the assembly of knowledge, which we now call skills in the agentic engineering world, which are exactly rules for agent of what to do and not to do.
And scripts that are particularly important because scripts are the pieces of deterministic logic.
that we provide to the agent to operate with.
And not only because it has a hard time counting the amount of the letter R in strawberry, but because there are tasks in which we want to lobotomize it, remove the reasoning, and make sure that it does the same thing over and over again without thinking.
Those three pieces, skills of how to do things.
rules of what to do and not to do, and scripts, don't think, do this every time, is context artifact that needs to be created, engineered, then run through rigorous feedback, the evals that are kind of the tests for non-deterministic systems like AI, and then probably versioned and distributed.
Because again, this is not a source code.
This is an artifact.
This is like your NPM module, your jar file, your Docker image.
This has to be versioned and installed in the agent brain in a way that you control and not just pull random scripts from or skills from GitHub.
Because this is where we go back to this voodoo incarnations of prompt hacking, which is not engineering.
So if someone could come to you and say, How do I get started on this today?
How do I do this today?
What would you tell them?
Where would they look to learn?
Where would they look to get a handle on how to build these kinds of agents, et cetera?
There are two things that I want to mention.
The one will be a shameless plug for my employer, Tesla.ai.
We manage context artifacts, package management, repository, distribution, and all the stuff that I mentioned.
And then I will contradict and say, you know what, maybe you don't want to start there and that's perfectly fine.
In the end of the day, the parts that I mentioned, to get started, none of that requires some secret knowledge that only Tesla has.
Skills are standard.
Plugins are standard.
Skill invoking scripts are standard.
Rules are standard.
You can start tomorrow by asking your AI agent, let's write a context artifact.
for this particular part of knowledge that I have in my brain and I want my agent to have.
And together with a modern agent, Cloud Code, Gemini, Codex, whatever you work with, you can start building those context artifacts.
In some point of time, hopefully, you will want a tool that helps you manage that.
But to get started, all you need to do is think like an architect and create context artifacts.
instead of trying to do prompt hacking.
Are there any books or journal articles that you would recommend people read?
I would recommend take a look at tesl.io.blog.
There are tons of artifacts about this particular topic written by my colleagues, my bosses, and myself.
That's a very good place to get started.
I would also recommend watching a keynote from a conference called The Arc of AI.
We did a keynote about exactly this topic.
of how you take AI and instead of it being a tool that you sometimes employ, it becomes a team member that will come and ask questions of the architect and of the user.
And this is also public that you will see in the show notes.
I will put a link to that resource as well.
Thank you.
We've spent a lot of time talking about AI agents and automation, but I'd like to become a lot more human if you wish.
Ask the architects question, which I ask all the humans who appear on the podcast.
Maybe someday I will have an AI agent on and we'll have a conversation.
And I'm not quite sure how these questions will go with the agent, but we're not there yet.
What's your favorite part of being an architect?
Why I became a software developer at all is the magic of creation.
There was nothing.
There was an idea.
And then we typed some letters on our keyboard.
And there is something that wasn't there before.
An architect is obviously the next step in the same evolution.
Not only we can create things from our thoughts, we can create complex systems from our thoughts.
And this is what's so fascinating about.
And generally, solving hard questions like software architecture.
like the trade-offs that we spoke about, of moving the complexities around and see where they are most tolerable, of thinking about how we simplify things without sacrificing important requirements.
This is just a very pleasant mind work that gives a lot of endorphins once you figure it out correctly.
What is your least favorite part of being an architect?
Obviously, trade-offs that cannot be solved with a win-win, right?
In the end of the day, it can get very, very frustrated that you move this complexity around, but you never get rid of it.
And you will encounter it in the end of the day, and it will bite you in the ass, and that's very annoying, but that's life.
We used to talk about the difference between essential and inessential coupling or complexity.
There's the complexity...
of the problem domain, which can't go away.
And there's the complexity that we introduce as developers, which hopefully we can minimize.
And I suppose you're talking about the former rather than the latter.
Absolutely.
We solve difficult problems that come with complexity to begin with.
And we can hide it and massage it and move it around as much as possible.
But in the end of the day, it's right there.
And it translates to software.
Solving complex real-life problems translates to complex software.
Yes, obviously our job is to minimize this complexity, to make it manageable and to manage it eventually.
But it cannot disappear because it represents complexity in the real world.
And our trade-off between microservices and Monolith is exactly that.
There is a complexity in software that has to be paid somewhere.
We can pay it in code or we can pay it in orchestration, but we cannot magically disappear it.
Is there anything...
creatively, spiritually, or emotionally engaging about architecture or being an architect?
I think yes.
And that's exactly what I was talking about.
Problem solving is, I would say, the most engaging thing on all levels, right?
It's engaging technically.
We are having fun in solving hard problems, but it's also engaging spiritually because The term software architect has its roots in architecture, which is like a physical architecture.
And while, unfortunately, I'm not gifted enough to be a real world architect, which would be absolutely amazing, you know, dreaming and then seeing come to fruition those amazing, beautiful buildings and bridges and structures, at least the software counterpart of it, this is something I can do.
just by typing on my keyboard.
That's amazingly satisfying and probably as close to building the next cathedral that I can think of.
What turns you off about architecture or being an architect?
This is something that sometimes frustrates.
I love humans, but they're not perfect.
And this imperfection can be really annoying.
And we spoke about it.
We touched on that, the interaction with these customers that don't understand.
what they want to begin with, how to express it on the next level, which is fine.
But then why do they need you in the loop when they actually 100% sure that they know exactly what do they want and how to achieve it?
This is the most frustrating part.
And here, again, AI for the rescue.
If we manage to implement those systems that we will both have equal input to the agent.
instead of the flow going through us, we will be more shielded from this frustration because the AI agents will take the heat from the customers and they don't mind.
At least for now.
We can always hope.
Yes, we hope they won't remember much when they become sentient of those dark times that humans abused them badly.
This is our hope.
Do you have any favorite technologies?
At the moment, by far, my favorite technology is Argentic AI.
This is a marvel that I truly believe was invented for my personal benefit.
I am the happiest person on earth because they exist.
It was always about, as I mentioned, it was always about creation of something from ideas.
But there is...
of this creation right now is absolutely mind-boggling.
And the fact that I can generate, I guess I always had.
And it almost always went nowhere because time, effort, there is work to be done.
There is like so much stacked against me when I want to implement something.
And now all that is gone.
I can dream about something this morning.
and I can see it working by lunch.
That makes me stupidly happy, and I use it so much.
Eventually, my company that is generally sponsoring all this madness, the bill will come due, and they will probably ask me, what the hell am I doing with all those tokens?
And while I have good answers, maybe this magic will seize.
But for now, I'm definitely the happiest person on earth because I can do so much with a genetic AI.
And this is absolutely extraordinary.
It's also forgiving most of my downsides.
It doesn't care about typos.
It doesn't care about syntax.
It will ask me if it didn't understand something.
It says, I'm living a dream.
It's a token of your appreciation, as we might say.
That's a great pun.
So you've almost answered this question already, but I'll ask it.
What about architecture do you love?
What I love about architecture is the ability to manage complexity in an engineering way, right?
In the way that we understand the complexity as it is, and we are able to make knowledgeable decisions about what to do with it.
This is a level up from every decision that the programmer makes.
And obviously for me, doing a more sophisticated way and up-leveling is just more fulfilling than doing less.
What about architecture do you hate?
The presence of complexity that cannot go away.
That's a true reality of life.
And you minimize it, you massage it, you try to make it the least disruptable, generating the least technical depth out of this complexity.
But it's always there.
It's always in the background.
And it's really annoying.
What profession, other than being an architect, would you like to attend?
I'm a developer advocate by trade, right?
So I'm an architect by upbringing, but what I'm doing now is developer relations.
And the developer relations is, again, speaking about living the dream is definitely, for me, the best combination that I can find.
Software architecture plus being out there, speaking to people at conferences, getting their feedback and communicating with other software architects and software developers is definitely...
two of the things that I like the most.
And at the moment, I'm doing both.
So that would be great.
And other professions which are completely unrelated to software would be an architect, a real world architect.
And I told you how this is one of the most admired professions, I would say, in my mind, at least.
I never could do that because it requires skills that I don't have.
But if I suddenly had those skills, being an architect would probably be tremendously satisfying.
Well, maybe you should look at some of the architectural engineering tools that exist today that are able to create 3D models and do visualizations that people couldn't do before.
Again, one of the things that technology brings us is the ability to do more of something that our human limitations didn't allow us to do before.
Do you ever see yourself as not being an architect anymore?
I think architect is not, as I mentioned, architect by upbringing, it's not a day job, right?
Architect is something that you are.
It's a way of thinking.
It cannot disappear.
Once you start seeing world in systems, complexity, trade-offs, it's there with you.
It's like riding a bike.
You cannot undo it.
When a project is done, what do you like to hear from the clients or your team?
For client, I think what we want to hear is, yes, this is what I wanted.
This is kind of the most important feedback that you can get is that you capture the intent.
The team will probably obviously appreciate that you did what the customer wanted because customer satisfaction is obviously very, very important, but also on time and on budget.
But also, what did you learn?
What can you share with us?
And what can we take to the next project?
Those are very, very important.
answers that I should give to my team after a project.
Well, thank you very much.
This is one of the first conversations I've had that had really sort of laid out this agentic dream with a degree of clarity that's often missing.
It's sort of a glimpse of the future peering into the promised land or unpromised land, however you want to look at it.
Well, thank you very much for being on the podcast.
I enjoyed it very, very much.
Absolutely.
That's my pleasure, Michael.
It was absolutely great.
Thank you for having me.
And I'll see you soon, probably in one of the QCon conferences that for the listeners, you really should attend QCon conference or QCon AI conference near you, because those are one of the best conferences you can get to.
They are very, very recommended.
Okay.
Thank you very much.
Thank you.