Jag Valaiyapathy, who joins to talk about Agentic coding and sf-skills, is a Senior Forward Deployed Engineer, Salesforce CTA.
Main Points
- Claude code and agent skills
- Vibe coding evolvement
- CLI tools as a come back trend
- The vibe coding mindset
- Specs and hooks in sf-skills
- Context window
- Future roadmap
- A suggestion to sf devs
Links
- Sf-skills: https://github.com/Jaganpro/sf-skills
- Agent skills: https://agentskills.io
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:14] Hello everyone. This is Xi Xiao. This is yet a new episode of Salesforce Way podcast. It's been quite a while, so now I'm back. So I'm starting a new episode with Jack. Hello, Jack. Welcome to the show. Hi, I'm Jag. I I've been with Salesforce the past four years, and I'm super excited to join this podcast. Yes. So I understand that, Jag. Not only you work in Salesforce, but also you have your CTA certificate already, right? A big applause from me. Thank you. Yeah. So I got my CTA certification last year, a couple of months ago during. The August timeframe, and yeah, it's like I'm happy. I'm more, I'm more relieved. I'm more than happy that the the two years of certification journey have come to an end, and I want to move on to other other areas where I can focus on. Yeah. Yeah, so Jack, I see that you created this SF Skills GitHub repo. It's open sourced. And it's meant for the agent skill. I know now the AI coding, the so-called vibe coding, actually is really hard. So that's exactly the reason. I think what you did is really useful, and I'm also personally quite interested in this topic. So that's why I think we might just have a discussions here. Yeah, yeah, absolutely. I can sort of introduce Salesforce skills. So. Backed in August September timeframe, I was trying
[01:44] to explore different AI tools, and I stumbled upon Claude Code. And during that time, Claude Code was the only LLM harness which which was supporting skills. And this was way before the skill became an open frame, like an open spec, which can be used by any agents. Um and I I saw a lot of demos where that it was almost like a one shot demos where uh where you prompt something and and um in in the Salesforce ecosystem and you're able to build some components and it was impressive at that point of time but there was there was no single place where you can actually see the see the specification files and how they did it. And that really led to me creating an open source MIT, so that I started creating these these different skills, and also try to provide a way so that everybody can contribute and learn together. So maybe let's provide a bit background here. I know, like even five months ago. So today's February of twenty twenty six. Five months ago, I started to use like. LLM for coding and in the past what I did actually is use the browser. I can copy paste the code back and forth. The browser give me some feedback if it's a legacy code, ask it to explain. So kind of like like a chatbot way.
[03:14] Even though the the large language model is is capable of interpreting the code and tell me the the answer. But now I think since the so called agentic Coding style appears, especially from the the cloud code, uh, was introduced in the industry. A lot of things has changed, and that's also like the the foundation for this so called agent skill and the SF skills you created. Would you mind to help us to understand a bit more this this feature? Yeah, so maybe we can take a step back here. Back in twenty twenty two or twenty twenty three, when the when first the open OpenAI you know ChatGPT was released. You know, it was a big shock for the entire world because now you can, you know, copy paste a code snippet or ask something really simple, and it's able to write an entire a file or like an entire like hundreds of lines of code. Um, and that was a gold rush at that point. So you know, at that point, where if you have some issues, then you basically go and copy and paste the code. Obviously, if you're working with a customer, you probably scrap the customer information and just figure out how to extract just the question, and then you put that in ChatGPT and get the response, and you go back, swivel chair, and then copy and paste it. Um, so that was sort of like the evolution one, and then in parallel. There were IDEs such as like Cursor
[04:44] who have pioneered this tab completion. So even before you complete writing a line of code, if you if you tab complete, like it will automatically finish your your intent. So it's really good at like you know figuring out your intent and completing the the code of the line of code. And then it moved from there to basically adding multiple lines of code. You know, the Git, ah, GitHub, ah, Copilot was one of the good examples. Like we're able to also also do complete multiple lines of code, and not just single snippet or a line a line of code. And then there was this complete revolution, and how to use the the LLMs, how to harness these LLMs using the CLI tooling. So I would say the whole CLI tooling really came back, like using. The large language models in CLI, and I think the reasoning for that is because fundamentally, from the LLM standpoint, it is text input and text output, right? And and that particular type of input output. Format, you know, it is, it is really simple to do in in CLI, and you don't need a fancy UI to start get started with. And then, CLI by nature is infinitely hackable. Combine this with you know LLMs started to get really good at writing Bash code, so you can basically you know
[06:15] tell your intent like what do you want to do, and it's able to construct. Really complicated queries or or commands, and and it's able to execute like the stuff what he really wanted to do, and so that that led to a lot of explosion, um and and Cloud Code is one of those tools, and there are multiple other tools that is Open Code that is Py. I use. I've also used AMP. There is. There is. There is things from you know. OpenAI like called Codex, Gemini. So there is there is an explosion of tools that just come come out in the CLI. And so now we are in this agentic workflows where you could use any of these CLI tools to to to kickstart and and and not just fill fill in the line of code, but then you could write entire sort of files to solve your problems. Yep, I think actually this also surprised me back a couple of months ago. As you said in the past, Visual Studio Code or Cursor was like really hot, right? People need to use their IDE to write code and finish. Like the usability wise, is always the IDE is better. But now the comeback is really here. Now everything is like a CLI. I don't know why. Like Cloud Code, I have it installed, and Codex, I have my personal license from ChatGPT, so I use that. GitHub Copilot is like my company is paying for that, so I also have
[07:45] it installed. And the open code you mentioned. This open source version, which you can like, hook into all the different language models. I have all of these, and none of them actually is the IDE version, and I'm personally really happy with that. I think it serves really good the purpose, right? And you just need the text. You just need to see what the language model did. Like read the files or touch the files. All those things actually are done in the CLI. So you don't need the IDEs at all. Yeah. So it's it's a it's a real debate at this point where um you know I you know if you if you think about it IDEs are Meant in many ways for humans to write code, and now there is this fundamental shift in terms of do you do you really want write code anymore? And and and and with this agentic workflow shift, if you start writing code, then it at some at some levels it start to become suboptimal. And the reasoning, and the reasoning for that is because, um, when you when you write some code, um, and and if it's isolated from the context window, now you need to import that changes into the context window so that the LLM can understand. Now you can do that by by by multiple by additional steps, but still, like, but if you ask the
[09:15] LLM to write the code itself, and if you know how to steer them. Um. Then it's then it's a lot more efficient to actually um produce a lot more useful work, a useful unit of work. Um. But I do want to I I don't want to preface this by saying. Writing code is different than understanding the code because you're able to write code faster. Then it then then it naturally creates this learning debt, learning debt, or learning debt. I I I like to think it as, um, you. You, you, you, you actually communicate an intent to an LLM, and and the LLM and how effective it is, and it's able to create something for you. And immediately the produced output. Now, now, AI models are really good at producing like hundreds of lines of code at a single at a single point. And now it actually creates two different type of debt. It's the learning debt and the and the understanding debt. Um, now you you didn't you didn't learn by writing like you know historically we would write code and then like you know that by doing that we also you you think slow and think fast and so you actually end up learning a lot. And then, so that's so that you're creating the learning tab because the LLM is doing that for you, and then the other thing is essentially. Um, understanding that like you created hundreds of lines of code, now you don't necessarily understand every single thing what it generated.
[10:46] Right, and so we'll talk more about the the the spectrum and development on one side, and the um and the white coding on the other side. Um, but I think that so this is a new world we live in, and in in order to go faster, and you want to parallelize your workflows. Like I I I think in the last few few months, I've completely shifted my way of thinking and way of how I write my code and understand the code. So that's pretty much where we are. Yeah, for me it's the same thing. I know that you are using Neovim as your code editor. I'm also using the same thing. So in the past, the Neo Win is always like the first thing I open when I touch my code. But now it turns to be like the second window. My first window is the the coding, the web coding CLI. I open it that, and if I have any questions or I need to refactor something, I always discuss with it, like a pair programming to me. Then in case I do need to touch the code myself, then we open a second tab in the Neo. And thanks for your information. I also noticed this: if I touch the code in separate window, it's not in the context. The language model didn't know. He needs to read the file again. Oh, you have touched the file. Then he will start to catch up. So that's definitely a gap. Thanks for this information. I think I pay the more attention now. Nonetheless, I think the main thing for me is that in the past I tend to still have this ego. Hey, I can think better than the language model. But now I kind of like put down that ego.
[12:17] I think I'm the servant now. I can feed you the information, the context, or anything in my brain. So please help me to write the code. I will. I will maybe just review. I think that's my now mindset. I don't know if it's right or wrong, but that's how I think. No, I I think it's quite natural for humans to, you know, you know, I I've been I've been in software industry for the last fifteen years, and you know, my very first job was writing code. I remember writing code, HTML and CSS. That was my very first job, and I and I tried to do, and and and you had a specific workflow for the past. Fifteen years, and it's really hard to let things go. And and and and when you when when you're able to do something for so many years, and you're able to have some really good output. Especially as a senior developer, obviously it tends—you know—we tend to cling on to certain workflows and certain ways, and it's really hard as a transition. And I, I, I do think that it was really hard for me to let things go, to write, to to handwrite, to handcraft something, because whenever you talk about something handcrafting this. It it it always comes with a lot of pride because you spend a lot of time and effort to to do something like that. But then I kind of I'm slowly progressively letting things go. And even if I want to make a very small change, where it took me, let's say that if I want to modify something in the CSS class, which go
[13:47] go from gray to light red, what whatever whatever the the change might be, I would still ask the LLM to do it. And because it is because it is in the context window, and the and and the more it it it starts to get more and more in terms of. The effectiveness of your LLM really depends on how you manage your context, and every single. You have to rethink your entire workflows to manage the context window. How efficiently you're managing it, and then over the long duration, like course of time, when if you're asking more and more complex things, how do you, um, how do you manage your compaction, um, and how do you keep keep keep going on for longer sessions, right? Again, that that's that's where your engineering focus really turns on, and to to produce really good output from from from what you what you really want. Yeah, I think also vibe coding is kind of addictive because it's so efficient, so effective. It just write the code fast, and you can drink coffee. And in the end, you just review the things that it did. And usually nowadays, it's not bad at all, right? Understanding gap and this knowledge gap you mentioned, I think that's also a big challenge for us nowadays because it just outputs the code so fast that at at some point I just hit enter. I cannot reviewing all the things it did. Yeah, when I first started, you know, using
[15:17] Cloud Code, and and Cloud Code is just one of the harness I use. I use a lot more different harnesses. I was so against white coding. Where at least when I started, I was like really, really against white coding. I was like, this is not engineering. You know, you just give something and then you just spit out like you know code, and you're not reviewing the code. And then there is this question about, okay, if yellow number is able to produce this much code. Okay, then who who who who do you who do you think is the author? Or are you responsible, or the LLM is responsible? Okay, and then I I started, and it's also important for me to white code like some some things to really understand what white coding is for prospective end developments. I actually created. It just, by the way, it just gives an immense power to actually go and create anything you want. So I actually created something called as the Metadata Explorer. It was another side project I ended up creating. So basically, it's a replacement. It's a it's a local. It runs on a local host, and essentially, it is it is a drop in replacement for the Schema Explorer what we have in Salesforce, which has not been updated for the past ten years. So you can go and pick any object you want. It will show you whether it is a standard object or a custom object, what type of relationship, what type of cardinality does it have. Sometimes when I want
[16:47] to understand, let's say I want to explore manufacturing cloud as an example, the first thing you would want to go and take a look at is the how did the data structure and the data model structured, and and so I I created my you know it's it's a tool that I really wanted and I ended up creating I was able to white code and create that in two days. Now you can ask the question. Okay, it's a personal tool. Do you want to go and review every single lines of lines of code? What what what it generated? And for the answer for me is is no because it's not it's not mission critical for me to go and review the code. But it is able to produce majority of the things I want and the the the overall human human level you know testing. Um, like unit testing, it kind of it seems to be working fine, right? But again, but if it starts to be adopted by a lot more people, then you can just wipe code your way way through. Then on the other side of it, it's essentially everything is spec driven development where. Um, speculative development for me combines multiple things together. It has deterministic checkpoints to to analyze like the output of the LLM and and able to reject deterministically whether this is right or wrong. And and we can talk about the static code analysis, the LSPs, and and those are all the type of things are also part of the SF skills. That it actually you know be. It's it's actually
[18:17] on the side of the the spectrum and development, and then and and the second part is essentially you you are. Um, you start with some very simple problem, and then you see the output, and then you look at the quality of the output. And then you determine whether if the quality of output is is acceptable or not for you, and if you want to make a change, and that change is essentially reflected as the spec file back to the LLM, so that so that it's able to reflect better work in future for you. So this this manual I call this manual reinforcement learning through human feedback, and the human feedback is is essentially creating the spec files. Um, which which is what led to the S of skills in in in many ways, and and so you can see the reflection from the standpoint of the perspective and development, um, all the tools you need to to to have to to produce the structured outputs for you. Let me ask you some questions. You mentioned SF skills. To me, it feels like it's a workflow. When you do something, for example, writing Apex, I know you have a so-called Apex skill. When people need to write the Apex code, you can automatically load that skill. Basically, it's like a expertise for the large language model to process and create Apex code. You have specs. To me, that's like a steps of defined actions
[19:48] to create the Apex. For example, you can define. Naming patterns. You can define what's the best practice to create the the loop, how to write the SOQL queries, all those things. Maybe the general large language model didn't know well, but now this is like so close by. There's a manual for you to follow up. So that's the spec. Also, you mentioned something deterministic. To me, that word means you can run it repeatedly and get the same result. Comparing to the large language model, which always give you slightly different results from time to time. So it kind of like have this both word, the best of the two words combined into this so-called SF skills. Is it so? Yeah. So the good example where I can draw parallels on is is
[20:39] is even with Agent Scripts. Like that's that's that's the next gen Agent Force agents from Salesforce. So you can you can think of it it this way. So from from Cloud Code standpoint, so you enter something. Uh, you, you. That's basically the user utterance. Um, and Cloud Code as an ecosystem provides multiple hooks or intercept or points to intercept at any and in this entire lifecycle, and it has something called start session hook. It will have three hooks: post hooks, pre tool use, post tool use. Um, um. That so what what I mean by that is. Every time you actually try to have have have some utterance before it it is being processed to the LLM, you could write your own workflows as as bash scripts, as Python scripts, and we will be able to intercept that and then have some structured. Maybe you want to give some structured input. Maybe you want to look for for structured output. So you can you can think of that that way. And and by the way, that is that is how I am able to inject the LSPs. Like basically, I am trying to bring back like some of the best features of the IDE, which is you know you write something, you actually already see from the LSP working in the background and says it has the squiggly lines that something is wrong. But from the LLM workflows, like in this agentic workflows. Um,
[22:10] even before the agent is able to go and deploy something or go and save something, uh, to to the Salesforce servers, it should automatically invoke the LSP, understand the output of LSP, and perform the loop. So you you can write some workflows like this, uh, to to make it more deterministic in nature because the hooks by by its nature is deterministic point. Where a checkpoint where you actually intercept every single message, and so I have taken advantage of these hooks ecosystem provided by Clark Code, but but but doesn't mean that Clark Code is the only ecosystem is able to provide this. There are other LLM harnesses able to provide this, but but I would say they are the pioneers in this. They are the ones who actually created the skills skills ecosystem. System. They are the ones who created the MCPs. They are the ones who actually pioneered the Hookseeker system. They've Far ahead than almost any any anybody else, and now they are pioneering at the agent swarms. So it's like this this this new gold rush. Um. So they're really um far ahead than many of her competitors. So that is the reason why I use I use the skills. But but going back to determinism, that's how I I'm able to go and re inject those specific workflows. And when you say the hooks, maybe as a Salesforce developer, I can think it as like a trigger, trigger action, right? Before insert, after insert, you can inject
[23:40] whatever you want. It can be simple. It can be as complex, right? Exactly. On top of that is that all these hooks. Can give you feedback. For example, if the large language model outputs some code, you can check the code. Does it the align with the LSP? Can you do the PMD static code analysis check? If no, it failed somewhere. You feed give the feedback to the large language model to update it. So it reduces the human. Manual work, manual check. It'll give you give you a better, accurate result. That's how I understand. Exactly, exactly. So it's it's you can think of from the DevOps perspective as well. It is trying to bring. All the things you used to do, not maybe not all the things, like some of the things you used to do, it actually frontloads it. LSP check has always been local, but think of the static code analysis. Think of like any other workflows like you used to do in, let's say, in a GitHub action, right? Like now you can actually bring it down locally. You could you could frontload it, and then figure out a way how you can how the LLM can harness these tools. And then provide this and and and make this agentic loop, because not every agentic loop requires a human feedback, like and for specific. Loops like this, like the LSP. I don't need. I don't need feedback if the LSP is telling you that okay, if something is
[25:10] wrong, you don't. I don't. You don't need to ask me. Just go and fix it, and then provide the final output before I. You know, we can go and and and work on it. So so we are able to create these mini loops. Um, not to con get confused with the Ralph loop, but but these these these mini loops can be can be can be created and and and this is um. I think a very specific workflow I created in Salesforce Skills, but it is that's why I kind of made it MIT and open source, so anybody can fork it and come up with their own workflows, or even better, propose something as a PR. And you know, I I look at it almost every day. The first thing in the morning, I look at it and and make sure. Because I I use it on a daily basis as part of my workflows, so that I can keep it updated. I also support my clients in parallel. Also, keep on improving the skill so that it benefits everybody else. I think what you mentioned the SF skills or in general the so called agent skill. It's loaded on the fly, so it does not consume the context. That was a big win when it was introduced because in the past, all the prompts, those are loaded in the context. It consumes the the token. It was like a really heavy. Yeah, yeah. So the just just to kind of step back there and double click on the point you mentioned. The reason why I created skills, and just for people not aware of what skills are. Skills are nothing but spec files or specification files, which are basically rules to tell the LLM what to do in a specific, in a in a in a
[26:40] in a in a very domain specific way. And and you could create what those domains are. It could be as large as a single vertical, like industry vertical, to all the way to very. Um niche things like for Apex for LWC and you can even further go and say okay I want to do focus on Apex batch or Apex triggers and stuff like that I have to come to some point to kind of figure out like how I how I can compose everything together um but the reason why you have those skills is because you can't write one single large spec file and if you end up if I end up combining all of this information uh it just becomes too large and it won't fit the context window. And every LLM has its own context window. For for example, if if I have to take Opus four point six as an example, and so you basically only have one hundred and sixty thousand token budget. And out of this budget, and that's why that's this is where we get into this advanced context engineering. Where when you when you are asking for some particular requirement, it might only need Apex to solve that requirement. It might only need flows to solve that requirement. So you don't need to load every single. Um, you know, spec files as part of the context window, and so you load the Apex, you finish the work, and then once it's done, once it's done, everything, then maybe you even want to clear your context window, and then say, "Hey, here's the Apex file." You get a fresh context, like hundred sixty thousand. And then start working on maybe on testing, right? Like then you can load the testing skill and do it. So
[28:10] it's really important to kind of figure out how to compose your workflows and and and and think through that. And then on top of this, um, you you you know when I when I actually used my cloud code, I actually created a a status bar, with my own like I white coded um a context window indicator, right? Out of those hundred and sixty thousand tokens, there is something called as a smart zone and a slop zone. Um, maybe the first hundred thousand tokens, the LM is is quite smart and it doesn't forget the things that what you told it to do. But the last sixty thousand tokens, I call it the slop zone, where it might tend to forget, it might tend to deviate from the um, deviate from the from the goal what you provided. So also taking that into context, so there is a lot of things that you would end up learning along the way once you start like using it on a daily basis, specific for the Salesforce. And also, Salesforce and ecosystem has its own quirks. So you'll end up learning, and and the more you do this, the more you are able to harness the LLM, the better output you will end up getting, and. And and basically leads to better efficiency. Yeah, I think that's the reason when you create such tools, you know that you have to manage the token, the context windows, because that's just how it is nowadays. Before vibe coding, it's not such a thing at all. But now, I guess developers go
[29:41] into the interviews. People who get asked how efficient is your this vibe coded program will will manage the tokens. But I'm I'm still interested in the agent skill like the definition. I know you mentioned the specs. Those are written in the natural language. They are MD files in general, right? So if it's like this, it's non-deterministic. How do we make sure the language model will really execute them? Maybe at some day that in a good mood they will follow you, but maybe another days they do not. So how do we handle that? Yeah. Um. So let's take an example. Let's say that I want to create a service agent, which goes and checks the order, uh, order status for uh for a customer. Now this is a really simplistic example, but I wanted to walk you through the sort of the workflow, you know, and how how how you can make it more efficient. When I have something like this, I try to provide as much as information as possible. I would say, hey, you know, I want to create a service agent, and I want to use agent scripts. And I also also please make sure use this particular SF AI agent scripts skill, just to kind of remind it. Like if it didn't automatically pick it up. Um and I also say something like you know interview me if you have any open questions. So at first I don't want
[31:11] the agent to go and start building because it's so eager to go and build and write a lot of code. I just don't want the agent to do that. I'm sorry, I just don't want the LLM to do that. And what I really want is to work with the LLM to actually create that high level plan. And this is what we call as a plan. There is a plan mode, and and and and and and essentially a mode to go ahead and create all these files. So I spend a majority of my time in planning. The way I think about it is, um, you know, you spend eighty percent of your time sharpening the sword, and then you only spend twenty percent of the time, you know, swinging it. And so you want to spend as much as time as possible. And that and and what you're essentially doing is sharpening your intent and aligning your intent with the LLM's intent and what it is attempting to do. And so it writes this whole plan, which says, first I need to create an Apex class which goes and creates the order object. Actually, even before that, it will first ask me, do do you want to use a standard order object or do you want to create a custom order object? What fields are you thinking? So maybe these are all the prompts or information you did not give. Which in my in in my argument you don't need to give that, but what you need to tell the LLM is to interview you, so that it can actually ask you. Intelligent questions. So in this case, I did not give the agent the gallium to say, "Okay, what object have? What object I need
[32:41] to use? What fields I need to use?" But it is able to intelligently, intelligently come up with some suggestions and asking me as a consultant. And I and I go and pick those choices, and then it will say, "Is Apex okay, or do you want to do this in a flow?" Or if it if it attempts to do it in a flow, maybe my preference is to actually do it in Apex. So and I can steer it and say, "Okay, go and do this in Apex," and then it will come up with a gist of like, you know, what the logic could be. And then it will say okay, and then I'm going to go and deploy this and write test classes to test this, and then you'll come back and write an agent, and they'll give you a snippet on like and what it is what what it's intending to write. Now, it actually has this this type of workflow has two advantages, and this is specifically true with Clark Code. Is that when you are trying to plan something like this, you are going to have this massive like it's going to go and explore, load the scale, come back and do all kinds of planning, and it might have spent close to one hundred thousand tokens in this case. And now you only now have sixty thousand tokens to go and execute, right? And so what he can do in Clark Code is to say, okay, once he comes comes up with all the plans, let's say it spend one hundred and twenty thousand token, he hasn't um comes up with the plans and it'll ask you to approve. While you're trying to approve this, you can say, "I approve and also cleared the context window," which means that it it only has the plan for you, and that's probably going to be like five
[34:11] thousand tokens of the that's the plan. Now it's all it needs to do is to go and read the plan and execute the plan, right? It doesn't need to like have all the tokens which is necessary to go and explore and do everything, and that's one level of efficiency. That it could gain, like moving from without compaction, moving from one context window to a fresh context window, and and guess what? Now you have the plan, and now it's trying to execute, and but it's going to execute in the smart zone, like I mentioned, and you're able to get from really good results from from from the output of like what you planned, and and you have by by the way, you have approved every single step, what it what it is. What what it is attempting to write, and and this this is like far far fetched from like moving from wipe coding. Basically, you're writing something and it's gonna spit out something and and praying that like you know it's essentially aligned with like what you think to all the way to every single step it's able to do, and then on top of this. While it is executing, while it is creating the Apex class, now you now have the hooks layer, hooks ecosystem. It's going to check for your LSP, check for your naming conventions, check for all the things like what you have already mentioned, what what you already worked through. It's going to do this additional layer of deterministic checks even before it deploys to it deploys to sandbox or production. So that that is the way that you can
[35:41] bring. Or harness the LLM and and and and make it useful for you, for your specific workflows, and that's pretty much how I use it every day. And. Every time I see, I find a fault. What many LLM does some some some kind of maybe it it issued a wrong command in SFCLI. Then I actually capture that and I try to make sure that that particular mistake is is not. Uh, repeat it again by going and adding a spec, a line, uh, in the spec document so that it doesn't repeat that again. So this is this agentic loop, like you're really talking about. Um, and I, I really think this is the new way to go and develop and and and and and imagine that you can do this in a more parallelized workflows. You could do multiple things at the same time. So, and that's where everything is leading to. Yeah. I also think for any person who has programming background, we understand that planning. And exploring the technical details are much more important, and it takes much longer time. When you get everything clear, you start just pumping the code, right? So this planning mode, as you said, I think definitely it's it's it's it's natural. It's intuitive to to us. And also, it saves a lot of these context tokens, right? You make the finalize the plan, and that's compressed into this next context window for for the executor.
[37:11] So I think it's called a build build mode in in the following step when he pumps pumps out the code. But again, I think for all the listeners who. Think this is interesting? You need to start using the web coding tools because that's the only way you can feel the pulse. You you need to see how it thinks, right? Whether it's a real thinking or or like a Have that's an artificial thinking, but it is there like pair programming with you. It can articulate. It can like reason with you together. I think it's a really good body when we write the code, and it's almost free nowadays. You don't really need a senior developer all the time with you. All right. Would you like to share a bit more? What's the roadmap? What's the future plan for this repo?
[38:04] Yeah. One one thing I do want to point out from the from the SOQL architectural choice is that SOQL skills does not use any MCPs. So Salesforce does provide MCPs, MCP tool calls to go and you know if you want to deploy something, if you want to retrieve something, you have like specific MCP tools to do that. With the Salesforce skills, what I what I've noticed is that you could just use. Ah, SF CLI tooling, and the SF CLI tooling is incredibly powerful. And as as a bonus, um, sales, the LLMs are able to actually read its own doc, read its read its documentation from SF. You know, if you do SF help or SF any command help, it's able to understand like what these commands are used for. So it's almost like self documented the the tooling itself. So, um, it's incredibly powerful. It's able to it it it falls under the unique's philosophy, which is basically unit of work, and then you could actually combine everything to like you know you could actually orchestrate and. Combine a lot of things together. You can pipe from one thing, an output of input of one thing to an output of another thing using pipes using bash tools. So it really follows the next philosophy. And plus, the combination that the LLMs are really good at writing bash scripts. I kind of figured that you can virtually do anything you want
[39:34] just with the Salesforce CLI. And this is all the basically that the SF SF skills falls. Piggybacks on the hard work done by the Salesforce CLI team, right? And it's just a much an incredible like it's context efficient and everything else. But that doesn't mean to say that MCP MCP has its own place, and the reason. For S of skills here, it it it completes ah um a very specific requirement, which is that and and and also the presupposed notion that you you're using these tools locally, and it's it's it's it's actually. Optimize for that. You're using these tools locally, and you have a local execution system. Like like you have access to terminal, which can run Python, which can run Bash, and you don't need cloud resources to do any of those stuff. And therefore, SFP. So the entire SFP skills is actually using that as as as to to. To power it right, and that is the presupposed idea behind it. Um, with regards to um the future, I want to continue to improve the skills. Um, I've also a few of the folks have volunteered to create skills specifically for industries because if you if you've seen like you know S F industry maybe data cloud S F industry maybe manufacturing cloud. Um. There are a lot of lot of things that's very specifically focused on industries,
[41:05] and you know if you have skills for that, like that, that would dramatically improve the workflows for for folks who are working on industries. And then the other key thing I'm continuously working on is the orchestration layer itself. Right now, the orchestration layer does not pick up the right skills at the right time. Sometimes it will go. The LLMs are eager to go and create an Apex class without using the SF Apex skill. You know, it will not auto detect it, and then it won't auto import it. Sometimes you have to stop it and say, "Can have you used SF skill like SF Apex to to write this?" Because the output of it is going to be dramatically different. To do this, that's that's orchestration layer continuously trying to think through and work upon. Um. The second part is this: this is new world of agent swarms. Uh, how do you harness the agent swarms? Basically, you what you can now do is that you can you can actually create a to do list, and then for each and every list in the to do list, it can actually create um dependency between one uh list one to list like uh item one to item two to item three. And then also figure out what are the things you could do sequentially, and what are the things you could do more in parallel. Okay, you know. So it's you know, I think people have tried it before. People used to write custom framework to do this, to how to communicate between agents and sub agents. Not to kind of confuse with sub agents, but this is a completely different concept.
[42:36] Even though a lot of things are quite similar, but that's a new world, right? Like if you want to do testing on on on agents, if I want to do a multi-turn testing on agents, I actually it is not supported in the testing S of scale testing. You can actually you can spawn multiple agents and then do things in parallel and then come back and report back to the orchestrator. So you don't need to open multiple tabs to do this in in parallel. It can automatically organize itself to do it as well. So I think that's that's where it's going and and that's what that's what I want to focus on and then continuously improve the sales Salesforce skills. Specs. I mean, this web coding area is advancing so fast. I want to get asleep. It's like twenty four seven. I'm following. Hey, what's going on here? It's always something new. But I think we can more or less wrap it up already here. Could you, if you have any one sentence advice to the Salesforce developers on this web coding era? So what would you say to us?
[43:44] I would say, apart from a set of skills, like in general, using the LLM to harness its input and output, to to really understand, like you know how you how how useful it can be to you is a new type of skills like you would need, and it goes beyond Salesforce ecosystem. So once you start working on this, you would start to realize that it's not just for Salesforce. If you want to develop any thing, this is a new skill set you want to acquire. Um and that's why I personally am focusing on it every single day and I learn everything and I don't know everything and I learn through the community and um and I try to contribute as well so so um yeah so that is the most important skill I think for twenty twenty six L and that's where I spend majority of my time and I would encourage everybody to think. Think about that. Thanks a lot to Jack. I guess we can close it right here. And thanks for coming to the show. See you next time. Bye
[44:44] bye.
