Imagine configuring complex enterprise applications by simply describing what you need with no drag and drop and zero custom coding required. Join us for the inaugural session of the Unqork Ask the Expert Webinar Series for an exclusive technical breakdown of the UnqorkAI Build Agent.
In this 45-minute session, you’ll see how the Build Agent unifies the full software development lifecycle (SDLC) into a single experience. You will learn how to turn prompts into configured, multi-module applications, automatically generating build plans, comprehensive test plans, and documentation inside a secure, enterprise-grade platform. Unqork’s proprietary guardrail and reasoning engine applies governed, deterministic rules to every build ensuring you eliminate code drift, avoid unvetted AI code, and cut maintenance costs. This session includes a dedicated, interactive Q&A component where our Sales Engineering, Technical Advisory, and Product teams will answer your live and pre-submitted Build Agent questions.
What You'll Learn
Alright, everyone. We're two minutes past, so we're gonna kick it off here. As I mentioned in the chat, we have a jam packed agenda, so we're just gonna start up the webinars to make sure we can run through everything and have a chance to run through everyone's questions as well.
Thank you so much for joining this morning, this afternoon, this evening, depending on where you are in the world. My name is Jim. I lead the Unquirk community here, and I'm super excited to kick off our first ask the expert webinar.
This is a long standing series we're gonna be running called ask the expert where we connect you all with our internal experts on new features, on best practices, on how tos, on use cases.
So please make sure that this is the first of many that you join to get the latest and greatest from Unqork. You can register and join everything in our updated community. We have an events page. We have an updates page, and you can find everything you need to join the ask the experts and keep up to date on everything else we're doing. I'm gonna pass it over to Kunal just to introduce himself in in one second, but I appreciate everyone who asked questions and submitted questions beforehand.
We have a ton of questions we're gonna go through in the second half of this webinar. But, also, we may run out of time, so feel free to add your questions to the chat. And we'll make sure if we don't get to them during the webinar, we can get you an answer afterwards. But without further ado, I'll stop chatting, and I'll pass it off to Kunal so we can get started.
Okay. Hello, everybody, and and welcome to our build agent session in our ask the expert series. My name is Kunal Gokle. I am a manager on our solutions engineering team. We're gonna have two other folks joining us, particularly for the q and a. One is Craig Sapata, our VP of solutions, and the other is Erdem Ozcan, our VP of Agentic AI. They have been very instrumental behind the scenes in our launch of UnqorkAI, so they'll be able to join and and answer some questions later on.
So our basic agenda here is just going to be an overview of the build agent itself, how you can really plan for success with the build agent, in the terms of BRDs and artifacts. And then once your apps are created, how you can optimize and document your processes along the way, specifically by using the ask mode of our build agent. And then we'll have plenty of time at the end for some q and a.
So when we talk about the build agent's capabilities, there are several different things you can do.
Planning and building is a is a major part of it. So what you'll see is that when we give the build agent something like a BRD, artifacts, screenshots, whatever else, we'll come up with a with a plan, an implementation plan. This is something that you'll have the opportunity to review, to provide input for, and and to really be specific on what you want the configuration to look like when the build agent gets into the build mode. Similarly, there's going to be a build mode, as I mentioned.
It will configure applications based on your BRDs or whatever your requirements look like, and there's rollbacks. There's version control. There's auto saving within that entire process, so you're never locked into what the build agent did. You can always roll it back.
Within that plan and build mode, it's gonna come up with test plans. You can create your own test plans if you want. The build agent will come up with a sequence of tests depending on the complexity of the application involving happy path tests, you know, tests of logic and calculations and everything like that, and you'll have the opportunity to interact with that as well. Similarly, when we talk about documenting and optimizing, you'll be able to interact with the build agent to really specify how you want future builds to go for similar use cases, how you maybe want to optimize those types of things, as well as having the build agent give you feedback on how things can be improved.
And what I kinda mentioned is, you know, the build agent is not designed to be a lock in feature. It's not a black box feature. It's an accelerator to build your enterprise applications using Unqork. You have flexibility.
The the goal is to ensure that the build agent does as much or as little as you want it to do. It's always gonna give you recommendations and context of what the task is. Final decision is always yours. You can iterate with it.
You can change the plans. You can roll back, you and can specify every step what you wanna do here. Similarly, it's never just gonna throw its hands up and say, you know, I don't know what to do. It's always gonna give you options.
So when we talk about the tasks and modes that are included within the build agent, when you when you begin a conversation with the build agent, it's going to create a task. And and it's...
That's basically the conversation thread between creator and the build agent where you build a specific feature within the module. Couple things to note about tasks. First of all, it's isolated. So every task starts with zero context of your past chats or decisions.
It does have access to the things that that exist within the workspace, but your previous chats are not going to be, you know, included in context with your new task. It's it's private and persistent, and this is a question we get a lot. So it's saved across your reloads, but user a cannot see the chat history of user b. They can, of course, see the configurations.
They can see the versions, but you can't see what...
You know, as user a, I can't see what user b specifically discussed with the chat agent. But these tasks...
The task planning within the build agent is very aware of limitations. So if we have a particularly long PRD, if we have a particularly long build, it will understand that, you know, it can break this out into phases instead of building it all at once. And that's really one way that it that it prioritizes responsible token usage as well.
So the three modes you see at the bottom, I kinda mentioned them. The ask mode is gonna be read only analysis. We'll kind of go into what you can get with that. But, you know, whether it's optimizing builds, optimizing PRDs, or or whatever else, you can you can do that.
Plan and build mode, that's going to be what you're gonna see a lot of later, but this is going to be, you know, creating a step by step plan. You have to approve it prior to execution, and and, you know, that's gonna be best for building your complex production ready apps. And then just the build mode. That's for, you know, if you wanna do a rapid prototype, a POC, you just wanna tell it what to do and walk away and come back and have it done, the build mode will be able to do that.
And and, you know, part of that as well as we get into the plans is...
And you're gonna see this more, but it's a structured proposal. The agents creates this before any of the build begins. It's completely approval gated, so no changes are executed unless you select build plan. Right?
It's going to organize it into very clear actions. It's gonna give you a high level assessment of what it thinks, and it's gonna give you detailed component specifications, logic test cases, and verification plans, as well as showing you where it is in that step. Right? So as you start to think about creating good artifacts, you know, is everything in your requirements?
Are they accurate? And and are you defining the scope very clearly in terms of what's in scope and what is out of scope? Because like I said, the build agent will never throw its hands up and tell you it can't do anything, but you would rather control the scope than have the build agent guess about a scope. That's how you get in the scope creep.
Right?
Kind of along those lines, it will it will... It's always gonna contextualize your requests. What you'll kind of see with what we input in terms of BRDs is you don't need to have some sort of very specific format. You don't need to, you know, have specific necessary information. It will work with the context you have. So the better your context is and the more optimized your VRDs are, you know, the better the build agent is gonna be able to do. Otherwise, it's gonna... You're gonna have some more back and forth with it as it tries to specify things, and that's gonna kind of increase your token cost as well.
So now I'll switch over to the, platform. Bear with me as I pull up my screens. So what we've done here is I've just popped in some artifacts for a legacy incident management screen. I can show you what those artifacts look like.
Right? We might have something like a screenshot. This is just a legacy screen. You know?
It's a it's a ticketing ticketing incident management screen, and we have something like a pretty simple BRD. So I can also just flash that for you as well.
And what we see here is really just that, you know, it's a single module application.
Here we go. It's a single module application, but this defines, you know, what our data looks like, what the functional requirements look like, some logic as well as UI UX.
So with... You know, some of these are gonna be longer than others. Some of these incident... Some of these VRDs are gonna be longer than others depending on how complex you want it to get. And what you'll see is, I just asked it, you know, please read these specifications and and create a module. Right?
So, again, you're not locked into what this decides. You always have the opportunity to modify the plan, to work with existing plans, whatever.
You can kind of look at what it creates.
It will give you some context, what the approach is, why it needs it to happen. It'll give you what the user journey looks like as well as... I skipped over, but the desired behavior. There's also a Salesforce integration right here. So that's pretty pretty nice that once you've configured the integrations on the back end, the build agent is gonna be able to set those endpoints up within the module.
You can also see that it it shows you what the smart components look like, so how it's going to be able to reuse things across different modules.
It also gives you a data module... Model, so a full, you know, field type and persistence, readout, and then it's gonna give you what the actual modules look like as well as the test. So you can kind of see it. It looks at things with an edge case with priority matrices, make sure that some of the calculations for priority matrices look look good, as well as just different things that it goes through, making sure that SLAs are are, you know, up to up to requirements. And then at the end, it's gonna give you an execution plan. So this is how the build agent is gonna run through this process.
What you can see here is I can actually highlight one of these things, and I can add comments so I could provide feedback at any stage. We've kind of already already gotten to this point, but you can see that I could request changes here as well. I could type it into the build agent itself.
And this is where one major advantage of the build agent is really that it becomes deterministic once you've decided to build this plan. If you upload these artifacts five or six times, you know, it might still be slightly different every time with the same artifacts, but it's never going to add or remove anything once the plan is approved. This can be kind of different from other code assist tools. They may still come up with a plan, but after you approve that plan, you might still see some hallucinations.
Right? So going through this iterative planning stage, we can, first of all, ensure responsible token usage. So it's not building then coming back and rebuilding to implement changes. And, you know, it's not going to be be hallucinating or creating any type of code sprawl after the fact you're building within our system guardrails with no net new code.
So let's go ahead and switch back over to the slideshow.
Okay.
And so so one major point to kind of emphasize here is that we we still believe in the SDLC. Right? So you wanna make sure your requirements and artifacts are are fully scoped, of course, before plugging them into the build agent.
But but what we're... What we also see as a useful useful output from the build agent is is the... Giving the ability for business and IT groups to have easier collaboration. Right? The build agent is gonna accelerate your build with the lesser numbers of developers required. It also will give your, quote, unquote, citizen developers more of an opportunity to configure within the platform.
But from there, we still... You know, it's... We still think engineering teams should be reviewing configurations, handling promotions, managing your back end services such as SSO and API configurations, and everything else required to move an application to production. Right? The built agent is, without a doubt, accelerator. It's undoubtedly going to reduce your time costs and your maintenance costs, but the evaluation importance for us is still of the utmost importance. Right?
And and as we kind of discussed, making sure your requirements are very good and and very thorough will help the build agent really speed up that process. For those of you who are are, you know, traditional developers or use the old Unqork, you know, that that development time, the actual build phase can can take a long time. Right? But but in this case, the build agent is really going to be able to accelerate that.
So what we can talk about is is, you know, what what is a plan versus kind of a quick BRD.
What you kind of saw with that ITSM module was a quick BRD. It's a single module application. We had a we had a screenshot, and we had some basic things within that module. Now given the screenshot, it's a single module.
It did a pretty good job of that. Right? We didn't need to have a 10, 20, 30 page BRD for that. But what I'll show you after this is an application where we kind of did need a longer BRD.
Right?
As we discussed, ensuring your requirements are fully scoped and and looking at some of these criteria can truly explain what makes, you know, a very planned BRD work. Again, if you wanna do a rapid prototype or an internal POC, the quick BRDs may make more sense. But things like, as I mentioned, clearly defining the scope, specifying what each component...
What each data field should look like, making sure that the logic is clearly defined, the KPI formulas are clearly defined, and and making sure that the data data model is totally unified, especially when defining things like role based access control. When you get into a quick quick BRD territory, you know, as I mentioned, you might see some scope creep if it's not clearly defined. Though they're just gonna have to guess and and ask you more questions and kind of figure things out by itself, and and that's where you get into some some black box logic. If you've defined what all the logic fields should look like, then it's a lot easier.
Right? But if it's a little more ambiguous with with metrics or or black box logic, you know, you can get into situation where the build agent is is having to do things on the fly, and edge cases. We always care about edge cases. So what we did in the background...
And I'll go ahead and shift back into the platform now. What we did in the background is is we created a customer onboarding application, one with kind of a very well planned BRD and one that kind of had, you know, less planning that went into it. Right? So what we can see here is this is the good BRD.
It created this customer onboarding intake application.
It created a lot of a lot of different tabs as we're onboarding a customer. Right? You go through everything from what the applicant type is, specific information about the entity, personal information, contact information, as well as, you know, information that would be needed during an onboarding process when it comes to ID employment information as well as some regulatory regulatory things as we get into, you know, a a situation of doing due diligence. Right?
We go into our disclosures area. This was all built out by kind of the good BRD. It looks good. You know, it's it's pretty thorough.
We uploaded a quicker BRD, and you'll see it's it's not quite the same. It doesn't have the same depth of information within there. You can see as we get into some of the required things that that would be necessary as we get into an onboarding process when we're looking at due diligence.
You know, it has... It... It's still not bad. It has a lot of that information in there, but some of the specific things that we we did to the not as planned BRD was, you know, not specifying what some of the logic should look like. For a lot of these things where, you know, we were asking them to identify their relationship, we didn't give the fields that it should should have. Right? Whereas for the good BRD, for every one of these fields that have a drop down for every one of these tabs, we define pretty clearly what should be on each screen.
So the build agent, like I said, will never throw its hands up and do nothing. In this case, you can kind of see the the output, which is... You know, it's it's quite a different different look and feel. It's quite a different experience.
And at this point, you'll have to go back and start iterating to add things within the build agent, which is gonna increase your token cost. You obviously could still drag and drop as you've done traditionally within Unqork, but, you know, if you go to the build agent, it will increase your tokens. And if you go to the drag and drop, that's gonna increase your time. Right?
So I'll go ahead and switch back to our slideshow now, and we can start to discuss...
Oops. Sorry. I think I skipped ahead a little bit. There we go. So we can start to talk about what the ask mode and app documentation looks like.
So as mentioned, this tool doesn't have to just be used for building apps. It can be used to provide feedback and structure for your existing tasks that may need some brainstorming or improvement before getting to the point of a build. So one example we see a lot is with legacy code.
So if we're injecting a file of something like COBOL, you know, in in government applications, COBOL is is used quite a lot. We could ask the agent for an approach, ideas for architectural improvements, help understand why the process for legacy modernization is is tremendously useful, especially for larger lifts. You know, we we frequently get requests around this, and and the Asmode has done a very good job of that. Right?
It's... It...
That's why we call it legacy modernization instead of a a one to one transfer. Right? We don't wanna just pop in that old Cobalt code and say, hey. Create this in Encore. We want some input. We want some context to convert it to Encore, but in a better, more scalable, more efficient way.
In addition for legacy Encore customers, the ask mode in the agent has been very useful for looking at older Encore configurations and and understanding where bottlenecks can occur.
You know, for those of you who are familiar, maybe you have older configurations that use complex data workflows, kind of advanced grid operations or or bulky API calls. Right? These types of things within the the, you know, Unqork one point o realm have maybe slowed down some applications, and the AskMode has done a very good job with some of our new smart components to to make those a lot more efficient. Right? And you can kind of see on the screen what some of those things look like, specifically what the agent can't see. So it can't pull submission data. It's not gonna get live API responses.
It's not gonna be able to interact with the environment configuration. All of that is still left to an administrator to do.
And, you know, for issues that depend on a live state, you can still use your dev tools or service logs or API debugger or the express preview bar. And the agent can help interpret findings when you share the results, but it can't go dig into those itself.
And so we can kind of show what one of those examples looks like.
Again, I'll go into the platform here, We can see, you know, I I asked the build agent in ask mode with our good BRD. You know, how can I use this BRD to create a documented repeatable process for all of our future onboarding applications? So if we make another onboarding application, these these all look slightly different, we don't have to go back and rebuild it. We can use this BRD. We can use existing plans to create these a lot quicker.
Right?
So it's read the BRD in full, and it says, you know, this is great to turn it into reusable pattern, and it's gonna give you the feedback on how this works. Right? So it's gonna tell you, you know, build out the architecture first. So build out your schema modules, your back end API modules, everything else, and, you know, be able to leverage smart components as as the biggest reuse lever. I believe we're gonna have a future session on smart components. I know I've mentioned them a lot, so so you'll have to you'll have to attend one of our future sessions.
And then as well, you know, how we can document our data model and everything else and then create a plan template. It also gave you some optimization ideas, as it kind of says, these are some structural improvements you can make, and then it tells you, you know, we can go into a formal documented build plan.
But but the ask mode will give you an idea of where to start so that you're not just plugging stuff into the build agent, having it build, seeing what spits out, and then kinda figuring, wait. Maybe that's not exactly what we wanted. The ask mode will help you kind of plan out ahead of time. I personally like to have a pretty good plan before I get in the building itself.
But, you know, we... And and we we can use... Leverage the ask mode to give us more of that feedback. If you wanted to throw in the bad BRD, if you're kind of really stuck, it will increase your token usage a bit, but you could still have the ask mode give you feedback on the bad BRD, tell you how to improve it, where areas... You know, where additional fields can be added, as well as, you know, if you want the BRD or the... If you want the ask agent to actually give you specificities, it'll do that as well.
Okay.
So let me switch back in here. I believe now we're going to get to some of the presubmitted questions we had.
So let me go ahead and...
Jim, I don't know if you wanna add everybody else into the front stage here.
Okay. So it looks like everybody's in now.
So I'll I'll take a first pass at most of these. And then if if Erdem and Craig have something to add, then then we can get into it. But is there a recommended structure to the prompts? I think we've kind of reviewed this a little bit as we've gone, but, you know, it's it's...
The intent should be clear. Right? You shouldn't over specify minor details and remain vague on kind of core business logic. Right?
A long prompt shouldn't be used instead of, like, a well defined goal.
For any of you who have worked with LLMs before, you know, prompt engineering is something that we get into, those best practices kind of apply here. Be concise, be clear, be specific about what you wanted to do, and and kind of get into a situation where you you aren't having to build agent guessing as much as possible.
I don't know if, Craig, if... And, Erdem, if you have anything to add, please just just chime in.
So is it recommended to build an app with a single prompt or multiple smaller prompts? I think this really depends on on what what you're kind of getting into. Right?
For longer builds, I kind of mentioned that the build agent does a very good job of advising you to break it out into smaller things. Right?
I think it really depends on what issue you're looking at. If you're telling it to build a new module according to a BRD, that can be done in a single prompt. Right? If you're, for example, looking at a dashboard and you want specific components changed, say you want a KPI to be calculated in different ways, say you want a graph to be displayed in a different way, say you just want the overall layout and style of an app to look a different way, those might be better done in multiple smaller prompt prompts. So I think what what our approach usually looks like is start with overall planning, the overall infrastructure and architecture of the application itself, maybe do that in a single prompt. And then as you get into, you know, smaller, more specific changes, that's where your multiple smaller prompt... Prompts will most likely become more useful.
Come on. Can I say something about So I think the mental model that I like using in in? Like, when I think about this type of questions is that, like, think about yourself as managing someone.
Right? There's always this trade off around whether you wanna give the whole big vision at once and expect them to do things at once, or do you wanna give it piece by piece? I wouldn't really think about, like, you know, the length of the prompts or, like, single prompt versus multiple prompt as, like, pieces of text, but I would actually think about it as how big a task am I asking to do. And I think there are multiple things that go in that.
Like, in what I'm asking, can I be clear enough if what I'm asking is too big? Or even if, like, I was clear enough and the whole thing came at once, am I able to validate that big thing? Or would I prefer to do it piece by piece and then validate each piece as we go? I think that's that's really the underlying question that, you know, I like to ask myself when I do this trade off.
And I think, as you said, the... There is no secret recipe or, like, you know, one like, you know, one size fit all thing here. Like, know, it's it's really about thinking about your your your specific task and then thinking about whether you would you would prefer to go in smaller pieces and validate those pieces incrementally, or is there any advantage of giving the big context and try to do all at once? Because maybe a lot of these different components are going to be interdependent to each other, and, like, you know, going incrementally is not gonna get you to the best place.
Yeah.
Wonderful. Thank you, Adam.
Okay.
So when should I use the build agent versus when is traditional configuration more appropriate?
So a solid... A rule of thumb here is really that the AI is gonna excel at structured, pattern heavy, well specified builds. Right? Traditional config is best for, you know, very nuanced logic, quick tweaks, or those kind of deep institutional edge cases. So what we're using UnqorkAI for is, you know, net new modules built from these clear BRDs, things like repetitive build outs. Right? So forms, dashboards, validation chains, things that you might have been able to to build out using snippets in the past, but but, you know, it's it's... It still will take some manual configuration. The build agent does an actual excellent job of prioritizing the usage of smart components.
Clean logic. So eligibility rules, data mappings, calculations, the build agent will be able to do that very quickly. And then kind of what I mentioned is this initial scaffolding and and architecture while... Wireframes that are then intended for downstream refinement. So putting together that architecture for your application, the building is just gonna do that so much quicker than than you manually creating 20 to 30 modules. Right? What we also see it useful for is if you're doing some sort of a proof point and and the requirements are a little ambiguous, you know, you can run it first, create a wireframe, create kind of a version one, then go back and and get that discovery more more clearly hammered out. And then I think we've all we've all been there before.
Where the traditional config is useful, you know, several people in the audience probably have some experience with Unqork. If if there's a ten second tweak where you already know what you wanna do, go ahead and do it. If you wanna make edits to the style sheets or work within the service admin or or, like we said, really look at some of those complex edge cases, then then you'll be able to to go the traditional config route.
Okay.
What can I submit with my prompt to guide the build agent? Block diagrams, Figma mock ups, LLM schema's existing code. I know that the the repository of the file types we can accept are constantly expanding. Basically, what I'll say is all of your normal, let's say, quote, unquote, normal file types, build agent will accept.
I believe it will accept Figma mock ups. You can you can drop in code files, or you can put the code into a Word doc and save it as a PDF and drop that into the into the build agent. We want it to be as flexible as possible. I don't know, Erdem, if you have any point you wanted to add to that, but I think that it's it's pretty flexible overall.
Yeah. Yeah. I think, you know, you can give, you know, a lot of different file files. The the... I I saw that somebody asked for the file types. It's... The extensive list is actually provided in the documentation.
And you can put, for instance, Figma mock ups. You you though you cannot actually put the Figma file itself. You have to export it into a image file or a PDF file.
But, you know, you can actually put a lot of information in, like, either in text form or image form.
You can also copy paste existing code or, you know, yeah, give code files if you wanted to.
Yeah.
Can I use the build agent to generate test plans? Yes. You you saw that already, actually, as as I showed some of the plans we developed. As I mentioned, the build agent will come up with its own tests based on the context of your requirements and and what you've, you know, communicated to the build agent itself, but you always have the ability to add your own testing into those plans.
The build agent comes up with with a pretty good list of tests, but, of course, the more comprehensive list of tests will will definitely come from you. And and this is where...
It's just another point to really say that, you know, you should always be reviewing your plans. We want the human in the loop at the planning stage before the build stage starts so that the the build agent can just go and not have to keep doubling back and asking you for clarifications. So if you don't like some of the tests that the build agent has come up with, you can iterate with it and ask it to remove it. If you like them but you want more, you can do that as well.
And, you you have some flexibility, but the build agent will most certainly generate test plans.
Why would I use build versus plan...
Build versus plan and build? And, similarly, why would I wanna turn off auto test and auto fix? I kind of discussed this as well during our our presentation, but it really depends on on what you want your output to be. For those rapid prototyping POC type use cases, maybe you just use the build mode and you can turn off auto test and auto fix, for example.
Right? If you just wanna walk away and see what it does and and get something quickly, you know, the auto test, auto fix, and plan features will add time. Now if you're doing something that is starting to be prepared for production, we would always recommend to stay on build and plan and auto test and auto fix just because that allows the human to be in the loop. That's going to make everything clearer, and it will most likely catch any, you know, bugs, any validation errors it would find that, otherwise, if you have those modes turned off, it won't.
Basically, the idea underlying point is that for quick, you know, rapid prototype or POC applications, you can use the build mode. For something that is more designed to eventually hit production, you can get into the build versus plan mode.
What is the best way to handle requirements changing midway through a project?
So this is this is a a interesting question. I think that that this can look a lot different in a lot of ways.
I think that that as I...
One thing I mentioned is, first of all, that as a as a velocity driver, the build agent is going to do a very good job of, you know, module scaffolding, smart component construction, and and coordinating, you know, multilayer builds. So the build agent will enable you in a lot of ways to have the architecture of the application kind of kind of hammered out so that if those requirements change midway through the process, if within the module requirements are changing, if there needs to be additional things, if the scope has creeped a bit, it can kind of run with that without having to tear it down and rebuild everything.
That is definitely one way that the build agent kind of accelerates compared to other Codesys tools that if that scope changes halfway through, they may tear it down and rebuild the entire thing, which increases your token cost. Now, of course, this is a this is a unique question in the sense that, it can always kind of look a little bit different, but I think that taking the build agent with the approach of start big and then start to really zero in on the specificities so that the infrastructure is in place and then you can start to make those those more fine tuned changes as you move through, that that would be the way I would go with it.
And, Erdem, if you have anything to add, please go.
Yeah. I I can add some... One piece of information. I think, you know, if if the requirements change midway through a project, I will say that the build agent is going to be your friend because it is very able to, you know, when you ask for a change which might have impact over a large body of modules, it's gonna be able to trace all these dependencies and then do all these changes at once.
Whereas if it was a single user who might have a, you know, partial understanding of how the application is gonna work, like, these kind of changes in requirements might be scary, situations. So I would say that the build agent is going to be extremely useful when, you know, midway to the project, you will have some updates to be done and... Which may have impact across the modules, and it's gonna help you figure that out fairly quickly and and consistently.
Yeah. I think I would echo the same. Right? Like, if you think about it, what would it be like if you were...
If you didn't have the build agent and you had a change in requirements in the middle of a project? Right? To Burdom's point, you now have to figure out, oh, great. How many modules across this application will this change impact?
Right? And I think similarly, you know, it kinda...
A bit of, like, along the same lines is, like, documentation, I feel like, is always one of those things that as soon as you finish writing it, it's out of date. Whereas, if you have this change in requirements or you want to know, like, oh, what is this module doing or what is this application doing and ask the build agent, you know, back to the asking portion of it, tell me what this is doing. Because I I have a change of requirements coming in. I wanna make sure I I understand exactly where the code is because, you know, the document I may have read is, you know, six months out of date, and that could be significantly out of date when thinking about changes you might need to make as well.
So Cool.
I see there are so many questions in the chat. I promise whatever whatever we don't cover, someone is gonna reach out to answer your questions. So I see there are a lot of questions. So do I need to review the configuration built or just a plan? You need to review the configurations built.
That is definitely what we would what we would suggest to be doing. The built agent is a fantastic accelerator, but like like anyone developing, you know, manually, it can also make mistakes. As we mentioned, the the governance and and kind of back end configure... Back end confirmations are still a big part of the SDLC, and it's something we still want you to keep top of mind. So the configuration should definitely be reviewed, but we hope that by really submitting a very well tuned plan that your, you know, after the fact debugging time will be reduced, and that is what we've seen so far from from any test we've run.
Yeah. And a little bit, again, echoing Erdem's previous comment about what role you're playing as the the person giving instructions to the build agent. Similarly to, like, well, what if you were giving, instructions to the junior developer on your team and they complete their work? Do you just ship it to production, or do you, you know, do some review of their work or, you know, pass that work onto a a QA team or what have you? So I think, again, sort of similar steps there, but... Sorry. Erdem's organization.
Yeah. One thing that I wanted to add was, like, how do we validate the or review the configuration? I think, you know, you can obviously use the ID and look visually about, like, the configurations and then dig into the, you know, details. The other thing that you can do, and I would highly advise that, is also use the build agent to, you know, ask questions, ask about formulas, like, the the things that are being implemented in those components. At least, you know, that would give you the references where you you should pay attention to.
And, so I think, like, you know, build agent also accelerates the review of the configuration. I'm not saying that you should solely, you know, rely on the answers that are given by the, build agent to your questions to complete your review, but I think you can still leverage the build agent by asking it questions to show you where a specific thing that you need to pay attention to is implemented, how is it implemented, etcetera. And then whenever you think it's necessary, you can also go look at, like, the the actual details in in in the ID.
Cool.
How can I make sure the build agent isn't making changes to parts of the application my team is working on? So there is a setting within the build agent that that you specify, you know, how much edit capability it has. So, for example, you can have one of the modes where it will ask you before it makes any changes to any module at all. One mode in the middle is, you know, it it will make edits, but it will ask you before creating or deleting anything.
And then one mode is let it do whatever it wants. So so, again, if if you're working in a shared workspace, if you're working in a shared application, you can ensure that the build agent is not making changes to other modules that someone else is working on. And part of that is even if if if someone else is working on something right now, you can leave the chat and come back to it later once that module is done being worked on by your coworker, and then the build agent will be able to continue. So it retains its context. You can close the window. You can leave the environment and come back, resume that task, and it will be able to do that. It's not that, you know, if you close close the task, it's gonna lose everything that was in there, and you have to restart.
So we have those Sorry.
Go So ahead. One other thing that I would add, from a workflow perspective is that the plans also discuss in details what updates are going to be done to which modules. So you can also look at that if you're, like, concerned that certain modules are not to be touched. You can actually say in your prompt, like, I want you to build this, but I'm not allowed to, you know, touch these modules or actually review the plan to see if the if the build agent is planning to touch certain modules that you would not want it to do. And then you can actually give it feedback to find workarounds, whether, like, you know, your your task can be implemented without these things that you should not touch to.
And on top of that, you can also, like, leverage the security mechanism that has just expressed where, like, you know, it it it cannot... Like, you know, if you put the control mechanism where, like, it has to ask before an edit, it cannot, like, edit without your permission.
So you can actually leverage these different control levers to, you know, plan your updates with regards to the things that you can modify or cannot modify, and then and then use those control mechanisms to ensure them or enforce that.
Cool.
Okay.
Can a build agent help with debugging one of my existing modules? It absolutely can. What what can kind of accelerate your time as well is is, you know, if you've identified the core issue, say it's a UI issue, a validation issue, you can point the build agent specifically to that, and you can tell it what's going on, and it and it will, you know, enter a debugging process that can speed up your your time for debugging. Similarly, say it's something with an API and you're receiving some sort of a response code, you can put that directly into the build agent, explain the behavior, explain what the API is returning if it's a failure, and that will give it a lot of context.
And even with an API, if it can't fix it by itself, itself, it will give you kind of a sequence of what you can do and what you might be able to diagnose to fix the issue. So, you will have the build agent there to help you debug. You also have the other ways of debugging that Unqork has always offered. So we definitely see the build agent as an extension to your debugging capabilities to hopefully speed it up so that you are not chasing to find the origin...
Origination of the bug. Rather, you can explain what the behavior looks like, what the response code looks like, and the build agent can hopefully speed that process up for you.
I would also say that the build agent does not have access to the runtime data. But if you happen to observe bugs on your environments, you can also copy paste traces, etcetera, to give additional context and pinpoints, help him... Help build agent pinpoint the problem. That's something that you can do manually by copy pasting those traces and logs. Great.
So how can I hand off work to my team and make sure their tasks have proper context? The best answer for that is that in our... One of our soon upcoming releases, we will have an... A capability to retain context at a workspace level. So that context sort of will will serve as a bridge of information across tasks and users working on the same same workspace. So we definitely have that that in mind. And and with our upcoming release, that's gonna be included.
Awesome. I know there's lots of questions in the chat. We are gonna follow-up with every one of these questions. So thank you, everybody.
Awesome.
Thank you, everyone. Just a a quick plug of the coming soon before I close it out here. So this is the first of many ask the experts that we're going to host. Next one is on October 22 on smart components following on November 5 on optimizing Unqork applications, and then every two to three weeks after that until we get to the end of all the things you need to know.
So please go to community, register for those events, make sure you bring your questions, especially the hard hitting ones so we can get you clarity and get you answers. And then another plug, a new series we launched today called tap into Unqork. It's a bit rudimentary for you all now that you're experts in in the BuildAgent, but we're really gonna be starting at at, you know, home base stage one with these episodes. They're bite sized.
They're short form content. They're on community under five minutes. Share them with your team. Share them with those that wanna get into Unqork, wanna learn how to use UnqorkAI.
They'll be really detailing how to use best practices, settings you didn't know existed, and things to make your life easier. I wanna thank our three experts, Kunal, Craig, and Erdem. Thank you so much for answering everyone's questions.
For everyone that is here and attending, you will get a recording of this session, so don't fret. You can go back and revisit everything. And thank you for those who submitted questions beforehand and those who submitted questions during. We're gonna make sure to address everyone's questions.
So just keep an eye out from your partner customer contact. They'll give you an answer to those questions to make sure you have clarity on the things that you've asked. Thank you again to everyone. Really appreciate it, and thanks for making the inaugural session of ask the expert great.
Take care, everyone.
