Name: Take Control of Your AI Quality in CI: Live Demo
Uploaded: 2026-05-13T17:26:20.352Z
Duration: 1 h 8 min 8 s
Description: Take Control of Your AI Quality in CI: Live Demo

Transcript for "Take Control of Your AI Quality in CI: Live Demo": Hello, and welcome to this webinar brought to you by Codana and TeamCity, in collaboration between our two teams: Codana, our static analysis team, and TeamCity, our CI team. I'm Kai. I'm a product specialist for Codana. And today, I'm joined by my colleagues, Alex. Hello. Alex, if you want to introduce yourself. Yeah. My name is Alex. I'm a solutions engineer here at Codeona, specializing making sure people get set up with our tool and no static analysis in and out. And you, Artem. Yeah. Thank you. Thank you, Alex. My name is Artem, and thank you for having me here today. I'm a solutions engineer from TeamCity team, helping our customers to build, site pipelines on top of our platform. That's about me. you. Thank you. Also, it's actually Alex's birthday today, so please be nice to him. Before we start, some housekeeping items. This webinar is being recorded and will be made to the public at a later date so that you are aware. You are muted for the duration of the webinar. However, please feel free to use the q and a functionality if you have any questions and we will make regular breaks to get them answered. And I will also, in the background, start answering them in the chat. And we will also, run some posts and regular intervals during the course of this webinar. To give you a little bit of background, a little bit of context, today, we work to shed some light on why you want to and how you can put some guard rates on your AI development cycle in as part of your CI pipeline. The first part of this, webinar will be a presentation by Alex and by Ation to give you some methodologies and some background and, why and how you can do this. And then in the second part, Atium and Alex will do a live demo to show you how this can look like. We will keep the first part relatively generic, meaning that, obviously, we will do the demo with TeamCity and Cortana, but in the the methodologies that you will see in the first part can be applied fairly universally so that even even if you do not use JetBrains tools right now, that, hopefully, you will get some value out of this webinar. However, that said, without further ado, because we have quite some material to go through, I will disappear and hand over to Alex. Thank you, Kai. And thank you, Kai, for wishing me a happy birthday, and thank you everybody else in the chat that has also wished me a happy birthday. I appreciate it. But to begin, let's look over this quote from quite a smart individual. The true power of AI lies not in replacing humans, but in working alongside us to achieve what neither can do alone. Now this is gonna be at the heart of this webinar. The gap between man and machine and the cleanliness in what you want your code to be is the foundation of this. Now to begin, the first thing to recognize is that AI lowers the effort required to produce code. Developers can generate implementations, tests, documentation, and refactors faster than before. But what does not mean teams automatically ship better software? In many cases, the bottleneck moves downstream. Instead of asking, can we write the code? Teams now have to ask, can we validate all this code quickly and consistently? The validation includes correctness, maintainability, security, test coverage, dependencies, and whether the code follows the team's standards. So AI does not remove the need for engineering discipline. It increases the importance of fast feedback loops, especially inside the CI. That leads to the trust problem. AI is widely used, but teams still need confidence in what gets merged. AI is already part of the software development workflow for a lot of teams. This is not really a future looking conversation anymore. Most organizations are either already using AI coding tools, experimenting with them, or trying to figure out how to govern them responsibly. And the reason adoption is happening so quickly is pretty straightforward. Developers feel the productivity benefit. AI can help write boilerplate. It can explain unfamiliar code. It can help generate tests. It can also suggest refactors, and it can help developers get unstuck from very sticky situations. So the productivity story is real, but trust is not automatic. Just because a team is using AI does not mean they fully trust AI generated code. And, honestly, they probably should not trust it blindly. AI can generate code that looks correct. It could generate code that compiles. It can even generate code that passes a simple test. But that does not necessarily mean the code is maintainable, secure, well tested, or aligned with the standards of that organization. That is a gap this webinar is focused on. AI helps teams move faster, but speed alone is not enough. For AI assisted development to scale safely, teams need fast feedback, shared standards, and automated controls. That is where the pipeline becomes extremely important. The pipeline gives a place to say every change, regardless of whether it came from a human, an AI assistant, or some combination of both, has to meet the same quality bar. So the point of the slide is simple. AI adoption is here, but trust has to be earned through the engineering process. Now, once AI becomes part of the workflow, the next thing that changes is the volume of activity happening in the repository. When code becomes easier to produce, repository activity naturally increases. You get more pull requests, generated changes, more refactors, experiments, dependencies, additions, test generation, a I shape changes moving throughout the pipeline. Again, that is not automatically bad. In fact, this is what a lot of teams want. They want developers to move faster. They want a I to reduce repetitive work. They want engineers spending more time solving business problems and less time fighting boiler plates. But the trade off is that the surface area for review gets much larger. A reviewer now has to look at more code, more often, and sometimes that code was created or heavily assisted by a tool that does not fully understand the business context. That creates a new kind of issue. The bottleneck becomes, can we validate all of these changes quickly and consistently? Well, the manual review still matters and it is not going away. Humans are still needed to evaluate design decisions, architecture, readability, business logic, and whether the change actually solves the right problem. But manual review alone cannot only quality check. A reviewer should not be responsible for catching every code smell, dependency issue, license risk, coverage gap, and duplicated pattern. That does not scale, especially when AI is increasing the amount of code moving through that system. So the real takeaway here is that repository activity is scaling, and the quality controls have to scale with it. CI becomes the place where we apply the same quality checks every time, not sometimes, not only for important pull requests and not when reviewer remembers or when the reviewer wants. Every change goes through the same repeatable process. But before we assume more AI always means more productivity, we need to look at the productivity story a little more carefully. There are a lot of excitement around AI productivity, and a lot of that excitement is valid. AI can absolutely help developers move faster in a lot of situations. For common tasks, repetitive work, documentation, test scaffolding, exploring an unfamiliar API, Those can all be extremely helpful. And there's also the human side of productivity. Developers often feel faster with AI because it helps them stay in the flow. It gives them starting point and it reduces that blank page friction of them just staring, not knowing where to begin. That is all positive signals, but the reality check is that productivity is not universal. AI does not make every developer faster in every situation. The more complex the code base is, the more careful we have to be. A simple greenfield project is one thing. A mature production repository is very different. In a real code base, there are existing patterns. Architectural constraints, business rules, security expectations, test strategies, internal libraries, historical decisions that may be obvious to a prompt. That is where AI can sometimes introduce extra validation work. It may generate something that looks right but does not fit the system. It could also produce code that needs to be rewritten. It may suggest dependencies, solves immediate problems, but creates policy risk. Or creates tests that increase test count, but do not actually validate the right behavior. So the message here should be not be AI is good or AI is bad. The message should be measure it. Do not assume AI generated code is faster, safer, or worse. Measure what happens in your repositories. Are we introducing more issues per pull request? Are we seeing more quality gate failures? Is fresh code coverage improving or dropping? Are duplicate patterns increasing? Security or license findings going up? This is the responsible way to adopt AIs in a software development life cycle. You let developers use the tool that help them move faster, but you also put repeatable controls in the CI so the team can see the actual impact. Now that leads into the core problem. The issue is not whether code was written by AI. The issue is whether the code meets the team's quality standard. Now the question is not, was it written by AI? The that is not the most useful question. The better question is, does this meet that quality standard? Because from a quality perspective, the source of the code is not what matters most. Humans and AI can create bad code, as well as good code. What matters is whether the final change is correct, maintainable, secure, tested, and acceptable for the repository. There are a few specific risks that show up with AI assisted development. First, code can still be wrong. AI generated code can look very convincing. It may be formatted nicely. It may compile. It may even appear to follow the pattern of the surrounding code, but it can still contain logic errors, edge case failures, or assumptions that are not true in the actual application. Second, generated code may copy existing bad patterns. AI often works from context. If the repository has duplicated logic, outdated conventions, or weak patterns, AI may reproduce those same patterns. That means AI can sometimes accelerate technical debt instead of reducing it. Third, coverage can lag behind functionality. A developer may use AI to generate a feature quickly, but that does not mean the right tests are created with it. Even if tests are generated, they may be shallow. They may test implementation details. They may not cover meaningful behavior. Fourth, dependencies may be suggested without policy awareness. AI can recommend a library because it solves a coding problem, but it may not understand whether that dependency is approved, secure, actively maintained, or compatible with organizations' license requirements. And finally, reviewers are under more pressure. If AI increases the volume of code, then reviewers may have more to validate. They are expected to move fast while also catching more potential issues. That is not a fair or scalable model if manual review is the only control you have. So the CI answer is to apply the same deterministic policy to every change. Human authored code, AI code, mixed code, it doesn't matter which as long as you're meeting those same standards. It all goes through the same quality control. That is how teams avoid turning AI adoption into a trust exercise. They do not have to guess whether the code is okay. They can inspector it, measure it, enforce policy automatically. Now that we have defined the quality problem, let's map those risks to where static analysis fits. Static analysis fits into the story because it helps teams turn quality standards into automated checks inside the CI. This slide maps common AI risks to controls. If AI produces plausible but flawed code, inspections and severity policies can help catch issues that might be missed in review. That is valuable because generated code often looks confident. It may cleanly formatted and easy to skim past, but static analysis can still identify maintainability, correctness, and reliability problems. If AI copies local patterns, then static analysis can help identify duplicate code and code smells. This is important because AI does not always know whether a pattern is good just because it exists in the pet repository. Sometimes existing code is legacy code. Sometimes it's duplicated. Sometimes it is a pattern the team is trying to move away from. If generate functionality is not tested well enough, fresh code coverage becomes an important control. Overall, coverage is useful, but it can be misleading in older repositories. A project might have low overall coverage because of legacy code, but what really matters for a new pull request is whether that new code is being tested. That is why fresh code coverage is so useful. It lets teams focus on what is changing now. If AI suggests dependencies, static analysis can help surface vulnerability and license concerns. If this is a big deal for enterprise teams, a dead dependency is not just a technical choice. It can also be a security, compliance, legal, or operational choice. And finally, static analysis helps with legacy noise through baseline. This is one of the most practical parts of the story I'm trying to tell. Most teams cannot turn on a strict quality gate and fix every existing issue immediately. That is not realistic. Baselines let teams capture the current state of the codebase and focus enforcement on new problems. That gives teams a practical first policy. Do not make things worse. For AI assisted teams, that is especially important. AI may increase the speed of change, so the first thing teams need is a line in the sand. Existing issues can be tracked. New critical and high severity issues can be blocked. Resolved issues can be measured as progress. That is how static analysis helps teams adopt quality without creating too much noise on day one. Now let's look at how static analysis fits into the CI architecture. The architecture here is intentionally simple. A developer opens a pull request or pushes to a branch. That triggers a pipeline build configuration. As part of that pipeline, static analysis runs a scan. Then the static analysis tool produces a report, applies a quality gate, and the team either moves forward or enters that fix loop. That is the basic flow. The CI's role is to run the pipeline. It handles the build configuration, it shows results, it enforces build outcomes, and gives developers a repeatable feedback loop. The static analysis's role is to analyze the code and convert the team's quality standards into CI policy. So, the CI answers, 'Did the pipeline run successfully?' Static analysis helps answer, does the code meet our standard? That combination matters because the pipeline should not only tell us whether the application builds, a build passing is important, but is not the same thing as saying the code is maintainable, secure, covered, and compliant with policy. For AI assisted teams, the CI becomes the control point. The pipeline can automatically answer questions like, did this PR introduce new high severity issues? Did it reduce fresh code coverage? Did it introduce risky dependency? Did it violate a license policy? Or did it add duplicated or hard to maintain code? That helps reviewers because it removes a lot of the repeatable checking from manual review processes. Reviewers can focus on things humans are better at, architecture, design, intent, product behavior, and whether the implementation makes sense. In the pipeline, it handles, checks, and should be consistent every time. That is the ideal division of responsibility. Humans review judgment based concerns and CI enforces repeatable standards. Now with that, I'm gonna go ahead and pass on to my colleague Artem to go deeper into the CI process. Yeah. Thank you. Thank you, Alex. So, you're gonna hear these words a few more times today, and I guess not only today. So, basically, AI is transforming the world of software engineering and, does it pretty significantly. It can now generate models, refactor the entire projects, write thousands of codes just in minutes. And, that also changes, among other things, it changes the bottleneck. And it's not it's no longer in writing the code itself, but rather in validating it. As a result, continuous integration becomes critical. In AI driven developments, CI is no longer just automation infrastructure. It's a system that creates trust. So what what does the modern CI need in this AI heavy world? There are several several key capabilities. The first one, you may you may see right now is automated testing. It's not just about unit tests, but also about integration tests, about regression tests, and trend validation. And, the rule here is pretty simple. If it's not automatically verified, it is not trusted. The next thing is static analysis and, code quality enforcement. AI is very good at generating locally correct solutions. It is much weaker at preserving long long term architectural consistency. So without guardrails, codebase can quickly accumulate duplication, complexity, inconsistent patterns, and maintainability issues. So this is why SAP appliance need automated quality gates for for this, for style, for complexity, for for for the application. The next one here is security scanning. AI can intentionally or unintentionally reproduce issue insecure patterns from public code. So security check checks need to be embedded directly into CI pipelines. That includes number of things, dependency scanning, secret detection, vulnerability analysis, infrastructure configuration, validation, and and and other things. Policy as codes. So standards should not live only in documentation or tribal knowledge. Pipeline should automatically enforce rules such as deployment restrictions, approval requirements, dependency policies, compliance controls. So the key idea here is, critical knowledge should exist as executable rules, but not in human memory. The next thing is repeatable CI pipelines. Every chain should go through the same validation path to ensure that every commit is validated the same way. Every deployment follows the same process. So in AI, in AI world, predictable systems become even more important. Shared infrastructure and, not infrastructure, but shared foundations or so called best practices. So organizations should use common build steps, shared security checks, deployment templates, standardized pipelines components, or standardized pipelines in general. So without, shared information, every team would drift differently. And, finally, deep deep traceability or, like, deep traceable history. Every artifact should be linked to its source, the checks it passed, approvals, deployment history. So when something happens, something fails, organizations need to answer some of the questions quickly, like what changed, which checks run, who approved it, which version reached the production. So as AI accelerates development, accountability and auto stability become critical. And the big shift here is this. In the AI era, CI becomes much more than just automation. That's it about, CI parts, and, I would like to pass over back to Alex and to, for sure, Kai. Hello. Yeah. Thank you very much, Matjom Singh. Thank you very much, Alex. So we have a question. Let me share. And I invite, both speakers to, share their opinion. So, overall, how should code review processes change when AI code is involved? I mean, should people replace it with AI soft or other tools? Very good question. Alex, you're on mute. Arm, do you wanna go first, or do you want me to give my opinion. first? Go ahead. Go ahead, and I will add if, if needed. Yeah. So in my personal opinion, and this may change just with how simply how fast AI has been moving. But right now, I think it's a combination. Right? And kind of what works for you and your organization. So I believe that utilizing AI to help with those AI code reviews or AI polls of some sorts, is great, but I definitely think that there needs to be some human interaction with it, or it goes blind. Many times have I seen at least working with some customers where they've adopted a very agentic workflow with extremely little human interaction and that has led to seven ones that are, hard to mitigate or repair, in certain situations. So I recommend trying it, but definitely keeping your finger on it and making sure that everything aligns right. So a combination of both. Alright. Thank you. We have another question. Let me bring this up. How can we deal with the code based cognitive deterioration introduced by AI generated code? I see code that passes all our quality controls just such as type checking, ease, lint, nip, Prettier, codana, unit integration test, mutation test, and so on, but still introduces implementations that differ slightly from the proposed software architecture, increasing the cognitive depth of the source code. Over time, this debt accumulates making it difficult for humans to debug and understand the code. Yeah. So that is a fairly common, situation, that's adopted where the code essentially just kind of starts getting away. Now depending on the current situation, and as you mentioned, you might be using Codana. So maybe we can have a deeper call where I can go over your architecture. But some situations where I've seen this happen with customers in the past is the ability to also build, at least from the Codana standpoint, to build custom inspections. So the ability to build custom inspections to as a guardrail, but also as Codana since it is basically a headless linter from our IDE's, use of plugins for style guidelines to also wrangle it in. So from here, essentially, AI and static analysis aren't necessarily things you set and forget. Right? You're constantly interacting with the AI to help build things out and change them accordingly. But same thing also goes with Codana. Right? We want to start setting things. If we're starting to notice problems, say that, any winter may not pick up. What we're going to want to do is essentially build out those guardrails either via custom inspection or a type of plug in that can also add this type of data where it becomes hard to read hard to maintain. So if this also falls into the architectural problem, right? Say for instance, it's making a bunch of directories sub directories, which is something I commonly face working with a I is either at changes my main function, to make it massive or it starts adding a bunch of repositories which makes me a little forgetful of having to go across my whole architecture. So guardrails can be placed, at least from my standpoint, working at Kodana with either custom inspections so we can start adding those guardrails or finding a plug in that might be able to help with the style guidelines. Now, once again, if you use codona, I'd love to have a deeper conversation with you and figure out exactly your code base and where I can assist with that. Akhil, anything to add? Yeah. The idea is that, there are, like, no established processes or, like, good best practices in some cases because, like, the world is changing and all the things, is quite new, and we have to adopt. So I would say that the right approach would be, like, if you still, as a human, can understand that something something wrong goes with the with the codes, like, try to address it through some, some tools, like, to automate it for the future. And, like, the great way to do it as, Alex told through the custom, custom reports. Thank you. Next question. Thank you very much. It's really good good to see so many questions coming in. No. This after more than twenty two years in software development, especially over the last two years, I've regularly seen AI assisted fixes produce false positives, false negatives, or even worse implementations than the original code. In many cases, I eventually had to rewrite the solution manually from scratch. How do we realistically solve the reliability problem of AI driven validation and automated code correction? For a change, I can probably already give my 2¢ and then I will hand over to Alex and Artiom. This is a very good point. And with static analysis tools like Codana or others in that area, the analysis itself is actually based on deterministic. So it's not AI driven. Also, the quick fixes that, for example, Cortana produces are not AI created but based on deterministic as well. And that is a way to kind of revalidate what your AI is doing. So let's say you run a scan and Khudana finds a 100 issues and you have your AI fix 50 of those, we would recommend just doing another scan with Cardano to see if they actually are up to scratch or not. So, ideally, you have kind of a self reinforcing loop of partly AI driven corrections, but always confirmed by a deterministic tool like Kudana. But, Achom and Alex, please. Yeah. Let me add. I don't have a I don't have a direct answer on it, but what I'm doing myself is I am continuously experimenting with all the new tools, appearing on the markets. So and I see that, gradually, like, the quality, is getting is getting better for me. But, of course, like, it could be different for every project, for a technology, and, you wouldn't know, until you try it Alex? Yeah. So yourself. I I'm gonna side with Kai on this one. Right? Using deterministic and those quality, checks through static analysis really helps with that. So even when you get the false negatives, right, like like I mentioned in the previous question, static analysis isn't necessarily something you want to set and forget. It's something that constantly you want to add on to. So if you're doing false positives, we wanna make sure we ignore them. If there's certain things that you want to start adding to it, then we can build on to it. So over time, having those deterministic, strategies to essentially scan across your code and making sure that it's getting to the point where you're not getting these piles of technical debt or issues while you're programming is the way I see it moving, further into the future. And also feeding, your static analysis data into the AI to help regulate it as well. Thank you. Then the next, question is, do you have any advice for policies and the enforcement for AI usage? We are employing PAC and CI, but creating effective AI usage guidelines for devs have been tricky. Oh, I I have a lot to say about this one. This one's hard. Sorry, Artem. Kai, do you have any updates on this so I could gather my thoughts on it? This is something that we hear fairly regularly from from customers indeed. So to probably exaggerate a little bit, we have it quite often where companies kind of encourage the developers to start using AI and they just say, use Claude, Go ahead. Do what you want. And then it kind of starts being a wild west for everyone. And even once you try to kind of rein this in, it can still be difficult. For example, things like shared AI use and so on. However, there is actually a new platform from JetBrains. It's called JetBrains Central. Sorry. That needed a second because we just renamed this. And the JetBrains Central, that is exactly meant to to solve what you mentioned with, kind of heterogeneous use of AI and not having a real tight grip on it. And, Drew, I'm happy to to bring you in touch or to send you some more information after the webinar if you're interested. Cool. Then the last question, maybe our team can add this to the polls because I can't do it from here, but it's, let's do the poll. Do you like to write the code with AI or without AI? So we can probably bring this in. But this also gives you a nice segue to just share quickly the result of the first poll. Does your company already use this AI to develop code? The majority says yes with 58%. Then the minority said no. Some are still in implementation, which we also see quite often. And I'm a bit disappointed because we only have one person, one vote for the obvious correct answer, which is we are on our report to our new AI overlords. This is also why you should always say thanks and please to end your AI prompts. Good. I stopped sharing this. I will open a new poll in a second. But, back to Alex. Thanks, Skye. Sorry. That that was pretty funny. Whoever voted for the overlords, good luck. Go ahead. I will go ahead and share my screen. Awesome. So diving in to more of a demo, more of what y'all came here for. So let's let's start. Let's take a step back. Now let's imagine we're working with a small regional bank. Right? And so most of the people to poll said that you were in the process of implementing. So that's kind of the mindset I wanted to go with this. So let's imagine we're working for a small regional bank that's modernizing its online banking platform. They're moving from an older slower moving system to a more modern digital offering. They want faster releases, better developer productivity, and a more responsive customer experience. But because this is banking speed by itself may not be the goal. The organization still needs confidence around code quality, security, license risk, maintainability, etcetera. And now, like many engineering teams, they are also beginning to use AI AI assisted development. That means code can move faster, but validation has to keep up. So I'm going to start from the team lead perspective. My job is to give stakeholders visibility first then drill into the project details that the engineering team needs to act upon. So from this mentality, we are a small company. We only have one team set up on Codana, and we have three projects inside of it. Now diving into insights up here in the top right, we'll see data like this. So first starting off, we're gonna have problems over a period of time skyrocket. These are our their our initial scans. So these are all the problems we see. Now generally this might cause a little bit of panic, but don't worry every code has problems. Now insights lets us see every single project. So once this grows bigger, say you start building more microservices, more tools, or what have you, this will start going up, go down, etcetera. But for the sake of this, right, I'm starting insights because it's the view that makes the most sense for stakeholders and upper management. They usually do not want to start with the individual code findings. They want to know the broader quality posture. So from here, I can look across the organization or across specific teams and answer questions like which projects have the most issues, which products have critical findings, and where should we focus attention first? For a bank modernization project, this is important because leadership needs visibility into risk without needing to read the code. This is also gives us a way to focus the conversation. If I am talking to upper management, I can filter the view to the projects, tied to the online banking modernization effort. I can narrow the dashboard by severity, etcetera, from there. So coming in, let's say we have those three projects. I could come in and I can see, hey, we have AMC legacy, our legacy code. We also have AMC online banking and Phoenix. AMC online banking happens to be the project that I have one engineer, maybe two engineers, depending how big the team is, working on building this fast iteration, say, with AI code. They're building an MVP, as fast as possible because we want to hit the market as soon as possible. So coming in, I can apply those filters targeting this one project. We can see that we added it. We have 37 problems. And then from here, we can also change severity. Leadership may not necessarily care about our moderate problems. They're more focused on critical and high. So from here, I can change the severity. So knocking down info or moderate, keeping the criticals and highs to come in and see hard coded passwords being number one. Very bad. We do not want that. We also see unused functions, bold condition, etcetera, moving forward. Now from here, I can copy this link, send it out to anyone, give anyone access to this u I, and they'll get this direct information. But here I can come in and just save as, project AMC as cell, and save it. And now I have a saved horribly spelt drop down so that you can save it for later. You can also toss it, etcetera, from there. But you can start breaking down the views as you see fit. Now diving a little bit further back, let's kind of understand possibly what other pain points we're gonna face. So coming in and looking on online banking, I could see that AMC legacy, AMC online banking are both here. Now dropping into AMC legacy, we can see that we have quite a few problems. We have a 126,000. Now I'm gonna state this here, the record I've currently seen is a 473,000. If anyone has broken that, please let me know. I love records, and it is my birthday. So diving in here, we see a 126 k. Now from something like this, a legacy project, like I mentioned on the slides, maybe we're gonna start using AI to help patch things up. Or we might just kind of keep it going until we manage to get the new system up and running. Now with something like this, we want to move things to baseline. This won't be necessarily an active project that we're gonna keep trying to add features to, but something that we wanna keep alive until our new product is offered. So I can move selected the baseline. And then from here, I can download the serif file and send it up to my SREs, DevOps engineers, so on so forth. So that way they can add it to the configuration when Code on a runs. This will let Code on a know that, hey, all these problems, we know they exist. But any new problems coming will report the current problems. And that's exactly what you want to do when you're just trying to maintain a code base. You don't wanna introduce any new problems, but you also can't really forget about the old ones. So, this will make sure that anything that you have to add patches, bug fixes, don't introduce possible new patches or bug fixes when you're working on that code. But diving back, let's go into our new online banking. So the engineers I have working on this, I've decided to set, the baseline since this is our new baby, the new thing that we are currently working on. We set the baseline and looking over it all looks good. We have 81%. But once again, we have 37 problems. Possibly we don't want to introduce this. Maybe I sent, the insights dashboard up to upper management and they're like, hey, we wanna make sure we nip those security things in the bud before we move forward and before launch. I wanna make sure that those are fixed before we possibly move forward. So for something like that maybe I would come in here. I'll dig through categories. I'd look at security. And once again the hard coded password haunts us. But also we also see vulnerable declared dependencies, vulnerable API usage, and multiple things that we might wanna pass to our engineer. So coming in, I can look into these if I want. So hard coded password, and I've already closed this account for anyone that gets wily out there. But this strip, Stripe secret key, it happens to be activated. So I can send this over to our engineer as a link or open up in my own Go land browser and start working on the problem myself. However, most use cases here, that team lead will pass it over to the engineer. Now with this said, I'm going to go ahead, pass it to Artem to talk more about the CI pipeline and its usage. Thank you, Alex. Please, let me share my screen. The screen and right here. Can you see as well? Okay. So, I'll get here, I'm logged to my TeamCity cloud instance. And, by the way, we also have on premises and hybrid, setups, But it's not, the point for today. Point for today is, AI have a project, which I have, right here. And, as I was mentioning already, the idea is simple. When AI contributes a lot of codes, the bundle the bottleneck is invalidation. So this project is built as a trust system. Every change go through the repeatable path. Say configuration is stored as code. Tests are deeply inspectable and shared standards, and pipelines are enforced through templates and further conditions. Let me start with the most feasible parts, here, which is a build chain. So if I go to the step, calls about data gates and jump into the recent execution and send to dependencies, I would I would I would see this I would see this view. Maybe I have to, yeah, to do it like this. And here, like, it's another, story and a bit another view. So instead of treating the continuous integration as a flat list of unrelated jobs, TeamCity lets me model the real validation flow, like, as a bill chain. So I have unit tests. I have regression tests, integration tests, end to end, and so on. Like, all of them are connected through, snapshot dependencies. And, like, which allows me to add the failure conditions. So I may fail a particular part of the, of the build chain because of some, results in the previous execution and thus, like, failed the entire the entire build chain. And, from here, I can, jump, to the particular, build, results and details. For example, unit test. I can go here, navigate to this page, see all the details, what's, commit, what, was taken for this for this execution, what is what's the build log, what's the performance metrics, and I can directly jump into tests. Right here, I can see what tests were successful, which of them were ignored, how much time they took to run. Right? I can, I can filter them by by by name? And, even more, I can, deep dive into the task history. And, this task history, like, show shows me the execution over, like, over time in different configurations and in different, you know, projects configured inside my TMC instance. And it is very useful because I can because sometimes failures, could happen, like, in a certain branch or, like, on certain circumstances. And from this page, I can quickly find it out. Now about, now about configuration. Let me let me open my in my ID. Obviously, it's gonna be it's gonna be IntelliJ. So the important thing is that, like this trust on the system, inside CI is configured, like, not manually, but started as a as a code in repo, like, in the same repo where my, where my program is actually located. And it allows me to do several things, like to build the diff, to track the history, to evolve, the configuration itself through pull requests. Right? So add additional checks, for the configuration itself. And for YI heavy projects, this is especially important. Let's take a closer look of what's what I have here. For example, I define I define the version control that should be used for the, for the project. I define some some templates with, like, as a basic as a basic, thing that should be used in every in every or selected configurations in my in my projects. I define I define, let me show you one more thing. I defined dependencies. For example, in this, in this build type called validate all, it's gonna depend on all the on all the configurations. So this one gonna be say gonna gonna be successful if all the snapshot dependencies were successful. So it means that, pipeline is not, hidden knowledge. It's a part of the of the code base, and you can you can add your, for example, EA agents to also to modify or, like, to be aware of the of the CI structure. The next thing I want to talk here is about, the templates that I've mentioned. So it's and it's called shared CI Foundation right here. So it's a baseline for all build configurations. And instead of copying the same steps into every build, TemCity, lets me define the shared behavior once and reuse it in in all configurations. In this project, the it defines, for example, the artifact rules. It's how artifacts should be should be stored. It defines the Gradle build cache directory, some additional features like, commit status publisher for for GitHub. So all my builds are uploading the results in into the GitHub. Some basic failure conditions. For example, I have here execution time, forty five minutes. It means, like, all bills should not should not exceed this this time limit. But I can, go but I I can still go to a particular configuration. Let's take a look into the static code analysis, yeah, right here. And I can define even more, like, which is, by the way, also about Skadano. And I can define even more granular failure conditions. Right here, I, I run the inspection and collect the all the errors, in this build. And, if, like, some errors are found compared to the previous successful build, then, like, this build's gonna be stopped, and the entire chain gonna be interrupted. And the same in the second, in the second, in the second condition, which is about warnings. So, for example, if comparing to to my previous run, to my previous successful builds, more than 10, warnings were introduced, then it's also gonna be, gonna gonna be stopped. So, yeah, so this is a key shift. Instead of, like, asking developers, like, to to, like, to remember, to refer to some documentation or some best practices, like, team seat allows you, like, to put it into the code and just to rely on this automatic approach. Let's go back to my browser for for this for this view. We will check-in before yeah. About about the, chain in general. So what I wanted, to add here So for AI heavy projects, Temcity gives, like, a practical trust layer. So builds are connected into repeatable chains. Continuous integration is configured through codes. Test results can be inspected down to individual test history. Templates give every configuration a shared baseline, and failure condition or conditions turn standards into automated gates. And this is what lets team use AI generated code without lowering confidence. So the goal is not to on is not only to move faster, but the goal is to move faster with evidence. And, that is it for my part, and I would like to invite, Alex to the stage. Thanks, Artem. Awesome. So I know we're approaching time, but definitely wanna show you some stuff on essentially repairing, your code base when working with AI. So with that, let's go ahead and open up my IDE. And so now let's look at this from the perspective of a software engineer. Right? So from that AMC banking application that we were talking about, we now have an engineer working on that project. So here is a code base that I've essentially built, using AI. So I've configured it, set things up, we ran it, AMC's running, and we get it to work, but we're starting to hit a lot of those common issues that you see when using AI in your code base. It makes us faster, but we're starting to hit some repeated snags. So using a JetBrains IDE, right now I'm using Golang, you'd be able to see something along the sorts of vulnerable dependencies. Now, Codana works with bunch of IDs including Visual Studio, Visual Studio Code and CourseAir, and they all give this information. But coming here, I could see that I have some vulnerable dependencies. I have crypto version 42, and j w t. So I can come here along the lines, maybe using Juni, and say, hey. Maybe I wanna update this to a more stable version. So coming here, I could see upgrade to version 0.45 may help with this. So coming in, I could say, hey, let's update crypto, 0.42 to 0.45. Now, in a lot of cases, this might be easy, especially when you're starting out with this program. The dependency might just be simply called into one method or you have one method simply just using these plugins. But in cases where the code base might get higher, using AI might be the more beneficial route to go around by saying, hey, please clean this up. And then usually, it will be smart enough to then start detecting where it's called. If not, it'll be snagged in errors and static analysis can also pick that up. So coming in, I'll go ahead, ask this to run. But while it's running, I can go ahead and start looking into some other things that I might want to repair. So coming over to my server side analysis, maybe there's some things that I also want to take care of along the way. So coming in, I could see let's check on moderate and we could see declaration redundancy. Now this is a group that is fairly common especially in AI generated code. So declaration redundancy, I can come in here and choose one of these and it'll send me directly to the project or the file where this line of code currently exists. So diving in, I can come in here and I can do a little bit of reading of this problem. Or in situation currently am, I can also highlight over it and I can see a little bit more information. So I've noticed that this is essentially a quick fix. So most engineers, pretty familiar with the ability to do quick fix. Inside your IDE, you can have your IDE do the fix for you. But like I mentioned earlier, Codana is essentially the headless version of a JetBrains linter. So from here, I can configure all of these things to fix by themselves. So instead of repairing it right here which I can do, which would probably be the thing I do right now But maybe something to make it so when the pipeline fires, it will fix these redundant problems that don't really require my attention. So with that, I would come into say my codonn. Yml file. In here, I can add a special condition called fixes, strategy. Now this flag takes two different values. We can either use cleanup, which will allow us to automatically clean up, more of the low hanging fruit. So minor safe cleanup inspections, word changes, or maybe this redundancy where I'm adding too many areas to it as well. Now fix a strategy also has the ability to apply. So apply means fix everything, even the logic changing bits as well. Now my, my recommendation, highly use cleanup, but when it comes to apply, test it out. In some cases, it's extremely useful, especially destroying things, building it from the ground up, and especially when you're articulating in a a I assisted type of engineering process. So for this I'll go ahead and choose cleanup as my method and then from there I will go ahead and keep this updated So that way it will work when I run the pipeline. Now when this is configured, it will then change everything, when I do a pull request. So I'll do the fixes and add it in accordance. So as I'm here, I'm going to go ahead and do code go mod tidy to continue updating that version of that vulnerable dependency. And then here we can see that it's starting to work as it's moving on. Now with that, oh, go ahead. We'll end this webinar. Great. Thank you very much. I would ask Artiom back on the stage as well. So there we go. We have one last question. Let me share. And that is, what does a practical AI ready CI pipeline look like today and are there any strong examples from the industry you can share? That is a very broad question which I'm not sure we have enough time for, unfortunately. But if you are interested, please feel free to reach out after the webinar and we are certainly happy to to give you examples how that can look like. Yeah. Definitely, Please. we would be glad, like, to maybe to even to provide some, tailored demo and see whether TeamCity is something that, fits your needs. Thank you. I also so just go through the last polls really quick so that you've seen it. There is the question about how to ensure high quality. Quite a nice spread of different ways with but it's good that, it seems that everyone is aware that you should use, tools and that you should have an eye on it. Then the question about how are you to prefer how do you prefer writing code. So it seems also, relatively clear with a mix of both. Also something that we see fairly often. And last but not least, CI pipelines, runner front runner, GitHub actions, GitHub pipelines, Jenkins, and, also quite a few TeamCity users. So very good. Alex, Atjem, if you don't have anything else, I would wrap this up. So we are four minutes over time. I really hope that you got some value out of today's webinar. Again, we will make the slides available afterwards for you to review. And last but not least, I will also share a QR code. So if you want to make a photo of this or we are always super happy in listening to your feedback to improve this for the next times. That's it. Thank you very much. Thanks again for your time. It was a lot of fun. Thank you, Alex. Thank you, Artiom. And I'm looking forward to seeing you next time. Thank you very much. Thank you. Bye bye. Thank you. Bye.