How to Think About Software Engineering (CTO's Perspective)

We are in a unique point in time where people have an opinion on people's personal productivity. When it comes to software engineers, they have quite a valuable skill set and there's no alternative. Now there is an alternative. It works now because you have senior developers, they lift the pain of developing. They know object, object orientated programming, they know functional programming.

Now if you Fast forward to 20 years and we freeze in technology and you do exactly the same, the person driving that large language model doesn't understand the lower level concepts of object orientated programming because he never had to do that in the past. Are you a programmer who writes code or are you a software engineer that you design software architectures and that you write applications? You are the author of the application. You're only using a tool to

build it for you. Joining me today is my friend and colleague Joris Konang, AWSCTO over here at CBR and we talk about automation, agentic workflows and the impact on the software development life cycle. Really fun conversation and it'll definitely make you think. So enjoy.

I looked at your LinkedIn and you've done a lot. I saw sys admin, I saw software engineer, cloud engineer, trainer, and now CTO. I'm wondering what nowadays still gives you energy that might be different from how it used to be. Still the same things. Yeah, yeah, yeah. So next to be the CTO, I'm still doing consultancy work. So I'm still engaged with, with

an engagement at a client. And then when you have that particular heart problem that you're actually trying to solve, and the moment when you actually solve it, that that moment, that spark is like, yes. And it doesn't matter what that problem is. Well, the bigger the problem, the bigger it impacted, the nicer the yes is. But. Yeah. And then does it matter if they are long term problems that you solve bit by bit or they're more the shorter kind of instant

satisfactory ones? Well, it could be both. Yeah, yeah. That's nice. But it needs to be stay fun, right? You need to enjoy your work. You need to go back to your work and say, yes, I'm excited to go and I feel like it and I want to make a difference. If you do that, then you're in the right job. How do you keep it fun? Well, you have to make it fun. So also within CBO, we also shape our own assignments sometimes and that's gives you the opportunity to make it fun for yourself.

So of course you can go to a client and ask them their problems and then let them drive the assignment that you they want you to be doing. But if you as a consultant say hey, but I think I will excel in this area, can I help you with that, then you're shaping it more towards you to make sure it's fun for you as a person. Do you have an example of that? Something that you came in to solve and then turned out there was a different problem that needed solving.

You actually fixed that. Well, if you, if you talk a little bit earlier about when landing zones were hot and happening, I would say there the governance. Well, I, I don't really like governance, but I do like security. And I do know that it's, it's goes hand in hand. So it, it's, it is important to have that together with each other. But I really like figuring security challenges. Don't be the department of no, but make sure that you say no,

you cannot do this this way. But let me help you figure out a way how I, how you can do this. And in in that sense, I was more or less like, OK, put me in that position where I can not block people, but actually help them unlock themselves and then see what the impact on the organization is.

That's nice. Yeah, I got a new kind of viewpoint on things like risk, privacy, security specifically, and it was mainly because I was talking to a person that's quite senior at Databricks. They also worked at Google and they said it's like you're engineering but at a different level, on a higher level because the margin for error is a lot smaller, right? If you're at risk security wise, then when something big actually hits, then could be detrimental.

So you have to make sure you got all your bases covered. Same with risk, right? If you get sued, you're kind of screwed. So if you're responsible as an engineer, you're playing on a different level. It's like you're playing Champions League instead of like smaller league. Definitely, yeah. And with security, it's also fun, but I've never been responsible for I think those bigger topics.

I do feel like when things are quite risky, those topics go to the people that the organization trusts the most to actually make sure that this works well. Yeah. And more and more people are involved making that decision and they're, it becomes slow and bureaucratic and nobody wants to bear the the risk of going wrong. And then they postpone. And then you get the typical enterprise behaviour that you would see in organisations.

Yeah. Yeah. Have you found yourself in a position like that and how do you handle that? Well, usually finding the person who is responsible in the end and just confront him with what the well, what the the downside is of not tackling this is for

instance, you can deny people from using AI because you're afraid for the risk what it brings. So you don't allow AI within your company. But what people will then do is they will use ChatGPT on their personal accounts for a free version and they will use it where it was intended for. And you can upload excel sheets there as well. And then you're then you have a bigger risk of losing data into places that you don't want your data to be be app. Yeah, I've seen two types of

people. Then the people that really try and prevent that from happening, people going shadow IT personal stuff or people that then say indeed, let's fix this because this is an ask, so let's make sure it's in a mature way and we can actually accommodate. People will find a way, Yeah, right. So and either it's through the way that you pay for them or you they will find a way that works

for them. It's interesting because I, I only know this industry, which is the tech industry, but I do feel like the engineers are quite influential, right?

Within a product team, A-Team can just say we're not going to work on this feature. I believe we should not work on this feature. We need to work on tech depth for at least two weeks. And then a product person can be like, oh, what am I like, what can I do? My engineers are not going to work. They're like, and on a strike, it's like a mini strike.

Sometimes they can even hold an organization completely, like in a in a stranglehold when they say I want to work with this certain technology, even though it might not be the best for the organization, but there's quite some power in there, which I think is fascinating. Yeah. The interesting thing with those kind of things, especially if you're trying out new things, is, well, I think the fundament below that is already wrong if you're in a situation like that.

Because in the end, it's a lack of trust there already. Because typically when that happens, you say to your developers like, no, you have to work on this feature, that feature, and no, we don't have time for technical debt. And you just make it happen. And then at one point your developers will go on a strike because. It's too much. It's too much and they're postponing and postponing and postponing.

That's why I always say you should embed the technical depth that you want to solve into the features that you're developing. So for instance, if you want to change the logo, but you need to, well, you know that it touches some areas, where is some technical depth, then you say, yes, we can change that logo, but first we need to fix this. And if we fix this, then I can change your logo more efficiently and that will help the team grow and excel in their

job. Yeah, I think it's fun to zoom in on that because the trend that I've seen now, especially with agentic tooling, is that people all of a sudden have a tool that will magically fix this for you.

You want to change the logo? I can do that. So when you as an engineer say it's going to take me a couple days because I'm, we're going to work on the stick there, someone else might say, well, why, right? Because I can do this with a snap of my fingertips basically. And it's fixed. Which all of a sudden now people have an opinion on how engineers solve problems and they really want the problems to be solved with agentic tooling, which has

pros. I love it from a usage perspective, but it can also definitely have cons. Yeah. I would say in the end, as a developer, you're responsible for the work that you do for the product that you're delivering, regardless on how you built the software. Either you do that through a terminal with FI or you do that with the nice and shiny Kieros or cursors or cloud code, for instance. It's, it's still tools. So whatever the tool produced, you're responsible for that as a developer.

So yes, you can change the logo, but you have no idea what else it does and what kind of impact it has on the rest of the the application that you do potentially. And that becomes a very interesting dialogue then, because yes, you can change this. And of course we can do that over and over and over again. But that will cascade into a world where you no longer understand your code base. You don't understand what the implications are of changing this one property.

For instance, Yeah. And then it becomes troublesome I would say. Yeah, I, I think we're going to learn a lot and hopefully this year, because there's two trains of thoughts, right that I have either teams still have that

ownership, but they lose some form of instant, oh, I know this or I know that and they have to rely on agentic exploration to actually figure things out. And there are pros, pros and cons there. Or they go a little bit slower, a little bit more, I think consciously trying to understand their code base. And they might still very much be hands on, not fully reliant on agentic tooling. And I think they have pros and cons. It's quite interesting how things are going to accelerate

and evolve. I see some people are all on the bandwagon that say, OK, does not make sense to write code by hand anymore already, like not even in the future, but already, yeah, yeah, yeah. And I think that's quite interesting. It's interesting, but also, well, a risk I would say, because why does that work nowadays? I would say it works now because you have senior developers, but actually know they, they lift

the pain of developing. They know object, object orientated programming, they know functional programming. They know what the changes are. So if a large language model proposes some changes to the code base, they understand it. Now if you Fast forward to 20 years and we freeze in technology and you do exactly the same, the person driving that large language model doesn't understand the lower level concepts of object orientated programming because he never had to do that in the past.

So how can that person make an objective choice whether that is a good or a bad chance in the context of the code base, which you probably don't know because the majority is generated anyway. Yeah, this is where like the lines of code is, is kind of a challenge, right? Because if I pick up a new programming language, I don't do that often. And now I don't think it makes

sense anymore because I can orchestrate in a specification feature wise what I think we should do. And I can look at the architecture flow and be like, OK, this is the entry point for an API. This is where it goes in the database. Oh, it actually is decoupled through an event at a queue there. So I can see that even though it's not a language I'm comfortable in, that's from a

readability perspective. If I don't know any of that, my assumption is that whatever gets generated you should try and understand. And I feel like, but this is a hunch, you can get quite far through pattern recognition where you can read a lot of code and if you don't understand you have to consciously make it a learning opportunity. If you don't do that, then you're lost. Then you're the same as the people that copy paste from

stack overflow. But I do feel like this can really accelerate your learning if you use it wisely. Yeah, definitely. And not only that, let's take it

one step further. So the question is, does it still matter that you fully understand the code that is being generated when you, I think that is important when you have in, in this hybrid situation where you have an existing code base written by humans and then you introduce an AI coding assistant, then it becomes very important that you actually know from each other what you're doing to, to have a good confidence that you're building the right thing.

Well, if you start with a Greenfield application, does it really matter that you really understand the full code base? Still, as long as all the specs are in the correct format and has the right requirements and and all those things are right, then a large language model is probably the better developer to actually implement that in such a way.

So what is the added value of a human in that that regard? Yeah, I think it's the the orchestration, right? Because this is this is treating it like a black box. We say on the edge, these are the requirements. We can have edge cases or we have all those edges actually also validated in integration tests, smoke tests, unit tests, all of that which we can read as another specification and be like, does this make sense? I know what happens in between.

You can actually kind of blindly trust it if you make sure that that process is in order. And we've, and we've done this in the past. So if you look at object orientated programming where you have a clause where you say, hey, I threw in an apple in this parameter and I expect a banana out of it, then you don't care how that happens within the

clause. Because if you do, then you're creating a test that actually understands the inner workings of the class, which you shouldn't do because then when you change the clause or you or you refactor it, then all your tests are broken. So in a way that is exactly what we're already learned to do from object orientated programming, but now we apply it more on a higher level, more on an

application level. So having good end to end test, having good integration tests and having the ability what, what kind of what kind of patterns really need to work well before we can say, hey, this application is actually working as intended. That becomes way more important now than ever. Yeah, it's interesting because just due to working in a lot of teams, I know that the logic is abstracted away and you test around and you don't change it because otherwise your test fail.

It's just comparing it to this situation. This situation is like on a next level scale, which is pretty cool to be honest, But it also brings opportunities. Like I've had recent conversations of technologies where we have quite heavy license fees in certain organizations with certain technologies and those companies might have quite a stranglehold on certain organizations, right. If you're all in on a certain technology and it's very hard to

migrate away. And yeah, you're kind of, if the vendor then says, well, the license fees are up 20% this year, just you have to deal with it basically you can't easily migrate, but maybe now you can, which is quite interesting, except then the ownership becomes quite a challenge, I would say. Yeah. If you move away and build something on your own using AI, then you need to own that as well.

It comes with responsibility of owning and hosting the the application, the security implications of that. So it is a little bit more than just saying, OK, let's build it ourselves. There is more to it. But if the license fee are high enough and you have a organization that can actually run these implications yourselves, then it becomes easier and easier to start doing that you. Have quite a business case on your hand? Yes, yeah, yeah.

I, I hope that we get some, some good examples of where that is a success and then also kind of learning from how they do that because right now I have a lot of assumptions and I can't wait to test those and validate those assumptions. But they're still assumptions. Like we're kind of on the on the front end of this, which is quite cool. I know you're a fan of automation in general. And for me, this is like automation, the automation on

the side of writing code. But if I look at the software development life cycle, anything from researching, planning, refining, actually building, reviewing, testing, running, deploying, documenting, for me that's kind of the whole life

cycle. There are a lot of aspects with the genetic tooling that we can now play around with automation and it's a scary amount to be honest. You might be able to do a whole lot there. What have you done so far? What? What have you experimented with that you'd like to share? Oh yeah. So actually ACBIA has a platform which is called Cbas, and that's actually doing that. So it's brings a holistic view to the software development life cycle, which is quite a cool tool.

So in essence, what it does, for instance, if you want to develop a new feature, usually it happens between two people having a conversation, maybe 3, maybe 4. Like we need to add this feature. What if you record that session that you have, usually on Teams, it will give you a transcribe. So how cool would it be if you can feed that transcription into a system and then extract all

the requirements from that? And then from the requirements, you can actually validate that with the right people. Are these the requirements that we've set and then use that as a process to guide it towards a software development life cycle? Because when you have the requirements, you can, well, a human used to create user stories out of that. Well, you can use AI for that. So having the requirements, you can generate your user stories. When you have user stories, you

need to plan that. So you can do Sprint planning. All that stuff can be automated. And to be honest, that's the most boring part of, of doing software development. So I really, I'm, I'm really pleased to see this development, especially in that area as well, that you can actually focus more on the creative side on having the discussion with each other.

What does the application needs to do and how do we ensure that it works for our business instead of doing administrative tasks like creating stories and that kind of stuff or writing Confluence pages? So. That really excites me at least. Yeah, it's, it's funny, I actually had a conversation in this morning actually prior to our recording. And there I shared that I know at Veed, which is this online video editing browser tool, they do a lot with regards to customer interviews.

And there they capture the transcript. It all goes on a drive. A lot of people within that team, all within product have to do 1 conversation like that weekly talking to end users. And they have this very rich

database in the end of transcripts, which are all interviews and discovery talks. And there they look for commonalities through AI and they look for patterns of features or problems or symptoms that they want to solve in their tooling. And I felt like that conversation that I had this morning was about developer experience. I am now in a position where I can do something similar. And I really want to experiment with that. But this is very interesting as

well. When you're talking to stakeholders or when you're aligning with your team, when you're doing refinement. I, I pride myself in being able to type fast. But yeah, I'm kind of out of it. We have to have a lot of sessions, a lot of back and forth, a lot of, didn't we actually discuss this already or

what was said again. And yeah, if you can capture all of that in transcript, it just makes sense that we can use that and then leverage that and go even beyond with regards to kind of refining and figuring out what to do. Yeah, not only that. So I don't know if you ever looked at the transcription and then looked at the meeting meeting report that's getting generated by an AI tool. Yeah, I want that as well. It's.

It fills in the blanks as well. So it's, I always see a large language model as a, a, a child that learned a lot of things along his way. And now you, you could think about it as a human being, a mind of a human being. But it's primed. Well, we, we have control over

how the mind was primed. So it has a way of thinking on its own a little bit based on the knowledge that it was trained on. So reading the transcription and then writing a meeting report out of that, it fills in blanks based on assumptions and those assumptions come from the way how it was trained. So if you do that with all the meeting reports automatically it fills in the blanks.

And then if you as a team review that that meeting report, you will actually see I didn't look looked at it from that angle. And especially when you generate requirements out of that, then it is an assumption of the model that you meant at the time when you in the context that you were discussing it. So either that is spot on or it's, yeah, maybe we need to add another requirement based on this answer.

So it also helps you develop and strengthen the requirements on its own as well, which I found very interesting as well. That is also a skill that people have. I've seen when people are having a dialogue.

I'm I'm new in an organization right now started in January. People are having a talk and I ask a question because they're like not addressing this part and I'm not sure if they know, but it needs to be explicit, right? Then I can have an equal level of dialogue, which is then interesting because that's what one of the people used as a word. When they actually answered me, they were like, yeah, we are working on the dis implicit knowledge that you don't have, so let's make it explicit.

I feel like that's a really cool skill to have that you figure out what this conversation is, where there are gaps, and then make those explicit. Those can be right. Well, they can be wrong, but if they're wrong, we have to change them. Yeah, indeed, I have a great example of that. What happens today when I was in a refinement session. So the the the obvious thing happened, we were working on too many epics at the same time. So and and we agreed upon not doing 3 epics at the same time a

long, long time ago. But somewhere it's. When it always happens. It always happens every every now and then. You need to remind yourself from that. So we sat down with the team and we said, look, the the column of the epics already has a maximum of three and if you have 4, it turns rat. So it's just a matter of looking at that board and seeing, hey, it's rat. We need to make a choice here

which one will go out. And then you get an interesting discussion because you can ask the product owner which one is important because we direct the 4th one in on your request. Which one of the other has to go has to go by making it explicit, you sync the whole team, you recalibrate all the priorities

because if somebody is sick that day or whatever, he doesn't get that context. But if the epic is actually moved into an on hold status or all the the stories got removed from the Sprint because any new important thing was added, then he will have. Questions, of course. If you leave it in, he will come back to work and he will start continue working on other things, on the things that he was working on. Yeah. So by making it this explicit, you actually sync with the team

a lot better as well. Yeah, I feel like it's, it's quite a mature approach. Yeah, in some teams I've been in, when something new pops up, it's just added work and nothing goes. And I'm like, well, that's not really healthy. Well, especially well as long as there is no downside at the end of the Sprint that you did not complete all the work. If you don't have that consequence in there, then it's easy to accept, okay, we will do that and we're all adults, right?

So we all understood if you add this to the Sprint, then we cannot deliver that. If you're in A-Team that works that way and you have a understanding product owner that also sees it that way and the share the stakeholders above that also understand that, then there's no problem. But if you look at why Agile was created, it's not for that.

It's for having control over the philosophy and making sure that you have all those those insights so that you can give a reliable planning towards the business. When will this feature ship? And that will not never happen if you work that way. So it's a control thing. That's how you see it. And I think that's quite interesting. Like I, I like working in agile teams, but I've never viewed it as a control thing.

Some people go above and beyond with regards to when is what done and how much is story point in days. And I'm like, it really defeats the purpose. In essence, when I was responsible for product, I kind of got, I took ownership of that and I was like, I want to work with story points and teams were like, well, do our people asking for deadlines and plans. I said no, we can throw away the story points in the end, I don't care.

I want to know that when someone says an 8 and someone says a three, I want that dialogue to happen. Yeah, I think that's very interesting. That's where the value is, yeah, for me. Do we have the same understanding of what this means? If you say 8 and I say 3, clearly there is something wrong. You're thinking of things that should be in there and I'm just neglecting the thing, the things that you're thinking of potentially. So that's what I wanted.

And then I said then we don't even need to capture the stories in the end. I do know that if we have a magnitude of eights, I'm only going to get one or two of them that are actually going to be finished. So it will help us from a planning perspective, but if it's in the way for you, I don't need that. I can read the story and figure out kind of how big it is myself. Technical background helps, but I want that dialogue to happen. That's the only reason.

And then teams were like, oh, no problem. This I can get on board with because they see the value there. Yeah, definitely. So I from an agile perspective, I'm yes, I'm kind of agreeing that agile is needed in this world to, to be a little bit successful in developing Solver. But on the other hand, having more trust in the group of people that are actually

developing also helps. And agile is, for my experience, what I've seen is it's not really helping the trust there, I would say because like you mentioned, if you do story, story points, philosophies and over X amount of sprints and then we know this is an T-shirt size L, which is roughly X amount of velocity, then we can ship this feature.

If it's used that way, then you're neglecting the fact that there is technical depth, that there are other things that can pop up. And that's why deadlines are usually not made. And if they're made, we did shortcuts adding on to the technical depth, which is no time for because the next big thing is already scheduled, of course. Is on the finish line.

Yes, well, if you, well, if you turn it around and make the developers responsible for the the road map as well and have to dive dialogue with the developers itself, they clearly understand what's needed to deliver those features by removing all the overhead of doing X amount of meetings and scrum meetings etcetera, you can also develop stuff in that area in that time. So I'm a bit in between, like

where is the balance? But the problem with the approach of the trust is without doing Scrum is, is that you need a hell of a team that is high quality and can trust each other completely. And if you have that. Everything's fine. Everything is fine. It's like the A-Team. Yeah, like 10X developers,

right. The team of 10X developers, you do, you just say these are the the the things that we need to deliver this year. And they will say, OK, let's do this feature before that feature because this has a lot of building blocks that the other feature can help for. And if we do it the other way around, they are specific to this feature and we cannot reuse it for that, for instance. That's the team I want to work in and operate in.

And I feel like the people that really want to kind of manage deadlines and manage expectations in that way, maybe they've been burned a little bit too much in the past because developer state, they do hold a lot of power, right? If I want to work with a specific agentic tool and it's not in the org, some people might be like, well, I'll just do that personally, or I might leave the organization.

Then you lose a really good person because you didn't enable them to do what they want to. It's a very interesting power dynamic. Oh, it's like I mentioned in the beginning, right? You need to go to work enjoying your time to be there. And if you're being, you're working in an organization that doesn't allow you to do that, at one point they will leave. Yeah, Yeah. I think that's in the end it's fair, right? Because that's also the relationship.

If I can be my best at work and I go Sprint after Sprint in no, in no other industry do we go Sprint after Sprint after Sprint. Like 50 sprints back-to-back. If I then don't enjoy what I'm doing and I'm still doing 50 sprints back-to-back, you're going to get burned out quite quickly. And I've seen different approaches on how you can do this right. You do X amount of feature sprints and then you do 1 technical depth Sprint for instance.

So there are a lot of ways on how you can how you can deal with this. But I think having the dialogue with your developers is the most important to to to solve this problem. Now hopefully AI will help us with solving all that technical depth. Yeah, let's see, let's. See, I want to get back into that because when I really worked well with the genetic tooling was when I focused on having really good

specifications. And those really good specifications came down from really good distilled user requirements. A vision of where we want to go, what we're going to do in order that makes sense, deliver value as fast as possible, then test assumptions and build on top of that rather than going for a moon shot.

In the end, I just had a lot of specs and I could run them in parallel and I built features that way. And I loved it to be honest. And then the outcomes of that, I reviewed it. I reviewed it again with the agent fresh context and then put up a pool request and people reviewed it. And from those review marks, I made skills to even do better pool requests. That whole life cycle was a lot of fun.

And if you're talking about going from a transcript from conversations with the business or from within the team and then creating user stories, an additional or and a step even beyond that would be to create the specifications for then an agent to pick that up. Yeah. So that's reality already within Cbas that is already being done.

So I just hinted on the first area of of the solution, but it goes all the way of running the application into production and writing the code can be done based on the specification. Like I mentioned, you get the requirements, you get the story, so you get the smaller tasks that need needed to be executed. Although an agent would go faster through the sprints and the stories as a as a human would be, but still the same

steps are being taken. And from that, you can generate a very rich spec that you can feed into these, these development tools to actually build the application as well. And so, so just curious, because you mentioned you did somewhat similar for yourself. How did you share that with the team that you were working on? Because usually what I see is, is that yes, developers are experimenting with AI. They're doing what is cool and, but it's very local orientated.

And if you're lucky, they're sharing it with the development team that they're working with, like help your your neighborly developer, but across that the team, there are multiple development teams in organizations. So how do you scale that up? That is an interesting. This is the. Challenge I'm trying to solve. Actually it's a new assignment, but back when I was doing hands on that was at a startup. So very much I came in to do kind of a one man army assignment and I got to do that.

I don't think we ever we, we like to share knowledge with regards to our IDE usage or how we manage kind of on the keyboard versus turn men all get commands and stuff like that. But it was never something that we shared. It's still very much personal productivity and I feel like this is again similar to personal productivity, except there is a lot more benefits in sharing that, right?

If I share with you that if I do command shift Y, my terminal opens, it's not as beneficial to you as it is to me because that's my heart. That's like finger muscle memory. That works for you. That works for me. But if I share with you that actually the value that I've seen in this life cycle, for me it was very much in how well I do the specification.

And I would actually go through the specification and they would ask the agent to change things and I would review it again until I really thought that if all of this is good, then I'm good. Then I could just execute it and work on the next specification. I was like working out specifications back-to-back. That's how I did it in the end. And I don't know if that's going to scale to a certain point.

I feel like it's going to be interesting to try and make that scale to also feel to also figure out where there is then code based drift versus what you have captured in specifications. But I do feel like we will solve those newer engineering problems. I know we can fly. Yeah. So relating to the the personal, how do you call it, productivity gains? So in the assignment that I currently working in, I also created an agent, but I actually stored it in the git repo.

I'm using Copilot there. So if you use the dot GitHub folder slash agent, you can actually store the agent there and you can actually use that on your code base. And what this agent particularly did was it had very specific instructions to, when you ask it to update the documentation, it will actually scan the, the, the code base that that it was living in and actually had some very specific instructions on

how to update the documentation. So you can just change your code base and then ask it to hey, update my documentation. And then all the documentation pages were reflecting based on the changes that you did. Having that checked into the repository actually helped the whole team to actually reuse that agent as well. But beyond that, how to scale that across organizations, that becomes a a bit more

challenging. And that's what I really liked about the a solution that we had it it's, it's, it's kind of forces you in a workflow kind of working, which is more organizational driven. It's a no code solution where you actually work with normal interaction with, with human language and you, you change specs and it gives out specs. But regardless of what project you're using, the, the, the base instructions, the system prompts are all the same for all the

teams. So if you change something there, it applies to all the teams from a scalability perspective. I found that very interesting and I'm curious how that will scale in larger organizations as well. Yeah. I've seen a conversation on, OK, are we going a multitude of agents or are we going with one general purpose agent and then a multitude of skills that it can apply. And I think that conversation is still ongoing.

But whatever it is, I feel like offering, if you're talking about multiple teams, an organization with 1000 engineers, so hundreds of engineering teams having something central that is kind of a baseline template with some general purpose things and some very specific things, I think is always valuable. And then if people take that and they say, well, our conventions are XY and Z and we make something very specific for our repository of use case, I think

that's phenomenal. I feel like that's the way it's heading. And I I don't know if I see any other alternatives other than kind of teams managing it themselves. I don't think it's sustainable

to let teams manage themselves because especially in bigger organizations, you have certain quality aspects that need to be met. Some, to be honest, some teams find it's not needed to scan, for instance, with Sonar Cube or Sneak or whatever kind of tool you have to do security scanning. And they found that one example

that I used to have. From my experience, if you use Sonar Cube to scan your code base and it says OK, this is not a Safeway of using it, then the first developer response that I've tended to see was yeah, but it cannot do any harm in this particular situation. Not in this case. Not in this case. OK, so there is a security hotspot now in this dashboard, it says 1, OK. And then the next thing pops up and then it says 2.

And then if you have a good secure security practice, you would actually review those hotspots. And then you would say, OK, it's safe to use here because of this reason. You do an annotation there. But if you review that regularly, or at least in a fixed cadence, could be 6 months, could be 3 months, could be once a year, but at least once a year, worst case scenario, I would say you would review this list and see, Oh yeah. Is it still OK to use this?

And you're spending with 2-3 people like 5 minutes debating. Oh, yeah. What was this about? Oh, yeah, yeah, yeah, yeah. It's still still valid. Still valid. So there was 1515 minutes. So. But the fix for that problem was probably like 2 minutes. Now if you do this on a regular basis, these reviews, then you're spending 5 minutes every time discussing it will cost you a lot of time in the end.

And that is just one issue. So I'm tend to be more of just use those tools, fix the fix the problems right away. If it's a fix of one minute, yeah, don't be that lazy that you don't want to do those kind of fixes so. The problems is they, they compound in a very interesting way, right? You can say, well, in this linear way that we have right now, this, this moment in time, it's fine, but things compound, knowledge gets lost, right?

I, I really try and put as much as I can in my commits, in my pull requests, in my descriptions, because that's for future me and for future colleagues that I will never get to meet. In the end, that's as much context as I can do right now for the future. And if you don't do that, then things will compound. We're not necessarily building a system.

Sometimes it's like an Organism and problems can just emerge because we have a few hotspots and all of a sudden they form a triangle and they mess with your system. Well, too bad, that's just how it goes. Definitely. So to come back to the point, so do you want to have your developers responsible for arranging all those work flows, some teams, maybe other teams,

maybe not. So from that perspective, you probably for the bigger organizations, you do want to have some control, some governance over how your developers are are working. And again, not as a department as no, but how can we actually use this technology to to help you excel in your business in a safe and secure manner.

Also from the cases that you didn't thought off of or don't have experience with. I feel like we are in a unique point in time where people have an opinion on people's personal productivity when it comes to software engineers. Before software engineers are scarce, they are highly intellectual people, they have quite a valuable skill set and there's no alternative. Now there is an alternative. It is the first I think ever to disagree that there is an

alternative. So people have opinions and I think it's very interesting because some people are not budging. They're like, this is a hype, this is a bubble, it's going to fade. Some people are kind of in the middle or they feel that this is definitely something they need to jump on. But there may be hesitant, there's maybe a lack of knowledge. They may, they might not get as much room working. And then you have the the

complete opposite. That is like all in that says if you do not use this, then you will become obsolete. There is no point in writing by hand anymore. Which I think is so fascinating. Never before have we had this. And then if that side wins, if the latter side wins, that says you have to do this, you cannot write by hand anymore. Then that. That might just be an organizational policy where the fact that you're writing by hand, even though you enjoy that, you should not do that in

the organization anymore. You should do that in hobby projects, get your fulfilment from that. But this is a business and this is a very interesting trend. Yeah. But again, that really depends on how you define a developer or a software engineer or a programmer. So I I saw somewhere on the Internet. In a podcast.

In a podcast or in a book, I don't know where I saw it, I saw something like are you a programmer who writes code or are you a software engineer that you design software architectures and that you write applications.

Writing application can also be that you define how the architecture works, that you review that. So the tools, how you built the software just changes. So I really need to find joy in the developments process of how you actually shape and build the application versus actually writing the lines of code and figuring out what a semi colon got lost and that you have a parse error.

So what is the thing that you gives you enjoy and hopefully for the majority of the software engineers, I would say it is in the designing part. Then your job is still safe because you still need to review the, you need to make up your requirements. You need to review the requirements, you need to review the architectural decisions from large language models. And of course they will get better and there will be less errors, but still, you are the

author of the application. You're only using a tool to build it for you. It's not let's take a different approach. It's would be the same as me as a manager asking hey this is how the application should work like right? Fully specced developers go build. That would be exactly.

The magical world. For me, for my, my, how I see the world, then whether I ask this from a developer to create or an enlarged language model to create and I the end result will probably be the same or even better with with an coding assistant. It's yeah, it's. What do you call it? It's. I think it's how you look at it in the you can do more I think

even now. So if you really enjoy the problem solving aspect of it, I felt quite empowered to solve problems faster because I didn't have to do it hands on in the code. Sometimes I've been in refinement where we discuss a problem and then in this team specifically, they want the solution or the solution described in the ticket as well. So then the only thing the person has to do is read, they understand the context and execute. And that I don't have to do

anymore. So I don't have to do the execute anymore. I still have to do the thinking. I still have to do the reasoning, maybe not on a code level, but yeah, I do enjoy that part a lot more. And I would say that trend was already there before AI, because if you look at monolithic applications and micro services and then going cloud native or in AWS, for example, that's sparks your, your, your creativity to think of problems

in a different way. Because if you're writing a program, a command line program in C, then the solution would be very different than you would use micro services, for instance. So you architect your problems or you architect your solutions differently from your problems using the technologies that are at hand.

For example you can use an APIAPI gateway and with with micro services behind it. Or you can create one monolithic application so that the whole design phase goes more into how will I use these components Or it will be in a monolithic application, how will I organise my classes to be somewhat similar but then with different technology, it's just it's a shift and and now it's a shift again. So the tools are just changing, evolving.

It's just right now it's quite quickly that's that's evolving in the very space Skynet is coming. Yeah, I have one final question which I think is interesting to get your perspective on. I do Q&A's.

So in Q&A's people send me their questions and they ask me from my perspective. This question I thought was very interesting and I I might have even struggled answering this because there is no right answer. They said I have a product background, but I'm trying to teach myself software engineering. But even without the product engineering background or product background at all, how would you nowadays, if you're responsible as a mentor or as a teacher, teach people about

software engineering? What would they focus on? My answer was a lot less about actually the creating of code. I do think understanding is is still there, but I'm curious what your perspective is. I think it would be more in system thinking like these are all, are there multiple systems interacting with each other and how do would they interact with each other? Who's responsible for what

system? So it's more slicing dice, those areas like what are the responsibilities for for this particular entity within the application and have that understanding on what it does. And then you have, you don't need to know how it's built. You don't need to know who's

written. It could be written by a human, could be written by AI, but you know what it's responsible for and what it's core task is. And if you know that from the majority of the things, then you have a good understanding on what's what the application is, what it does, and what the capabilities are. Yeah. So you go one level above actually the the software creation part itself. And look. At the system as well. Yeah.

And then, then regardless if it's written in PHP, go, Rust, whatever, it's a system, Yeah, it interacts with something. Yeah, I like that a lot. Thanks for coming on and sharing yours. This was really fun. Yeah, thanks. I really enjoyed it. If you're still with us, let me know in the comments section what you thought of this episode and we'll see you on the next one.