Building in the Agentic Era

Meet the guests: building in the agentic era

Host [00:04]

Well, thank you for joining us here today on the CopadoCast. We're super excited to be here, and we're especially excited to be talking about our newest technology and some of our newest innovation. And with me today, I am very happy to say that I have the godfather of that technology, the SVP of engineering here at Copado, so Martin Bojori.

Martin [00:32]

Thank you.

Host [00:33]

Thank you for being here. And I'm also joined by Sachin Sankar, who is a senior strategy consultant with Cognizant in the UK, who is going to be giving us some of his insights and some of his experiences, having had early access to this new technology. Thank you for being here, Sachin. We really appreciate it.

Sachin [00:54]

Very excited.

‍

Copado’s origins and the challenge of reaching production

Host [00:56]

Let's start with Martin. Martin, take us back to the beginning. What problem was Copado-- I know you were there from the beginning, what problem were we originally solving at Copado?

Martin [01:09]

So, it's a good question, to look back and understand where we are. But the beginning was very simple. Is Federico and Phil, they were trying to solve the same problem that today, that is putting changes in production. They have very large amount of teams changing metadata, doing changes in Salesforce, and coordinating those changes to reproduction was a challenge. Mostly because the team was not technical, the usage of DevOps practice didn't exist back then. The knowledge to use Git properly didn't exist among the team, and there was not a easy way to coordinate those changes and really understand. So they were overriding things, they were pre-production with wrong deployments and was a nightmare. Well, actually it was a nightmare. That was the problem back then, and the evolution of that problem was understanding, okay, we can put a layer of simplicity, we can put a layer of governance, we can help people that is not technically savvy to actually move properly those changes across a maturity pipeline. And Copado was evolving over time on simplicity, on governance, ensuring quality,

Martin [02:28]

and basically trying to ensure that you are applying QA, applying quality gates, applying automations, and embracing all the good practice of DevOps, and we have been doing that for quite a long time-

Host [02:40]

Amazing

Martin [02:41]

... and learning a lot.

Host [02:42]

Amazing. And that early work is the reason we're all here today. Now, Sachin, you've also had a long history with Copado. You're a Copado champion. Talk to us a little bit about your background with Copado and where you first had experience with Copado.

Sachin [03:01]

Well, one of the biggest challenge which I saw was that the customers bought Salesforce, but that had no idea how do we deploy into production. And then the journey started with Copado. Copado was a tool that was trying to fit in, in the current landscape and try to help customers move ahead in their journey. So, as a Copado champion, Copado champion is not a title just for me, it's a responsibility towards the organization, towards the community, because we are the people who can guide the right things to the customers, right things to the consultants, right things to the team to move forward with their journey. So we have a responsibility towards the wider community.

Host [03:46]

Fantastic.

‍

Why Salesforce delivery keeps getting more complex

‍Host [03:48]

And, we've talked about Salesforce development back then. How different is it to what we're seeing today?

Martin [03:56]

Now, quite a lot. It's a different universe. I remember starting with Federico, talking with the team. There was not Apex, there was almost 2005. There was no way of customizing. When we started with Copado, there was permissions, of course, Apex and several started to cover other industry, but today it's completely different. It's exponentially more difficult because you have clouds from different vendors. Also, there is data and metadata, and you have coordination of multiple, not just the CRM, the typical sales cloud and service cloud. You have many things to add to the business, so the entire business is almost participating in the customization of the solution. So the challenge that the Salesforce team are facing today, even though they have more tooling, is, I believe, exponentially more difficult than cloud management.

Host [04:57]

Right. And are you experiencing some of these things, Sachin, in your practice?

Sachin [05:03]

Absolutely. So one of the thing which has changed over the years is that Salesforce have moved quite a lot. It is the futuristic CRM solution. But what has not changed a bit is the way how we delivering Salesforce changes to production. Because it's a very complex environment that we are dealing with. Not everything can be moved into production in couple of minutes, couple of seconds. Everything has to be thoroughly tested. There should be a proper governance, moving things into production. And there is a lack of confidence, which is, now we need to bridge the gap, that the confidence should be, again what we are delivering should be proper, and we have confidence of the end product that we are delivering it. So these are the couple of things that will make us a difference.

‍

The gap between AI coding speed and business value

‍Host [05:54]

Yes. Absolutely. Now, of course, we're seeing with the AI coding revolution and the AI coding assistance, we're seeing a dramatic shift in velocity and in the quantity of code being generated. What are you both seeing in terms of AI agents and how they're changing the way developers are working?

Martin [06:18]

Yeah. In particular, everybody is very excited about this. And it was not like a year ago. A year ago, the accuracy of the models to actually gather the context and be accurate on the change, and understanding the change, and understanding the context, and really apply a solution was not really accurate. But I believe that the beginning of this year, models are way more efficient at gathering the context, gathering the architecture, gathering the metadata. And they are really efficient on understanding the request of the user and applying that. And if you are a developer, you love, because you can prompt, and it is solving, it is telling you how to improve the code, how to follow the best practice. But at least what we are seeing, and our customers are seeing, is that developers are having way more speed, like I mentioned before, but the business is not seeing reflected that the impact on the innovation of work they have. Still, there is something that is not changed or required to be changed in order to reach production with that innovation.

Host [07:26]

You must be seeing the same thing, the tremendous amount of the expectations that are on teams now ahead of these tools, and the gap between delivery and deployment.

Sachin [07:39]

Correct. I think Martin is correct. The expectation has not decreased. So current customers, so if I compare it last year to current year, now customer is more aware of what AI can offer. So as part of their development life cycle, they are putting some pressure on putting some onus on development community to use AI. But if the developer is blindly using AI, his productivity sometimes is getting deteriorated because he can use AI as a tool for generating code, but does he have trust on what is he delivering is the right thing? Will his change is of right quality? Will it pass the automation testing? Et cetera. There are hundreds of questions that are still being unanswered because, yes, there is constant pressure on dev community to move things into production, but at the same time, everybody's moving at a very high pace. So we need to come up with some sort of solution that meets expectation of both the organization, one, the customer side, and one, the dev side as well.

Host [08:48]

Fantastic.

Martin [08:49]

Absolutely. And Sachin was telling today something, but for me what's very true is DevOps is not just about the product, it's also people and process. And you're talking about a cultural change that involves all of them.

‍

Why Agentia Headless puts developers and agents first

Host [09:02]

Yeah. Right. You don't have the process ... change to back that up, that technology up, you're not going to be able to take advantage at all. So this is creating a problem for us, this new problem, where development starts outpacing an organization's ability to safely get those changes into production. This, of course, was the catalyst for Agentia Headless, which is what we're here to talk about today. Is that correct?

Martin [09:32]

That is correct. We've seen now that we focus over 13 years on the person that we believe was responsible for the mission that was putting the change in production. That was the release manager. Now, the release manager has the responsibility of collecting all those changes and ensure the quality, ensure the governance, and reach production. And we focus so much on that persona, that we basically, to be honest, neglected the developer. And assume and forced the developer to join the process where he was not working. So the actual trigger for this project was actually recognizing that we need to go back to the developer, the person generating the changes, and ensure that he is comfortable using all the tooling. And right after trying to solve that, we say, okay, the developer actually today is not only the developer, is the agent of the developer. So when we say, okay, we have a great tooling, we have to move the tooling that we have to the developer, but actually we have to adapt our interface because the user is not going to be the developer, it's going to be an agent of the developer.

‍

Shifting checks left to reduce release bottlenecks

Host [10:41]

Right. Yeah. Fascinating. Sachin, when you first saw Agentia Headless, what was your first reaction? Did it make sense immediately to you?

Sachin [10:53]

I think as much as a developer loved it, as a side of stakeholder, I loved it quite a lot. The reason behind I loved it quite a lot is because there is a constant bottleneck between the dev community and the release engineering team. Sometimes the unexpected things that they see, which we cannot foresee, when we try to release things into the various pipeline, will help them in order to mitigate some things early in the process. So as Martin mentioned, DevOps is all about left shift. The more the things the developer can see on the left-hand side of the world, the more he will be confident on other areas. And believe me or not, this is a game changer. The productivity will increase quite a lot. Because if, as a developer, I'm seeing something in my one screen, I don't have to switch here and there, find out information, then it will be a very helpful operation. We will save time, keep everybody happy. So my impression is very good on this option.

‍

Inside Headless: CLI, IDE tools, MCP, and skills

Host [11:59]

Fantastic. And so tell us a little bit more about what Headless is. Where does it land? How does it...

Martin [12:07]

Basically, we have in Copado, in our AI product, in our testing product, in our CI/CD solution, we have plus 300 different tools to detect dependencies, merge properly conflicts to, item testing, and running in the browsing, and understanding sessions, and multiple things that are helping on that DevOps process. So basically, Agentia Headless is a layer, like I mentioned before, of a new interface for that user, that persona. That is the developer and the agent. So we have a new CLI that is exposing all our products. On top of that CLI, we have an IDE that you can use in Cursor, you can use VS Code and many other IDEs. And so it's a visual representation. But we also have an MCP server that contains almost 200 tools already. And we have skills, because we discover really soon that even if you expose all the power of all the tooling to the agent, the agent requires some guidance on how to properly follow the process and use the tooling, and the skills are very powerful in that. So in this project, basically, we're taking all the power that was in the pipeline for the operations of moving those changes to

Martin [13:24]

production, and we are moving everything left, like Sachin was saying, so you can, or your agent, you as a developer, when you are developing, you can combine all the tooling, and you can ask your agent to basically execute everything that potentially was a conflict later. And like Sachin was saying, I believe that the impact of this is going to be massive, because if we shift left all the potential problem that your pipeline is going to do, and we're basically moving and ensuring governance into the agent, into the developer space, and that is resolving conflict ahead, updating the test that you will face later. So why, as a developer, I'm building something, I'm pushing that to the pipeline, the pipeline is starting moving my changes, and I discover two, three days later, or one hour later, whatever, that something is failing and I need to context switch, go back, try to fix a test. If I can do everything in the beginning, like he was saying, the user stories are going to move faster to production.

‍

Improving delivery predictability with governance

Host [14:31]

Fantastic. Sachin, so just following on from that and putting yourself in the shoes of one of your enterprise customers, what changes when developers and their agents can now work together at this increased velocity?

Sachin [14:50]

I think-

Speaker unconfirmed [14:51]

With a govern, sorry. With a governance.

Sachin [14:53]

Governance. I was about to say that. So the million-dollar question is being answered is the predictabilities now will be empowered. So earlier, when the traditional DevOps was running, so one of the biggest issue was that as a developer, I cannot tell my scrum master or my senior manager that how much time it is going to develop a story. Because I was living in an unpredictable arena where I don't know what changes it might... There are multiple challenges in a DevOps pipeline on day-to-day operations basis. So some of them are merge conflicts, some of them are related to the environmental drift, some of them are related to low test coverage, there are no automated tests. So these things land up me in an unpredictable arena. I cannot commit to a delivery date because of this unpredictable arena. Now, what is going to change? Once everything is moved to left shift, how Martin explained, then there will be a level of comfort, level of confidence which developer can give it to the product owners that, yes, now I can deliver with confidence because now I have a predictability.

‍Sachin [16:00]

I can understand what things are coming up for me in the future so that I can predict the solution and act accordingly. And this is how the agent would help, because agent is not just replacing the developer's work. Agent is basically waiting for the correct instructions from the developer to move ahead in the journey so that it's kind of a seamless way of how we look things in the future.

‍

Why shift left matters for release teams

Host [16:28]

Excellent. And now you both have been talking, Sachin, you've especially been talking about this shift left mentality and this shift left objective. Martin, why are Salesforce COE teams, why are these release teams, why is that an objective and a priority for them?

Martin [16:47]

And I think basically, again, going back to the origin now, the problem we are trying to solve here is reaching production, giving some value to the business. And the best way that everybody understanding the software industry, not only, sorry, the software industry, the software industry is DevOps practice. And there you have automations, you have quality enforcement, you have a lot of best practices like agile and moving infrequent small things. If we have the new player in town that is the agent, that is capable of moving in the right direction with the right tooling, if we empower that person to be within the framework, like we talked, of the security of the pipeline and the governance of all those tools, automation properly, I think that we are helping on the mission of reaching production with knowledge. That is what the business is expecting from the software team. So shifting left for me means basically that, again, we're going to really move faster, not only developing, but doing the entire activity that you require to do the change for the business.

‍

Building trust in agent-driven pipelines

Host [18:07]

So we talked about a couple of scenarios. One is that we're giving developers now this tooling in the IDE where they live and work every day. And then the second part of that story is, of course We're giving agents now access to these capabilities because agents don't like human user interfaces. Right? Agents can't use and can't access human user interfaces. So in order to empower them, we've given them direct access to command line. What do you think as we embark on this and as we see more and more work being carried out by agents, is trust an issue there? What sort of issues are we going to face that we haven't faced yet as we unleash our pipelines into the hands of the agents?

Speaker unconfirmed [19:02]

This old beast here. You want to go? Move.

Sachin [19:06]

Yeah. Trust, security would be an issue, because not all customers are privy to how agents should work and behave and react to their metadata. Even if you have advised them that your metadata is secure, it lives in your area. But still, the questions will be around at how trust it is to trust the things which is happening. But, I think what is more important is that, yeah, trust comes up with an added kind of a value. But what comes up is that how do we trust the whole process? So the whole process means that how a developer can move things into production with confidence will be a value add to them. So yes, trust is for the enterprise level they need. They still need to see how do things fall upon. But from the developer community, if his work is getting recognized or his work is getting moved, that's the confidence he can give it to the wider practice and community. So I think that's what I understood, Martin.

‍Martin [20:16]

I just think of my old customers. They were having a sales process in Salesforce. So they have literally hundred of people using Salesforce to sell an airline, for instance. Facing an issue in production is something that the company will regret forever, if you want. So the fear is there. The fear is because you can have an impact. Changing and breaking the system is difficult, and the pipeline is trying to generate some trust. But I believe a year ago, two years ago, maybe nine months ago, the people was not trusting that AI was capable of really understanding the architecture, really understanding my coding conventions, my testing convention, and being effective doing anything. I didn't trust AI. That happened nine months ago, and now I really trust. We are evaluating that new ways of doing merge request, for instance. The AI is doing the change, and I have a process of quality that, of course, we are doing a pull request, a merge request. But more and more and more, we are doing a risk assessment. We are trying to understand the potential impact of that.

Martin [21:34]

We are automating how to properly ensure the quality in a better way, in a more automated way. Sometimes deterministic, sometimes non-deterministic things. So if we have to give the business the confidence that the change that AI is generating is not going to break the process of the business, that is going to be huge. But we have to gain their trust. And the way of gaining the trust is basically the same pipeline that we were manually managing before, and we now just have the tooling of automating more and more. And since we can do that, like we said, since the beginning of the pipeline, that should prevent other problems to happen. But it's going to be a journey. It's going to be a cultural journey. It's going to require, like we say, process, not just the tooling to change, but also the process, also the people. But I don't know. The industry is moving so fast that let's see what happens in six months or six days.

Speaker unconfirmed [22:40]

Very difficult.

Martin [22:41]

Nobody knows.

Host [22:41]

Very difficult to predict, right?

Speaker unconfirmed [22:43]

Yeah.

Host [22:44]

Seems like it's increasingly challenging.

Sachin [22:45]

And as part of being a Copado Champion, this is our ownership to make sure that there's a cultural shift of how people are seeing AI. So one of the things which is more personal to me now with the new headless thing that, Martin, you have displayed is that now there is a kind of a, in large scale enterprises, if a developer is not able to complete the work on time, he might say that it's a tool problem. But now what Martin's solution is bringing back is he's giving a chance to move everything on his shoes. Now, there is no more a tool problem. It has to be fixed in his own area. So he's moving things into the black screen now.

‍

How developer and release manager roles are changing

‍Host [23:29]

Yeah. Well, that's a follow-on question from that point exactly. Good segue. If developers now have access to this tooling that was previously the ownership of the release manager, and so that part of that dynamic that you're describing, this new process really has to wrap itself around this idea that now these things that were previously the exclusive domain of the release managers is getting democratized.

Martin [24:00]

Yeah, I believe we are going to be-- One of the things that is going to happen is reviewing the roles. The roles is that everybody's going to have multiple hats.

Host [24:08]

Yeah.

Martin [24:08]

You don't have the typical, the traditional process of doing QA later on the pipeline and having a manual QA, of course, and having a person that is going to try to build this automation later on doesn't make any sense. Right now, doesn't make any sense. And resolving conflicts is another good example. Now, again, I know that multiple teams, 50, you have 50 people changing the same organization. Of course, you are going to have conflict because multiple people is going to touch the same class or the same objects, and eventually you have to resolve that. Why the release manager need to know the business change that they were trying to do if you can have the developer solving that? If we are not wrong about that, the impact is very obvious. At least very clear. Everything in-- It is like a highway. You are not going to have traffic jam because you're not going to block at some point an environment and preventing more changes to move forward. And everything should happen ahead, and that is our intention and our vision.

Host [25:18]

Sounds like some sort of DevOps utopia, doesn't it?

Speaker unconfirmed [25:23]

Yes.

‍

The future of the agentic developer community

Host [25:25]

Excuse me. And so just finishing up on that thought, where do you see all of this going? What do you see in the future, Sachin, for your teams and for your customers?

Sachin [25:37]

So future of this whole concept is great. So we are moving. We are taking some baby steps. As a community, we are taking some baby steps in making sure that things are going in the right direction. We have an added ownership of making sure that it is understood properly. The trust part, which Martin explained, needs to be registered in the minds of the decision-makers. Once that part is done, I think everything will be okay, and there is a great future. One of the things which I was telling to one of my friend is that both Salesforce and Copado works hand in hand. So if Salesforce is trying to bring something new in the market, Copado is ahead of the game and matching those strategy. So we are seeing a great potential of this modern age DevOps now, because there are a lot of autonomous being given to dev community. A lot of autonomous has been in testing community, and nobody has to worry about anything which might go wrong in the future course, in the pipelines.

‍Host [26:45]

Fantastic. So thank you both for your time. Very interesting. Super exciting to see headless with all the work you've been doing on landing here. No doubt you've got a lot of conversations, and you're going to be very busy man this week.

Martin [27:04]

Yes, indeed. And happy man as well.

Host [27:07]

Well, thank you, Sachin. Thank you so much, and we really appreciate you coming in to talk to us. Have a great-- Enjoy the rest of the event.

Speaker unconfirmed [27:17]

Enjoy. Thank you. Thank you. Take care.