Name: Claude Code for State and Local Governments
Uploaded: 2026-05-22T18:32:41.161Z
Duration: 58 min
Description: Claude Code for State and Local Governments

Transcript for "Claude Code for State and Local Governments": Thanks. It's great to see folks in the chat joining us from around the world. As a quick housekeeping, we have a recording of this session will be shared via email. You will see a q and a portion for questions. Please make sure to submit questions. We'll have a dedicated section at the end. And then also, we would love your feedback, as well. Please keep typing in the chat, by the way. It's it's awesome to see folks, joining. I'm Michael. I lead our state and local government partnerships team at Endropic. And I'm here with Lizzie. Hi, everyone. I'm Lizzie. I'm on the applied AI team here, topic. Amazing. Today, we're gonna go through, a few things. So first, just a little bit of a backdrop of what's happening with AI, especially in coding in state and local governments. And then Lizzie is gonna dive in with a couple of cloud code demos. And then lastly, we will do some q and a and then, on how you can get started. But first, we wanted to just know where you all were at. So we had a little poll just to see, how familiar you are with, cloud code. Do you see the poll there? Alright. Well, keep filling that out. And, yeah, it'd be great to see some of the results there so we get a sense of who else in the room. Okay. Cool. So seems like there's a good chunk of folks who are brand new to Cloud Code, some that are actively piloting it. Amazing. Okay. Thanks for filling that out. With that said, maybe I'll share a little bit of historical background. And I think the broader current that's happening now that Clark Cote is a part of is this idea that AI can now do real software engineering. And that has huge implications for how you all as governments buy, build, and maintain systems. I'll just say that this slide is a little bit stylized. So you may have a bit of a different journey within your agency, whether you're in the I know we have some friends from the federal government, some international, a lot of states and localities, but I'll just start from the left. And originally, government of sort core started with cobalt development on the mainframe. And then there started to be more outsourcing right after, you know, late nineteen eighties or so, starting with the DOD trickling down to states and localities as well. And you started getting, of course, whether it was outsourced or custombuild.net, Java apps, and a lot of system integrators that were building these different big monolithic legacy systems, Medicaid, UI, DMV, etcetera. And then as there was this migration underlying from on prem also to cloud, in the twenty tens, you started seeing more costs, commercial off the shelf, as well as SaaS vendors. I'm curious in the chat if this resonates with you all. I'm guessing that you actually have this these these layers in your different agency systems where you have some of each of these over time. I know some of you have modernized. Some of you have still have areas to modernize. Something started changing in late twenty twenty four after the chat moment and after with it with the onset of LLMs, which is GitHub Copilot is really the first AI tool with AI autocomplete. And in the ID, that started speeding up your developers. Right? And that also started speeding up the SI developers that you have. This has now accelerated tremendously with Cloud Code. As of, I would say, really December of last year and early this year, it's only accelerating. We now have this new paradigm agentic coding, of which Cloud Code is is the leader. And Cloud Code is really this AI agent that is a general software engineer. So it can do things like read all the COBOL code that, or dot net code that you may not even have developers on staff for. It may not be well documented. It can document that code, help you migrate it. It can help you do note new code development. So this is a pretty big paradigm shift in terms of what that means for your ability to buy, build, and maintain systems. So that's just a little bit of a backdrop. And we're starting to see some really exciting things, uses of cloud code, in government. So I wanted to highlight one first on the left with more custom development and speeding up teams. I think we have some folks here on the call from Singapore GovTech, some of our friends internationally. And this is a quote from their CTO where he said, the numbers are pretty eye opening. I'll skip to the bottom with cloud code. It's a much smaller team. It's one data scientist over two days, roughly 0.4 person weeks. That's about a 30 x multiplier in productivity. And at GovTech, which is the central IT in Singapore, they are using cloud code to build a lot of applications for their agencies, whether they're department of education or their hospital network, things like that. So that's really exciting, right, being able to do this sort of this type of productivity lift. That's more on the greenfield side. But there's so much legacy code in those layers as we talked about here in US state and local. So I'm also really excited about code modernization. We did a pilot a couple of months ago with Christian Napier and the team at Utah's division of technology services, And we're so excited to see, things like users completing a month's of work in two days by modernizing old APIs, by taking very complex, forms and compressing the time to do that in different programming languages. And we're starting to see that across different localities. We have small counties in places that are completely rewriting custom applications. I know many of you on this call are also either piloting or in deployment already, but I wanted to sort of highlight these two, examples of impact that are happening today on custom development as well as on legacy modernization. So that's the backdrop. With that, I'll turn it over to Lizzie to talk about what is cloud code and get into some of the demos. Awesome. Thank you so much, Michael, and apologies all. My Wi Fi has been a little bit spotty today. So until Claude can fix that, you might might have to deal with with a little bit of that, but thank you for your patience. Awesome. I couldn't be more excited to be talking to you all about Cloud Code today. As many of you already know, Cloud Code is our agentic coding tool that allows your developers to delegate complex tasks while remaining fully in control. Really importantly, cloud code is purpose built to harness all of our model's greatest capabilities and intelligence. They're actually built in conjunction with each other such that cloud code can accomplish the most for your residents. It's really optimized again for how Cloud thinks about code, how it reasons about multistep and complex problems, and many developers are finding a ton of utility with it already today. Alright. I'm gonna go ahead and ask Michael to skip to next slide. Thank you so much. Cloud Code, again, was built for developers by developers and runs exactly where you work. So for all the government clients that I've worked with, many of whom are on the call today, you know, I see them work across the CLI, so directly in the command line, across IDE extensions. I, for one, am a huge lover of Versus code, but if you're using JetBrains, IDEs, we work where there as well, as well as across our desktop, web, and mobile apps. All of this, of course, is built on top of the agent SDK, which is also available to invoke programmatically such that you can build cloud code into, for example, your CLI or internal tools. Awesome. So here's some of the common patterns that we see in state and local government. Again, cloud code is meant to be your partner across the entire software development life cycle from discovering, designing, building, deploying, and then supporting and scaling your code bases. So for example, modernizing legacy code bases, writing tests, documenting previously under documented code bases, debugging, really underspecified errors. Cloud code, again, is your partner in extending the capacity of your team to handle complex development tasks. Excellent. Awesome. I'll just jump in real quick. and say. this is, these are some of the UCS's across the technical software development life cycle, but it's such a generally powerful tool. Like, I'm not particularly technical, and I'm using cloud code for hours every day to help me build slide decks and, you know, analyze data and all of these other things. I'm so glad that you said that, Michael. Yeah. Really, how I think about cloud code is that although it was built for developers, it really democratizes, this modality of building for folks who don't have a developer background. So I really see people across PMs, analysts, data folks, and otherwise jumping into club code and finding a ton of value. It's really, really cool to see someone who never thought that they would be in the command line or writing code, write code for the first time, just see that light bulb go off. So thank. you for adding that. Awesome. Well, see, I don't know I don't know if you knew this, but my parents are software engineers. Oh, And didn't know that. I I never thought I would we have, like, a mug growing up at home that has, like, a a Java mug. Now I finally know what that is. And I never thought I would be writing code, but, you know, with Clark, I I'm doing that. too. Well, So, you should have invited them because we're working with the Java code base today. Great. Next time I, okay. yeah. Cool. Next time I expect to see that mug. Awesome. Great. Well, the next thing that I wanted to cover really is where to get started with cloud code so that you can take what you learned from this webinar and actually get started today. Where I've seen teams be the most successful with cloud code is really when they spend a good amount of time just teaching cloud how to work within your environment. Just like onboarding a new employee, you need to teach cloud essentially where your guardrails are, where the context is, how to get up to speed on your projects. So that's what our demo is gonna focus on today. So let's go ahead and jump right in. The first thing that many of you will recognize to do to set up cloud for success is to set up a cloud m d file. You can think of cloud m d files as cloud's instruction manual for your code base. Essentially, where, for example, to find tests, where, for example, are your conventions, what are your best practices. Without a CloudMD, Cloud uses general best practices, but those may or may not be your best practices or conventions. Right? So best practice is to set up a Cloud MD file, and it's as easy as typing slash init in order for Cloud to scan your code base, which is especially important, right, in government space specifically state and local government context where the person who wrote that code, you know, may no longer be within your workforce. And Claude can act as a really, really helpful tool in order to understand how legacy code bases specific specifically work and how you can, essentially take on that code base and and make it, legible for the rest of your team. Great. Next slide. Next step is permissions. I know that this is a huge topic for government customers. At least my government customers specifically is how do we actually govern AI. Specifically for Cloud Code, we allow you and your administrators to set up, define, allow, deny, and ask list in your manage setting files. Those files then propagate for all developers such that all developers are following your, organization's guardrails. In this specific example, right, Claude is gonna stop and wait for a human in the loop for, anything, for example, that is pushing to get, and then the list is a hard no. So reading secrets, dot d n d files, destructive commands, and so on. The way to think about this, right, is that you're setting permissions that you're you're not just trusting Claude to behave and respect them. You're actually setting deterministic boundaries that Claude is operating within, which is especially important, right, in strictly regulated environments for state and local government work. Awesome. Next slide. Great. So now I wanna talk a little bit about MCP. MCP or model context protocol is the standard way to give Claude context and access to systems outside of its execution environment. So you can think about this as Claude's eyes and hands, the way that it affects and reads external state. So for example, pull logs from Sentry and help me understand, a reported outage. Really, when you're thinking about MCP, or a good sort of rule of thumb for thinking about MCPs that if you find yourself copying and pasting a bunch of context in the cloud again and again from external systems, it's probably a good time to set up, an MCP server of which there are many out of the box and available for you already with Claude. Awesome. So here's our last concept before we're gonna jump right into the demo, skills. So a skill represents an opinionated workflow or task that you'd like to teach Claude to do. The one specifically on this slide has to do with extracting requirements from an RFP. And the way to think about skills is that there's really two flavors. They're all specified in markdowns, such as plain language and sometimes a little bit of executable code, but most of the skills that I see in my day to day are really just specified workflows. So think about, for example, if I notice Michael does something especially well. Michael is, like, a close colleague of mine. And, I want to replicate exactly what Michael can do, for example, in writing policy memos or in briefing clients. In other words, I would walk through and tell Claude in natural language within a skill, here's exactly the steps to follow in order to replicate this specific task for my organization, which is one of the main reasons that you'd use a skill, right, to inform Claude about how to do a particular task for your organization. The second reason you might reach out for a skill is actually for something that Claude isn't quite good at yet, but I'd really recommend trying that thing first a few different ways with different prompt prompting skills as I think that you'd be really surprised what Claude is good at. So reach out to skills when you really wanna teach Claude something that it doesn't already know how to do out of the box or specific for your organization. Excellent. So now let's put this all together before we jump right into the demo. So ClaudeMD, again, is Claude's map for your project. It's static facts about your project that Cloud probably wouldn't be able to glean just by reading the code. And again, a tactical note here is that we really wanna keep CloudMD files brief and concise, structure them just with the information that Cloud needs in order to be effective, and really nothing more. The general guidance is around 200 lines or less. And then the next piece here is permissions. So permissions again are constraints specified by your administrators that then flow down with allow, ask, and denialists for all of your developers. These are things that by default, Claude cannot do no matter what a user applaud asks for. Next up is MCP. MCP again is Claude's eyes and hands. So live access to read and influence state outside of Claude's execution environment. And then lastly, which we just covered are skills. Skills you can think of as specializations. You've given Claude a superpower to increase his ability to perform well on a particular task. Awesome. I think with that, we might be ready to get into the demo. Awesome. Yeah. Lizzie, before we go in, I Please. maybe we can do one question. I I love that folks are asking questions. that. That'd be great. Yeah. So there's one around, I think it's relevant to nontechnical users as well. Anil asked, persistent question, our org is cloud code versus co work. People feel like they need to use code for full functionality even if they aren't building software. Joel also put in chat, are you gonna talk about coworker? Also, I'm just curious for your your quick take on, like, code versus coworker? Yeah. Great question. So for folks who, were on for that slide where I mentioned the agent SDK, both CoWork and Cloud Code are built off of the same SDK, and so they contain many of the same capabilities. Although, of course, their system prompt and the way that they're set up is slightly different. They're really targeted at sort of different personas or different audiences. Again, a huge goal of ours at Anthropic is to diffuse the intelligence and benefits of AI safely. And so when we think about rolling out new products, a huge part of that is how can we get the most people, to have an moment with AI? And part of that, right, is that knowledge workers, a lot of knowledge workers actually don't wanna work within cloud code. Instead, you know, a lot of their work actually happens more in a chat interface or a systemized systematized tool, download to the desktop like, CoWork. So I'd really just think about it as through a different modality for a different set of users. Each has its own strengths and a lot of overlapping capability, and I'd really just encourage you to figure out, you know, which harness works the best for you for most use cases. I know, Michael, I'm curious your take. I find myself switching between them a lot. I reach out. to cowork a lot more when I want a particular output like slides or deep research, and I reach out to collect code when I'm dealing with data. That's sort of my split. Yeah. I think I I tend to agree with that. Yeah. I know there's a lot of questions, so we'll we'll get to to some of those more, in a bit. But I think you guys are in for a treat with this one. Awesome. Great. Cool. I might ask you to pull down the slides. I don't think that I can click screen until perfect. Thank you so much. Awesome. Great. So I'm gonna go ahead and share my screen here. So in this demo, I really wanna accomplish two things with the remaining time that we have. One of them is showing you all how I'd approach implementing a federal policy change to a real code base. In this case, we're gonna be working with the state hosted integrated benefits application, which I'll talk about in a little bit. And the second is to actually kick off a modernization sprint. And to do that, I'm using Minnesota's legacy state hosted integrated benefits application, which is a point in time view of an open source benefits application from the state of Minnesota. One thing I wanna note is that this is not what they're currently using, and, hasn't been updated in large part because they switched over to a different system, but I think really points out, like, the value of open source for this community. And I'm so thankful for both Code for America and for State of Minnesota for making this public such that we can all learn from it, and practice on it as well. This a link to this code base is actually public and should be in the docs section if you'd like to follow along. Great. So previously, right when it was live, residents were using it to apply for SNAP, cash assistance, and emergency aid. And for those of you in the room who are developers, a little bit of background, it's a Java and Spring Boot app with about 5,500 lines of form configuration in a single YAML file. So let's say, for example, that, I, show up to work one day. I'm on the development team for the Minnesota benefits in this point in time. And I see that I have a policy memo in my inbox or in Google Drive that contains summary of changes that I then need to apply. In this case, changes that have to do with work requirements that I now need to encode. So let's say that I'm working from this and now I need to make this real for the application itself. I'm gonna go ahead and hop over to Cloud Code. So again, I'm accessing Cloud Code in Versus Code. You can access it in our web app, as well as in terminal directly or another IDE. Great. So I'm gonna do what I always do when I am new to a code base, which is asking Claude to help me onboard. Give me a high level explanation, that an audience about technical and nontechnical folks will understand. Claude is great at sort of translating code into something that is understandable no matter your technical background. And it's doing this right in part by reading the Cloud MD, which you can see here. The Cloud MD file again is Cloud's instruction manual. So it's taking a look at the project overview, any, relevant test commands that it should run. And then down here, you'll see, a bunch of conventions that are useful to keep in mind as we build that cloud might not glean, you know, just from reading the code. With that, let's go ahead and take a look at the overview that Claude spun up for me. So it says pretty much what I just described to you all. It's Minnesota's online benefits application. It allows residents to apply for programs like food assistance. And how it works basically is that it guides people through a questionnaire and then routes them intelligently based on their answers, generates a document that can then be shared with counties, and then ultimately delivers them. Great. So this is super helpful. Now that I understand a little bit more about what this code base does, let's actually go ahead and ask you to help me plan changes for this policy change. So I'm actually gonna tap through and go into plan mode which actually directs Claude. I don't want you to make any edits. I just want you to read these files and help me come up with a logical plan. Great. So I'm gonna go ahead so you guys don't have to watch me type, which would definitely be the slowest part of this demo. I'm gonna, ask you make it. a little. bit bigger? Oh, absolutely. Let's see. Yeah. Is that. a little, bit better? Awesome. yeah. A little bit bigger. Yeah. That's good. Okay. Great. Happy to make this bigger on my screen too. Let me know if folks have another request like that. Awesome. Great call out. So you'll see that Cloud Code is spinning up an explorer agent. And this explorer agent is gonna read through my entire code base. So this might actually take a minute. I think that the, a good opportunity right now is for us to switch to something a little bit different which is our modernization sprint in the right hand side here where I have a different instance of Cloud Code. So I'm actually gonna switch back over to my browser here. And for code modernization, I really want you guys to take a look of at this code modernization plugin that my colleague on the cloud code team who specializes in code modernization actually spun up. This is public today and reflects a structured workflow that Claude can walk through. Again, thinking about the concept of skills that we just talked about that guides Claude code through a very, very particular set of steps to arrive an outcome, in this case, code modernization. So you'll notice here, I'll just give a quick, quick, overview that essentially through a few different commands that will run, this brings Cloud Code through, a few steps of assessing, mapping, extracting rules, creating a brief that acts as sort of feature gates, reimagining, and then transforming. We are doing this by invoking particular, commands here that then spin up specialized agents that actually analyze your legacy code, extract the rules, and then audit and test on your behalf. So a lot of my mental load, goes from actually documenting line by line to actually evaluating outputs themselves. Great. So let's go ahead and head back here, and we're gonna kick off our modernization sprint on the right hand side here. Great. So I'm gonna say, please invoke code modernization, modernize, assess, which is gonna kick off an inventory of my legacy code base, languages, line counts, and so on. You'll notice again that this is reflecting and enforcing my permissions rules here, actually allowing me to decide where cloud code should go. Is it okay for it to, take a look at, you know, which library it should be using and so on outside of our current working directory? Let's check on on our agent here. I see that it's still working away, and so I'll keep, approving some of these quick bash commands so we can get this agent kicked off. Excellent. So I see it's off to the races. Well, both of these agents think. I'm curious, Michael, if any new questions have popped up in the q and a that would be good for us to take on. Yeah. So let me see. There is, see. There's a question about so there's actually one about CloudMD, SkillMD, which is, can we not put all the information in skills into a CloudMD file? Why are they separate files? That's such a good question. So, again, a huge point of why we're separating these is to protect, the context window. For those of you who are a little bit new to working with agents, the context window reflects the amount of information that Claude can take in, in order to remain productive in a session. So think, for example, if Michael and I were having a really long conversation and, by the end, you know, I was asked, what were all of the things that Michael said in that conversation? I probably have a pretty hard time. And although Claude has a much better memory than me, it could too. And so the reason why we split up skills and Cloud MD file and ask you to keep the Cloud MD file pretty brief is such that skills can be loaded just in time. So in this case, right, Cloud doesn't need to know about the modernization skills or commands, or even some of the test skills that I'll show you later until they're actually useful. So So we're progressively disclosing to make sure that cloud is just getting the most relevant information at the moment it needs it. Awesome. Great. Another question is about collaboration, which is. how do you best collaborate with others, devs and nontechnical on your team, whether on a code base or with, dot MD files to make sure you're not building in silo? Yeah. Great question. So Cloud MD files actually, are hierarchical by default. This is not a great example of that as it's a relatively small code base, but imagine, for example, a monorepo with many, many different subdirectories. Each subdirectory can actually have its own CloudMD file such that teams, for example, who are working on more platform features, like audit logs can write their own CloudMD file for their subject matter expertise. And then, for example, feature teams can write the same for their particular feature. So one way of doing that is to write a CloudMD file just for your particular team and put it in the relevant subdirectory. Another way that I've seen teams collaborate is really just by, relying on their, you know, Git workflows and existing software development life cycle. Cloud code is really not meant to sort of replace what you already have, in terms of the ways that you're collaborating as a team other than, you know, accelerate you and now allow you and your team to move much faster and more efficiently. But instead relies on the existing primitives within your environment already. The reason being, you know, we don't want to sort of disrupt the way that you're already working. We really want to accelerate it. Cool. Awesome. Lizzie, I think you have a permission prompts, but, yeah, while that's happening, there's a Stephanie is asking a question that's exactly related to this, which is I see you have two things going in parallel. One, updating the benefit to reflect a policy change and, two, modernizing the code base. Can you give a her question is, can you have an idea of the size of scope being tackled, how complex of a policy change it is, what part of the codebase is being modernized, and how long would something like that normally take. Absolutely. That's a great question and a great segue into the plan that Cloud Code just generated for me. So, again, what we are, implementing actually, is a change to the form logic within this questionnaire, in order to implement the, new roles present in section ten one zero two here, specifically expanding, the age range as well as, removing categories of exemptions as well as adding, work activity requirements, and exemptions from, work requirements for this new policy. And so it's a pretty big change. You know, it has a good amount of nuance and it's a code base, for example, that I'm not super familiar with. I would say, I'd be really curious if there's anyone from Minnesota who worked on this. I'm curious sort of to hear from you on how long you think that this would take. But let's go ahead and work through the plan, and then I'll provide an estimate, at the end. This will show you again, this is a plan that Cloud Code wrote for me based on the policy memo that it grabbed from Google Drive with MCP. And so I think this will provide us a really good sense of exactly what's gonna change. Okay. Great. So again, here in the new flow, we're adding new sections in order to reflect exemptions and work situations. We're making many, many file changes. Right? So adding a condition anchor, adding page definitions, modifying a workflow section, as well as the application data parser. We also need to change a bunch of downstream properties such as, all of the translations into Spanish. From there, we'll actually improve this and actually run some unit tests as well. But I would say this is a pretty big change for a, code base. I think it would take me at least a few days, in order to actually understand the code base and then action on it. Great. So I'm just gonna take a quick look here and make sure that I agree with the plan. Alright. This looks good to me, so I'm gonna go ahead and approve this, and then Claude will go ahead and start implementing. So you'll see all of these diffs coming up here, actually reflecting changes in that YAML file again that reflect the form flow as well as changes in page definition between disability and work situation as those reflect the exemptions that we just talked about. Adding lines, in order to handle some of the conditional logic, adding some, variables here to the data parser, and now it's reading files and making other updates, within the form itself. Again, I think a lot of the work here is actually understanding the code base itself and making safe changes and then testing those. So we're gonna leverage Cloud Code to do that for us as well. Let's go ahead and check out, what's going on, in our modernization sprint. So we'll see that, actually a huge part of the value of what, my colleague on the cloud code team has created is that it creates outputs that help me understand the architecture, the data flow of this, now legacy app. So let's go ahead and find that in analysis architecture. Great. Awesome. So you'll see that I have now gotten an executive summary of exactly what's going on in the system, a full system inventory, and technology fingerprint. Excellent. So we'll take a look at that in a second. Right now, looks like we finished our changes and now we're compiling. We're gonna restart the app to make sure that it boots, and so we'll see, while it waits to start up. Great. So it's gonna work through that on its own. In the meantime, let's go ahead and take a look at the high priority fixes. Again, it's giving me a quick glance at the architecture. I'm gonna move this into preview mode so we can see it a little bit better. And I'll keep an eye on this as well. Great. So now we're booting again with MPM run demo. All of that looks good to me. We're starting up the app again. Okay. Great. So, again, this plug in gives me a good sense of our technical debt, all of the top 10. Great. So I'm seeing there's some exemption, exception conversion issues. There's some security findings that I should take a look at and then some documentation gaps as well that are worth taking a look at. Excellent. And then here's our effort estimation. Looks like 18.4 person months. So that one actually has a more accurate, estimation here as well as a number of people. Great. And from here, we can move on to a recommended modernization pattern actually customized for my code base. So phase one, security hardening, spring root migration, and then an actual structural rearchitecting. Great. So we'll let that sit for a second while we move on here. Okay. Great. So all changes compile on that. This looks good. I'm just gonna go ahead and check this out in our browser. Okay. Great. I see that this is up and running and all good. So I'm actually now I actually want to test this out and make sure that the changes actually reflect what I would hope to see. And for that, I'm actually going to reach out to a skill. I set up this skill to help me quickly and easily test changes. Again, this is a really good use case for skill. This is something I'm gonna do many times over the course of this federal policy change. And it allows me to do this really, really quickly and is hyper specific to my environment. So again, really good, use case for a skill here. Again, all of this is written just in natural language so both I and Claude exact exactly understand what's going on. Great. So I'm gonna go ahead and invoke this and then we'll go from there. The first step in this skill is for Claude to test out a few of the paths. So for example, different scenarios of nonexempt snap applicants just by making curl commands to the app. And the next step is that it's actually gonna do a visual check, in my browser utilizing Claude in Chrome. So this is actually Claude operating on my browser. It's really safe, especially in this case because it's just an example demo app. But again, this is not me, clicking through. This is Claude actually proving to itself that it's done what it needs to do. So I'm gonna go ahead and split screen with Claude in Chrome as well as Claude in here, in my IDE so that we can see it, reason, and think through all the different steps required. This is especially helpful, right, so that Claude can gut check itself. I don't have to take screenshots and put information back into Claude. Claude is gonna see, look, it found an error already. Looks like, we have a missing county selector. So it's gonna take a look at that and actually suggest a change. Okay. Great. Awesome. So it found a workaround, but I noted that change for next time so that we can take a look and actually ask Claude to correct it. Awesome. So here, Claude is clicking through the form in order to make sure again that the form matches all of our requirements laid out in the policy demo. Okay. Great. So now we're navigating through different types of assistance, be it SNAP, cash assistance, and so on. I'll scroll down a little bit so folks can see. Next, we have one more step around expedited, and then we should get into the exemptions next. Okay. Alright. One more screen here. I think what's really helpful for me too as like a designer of different systems that people interact with is to actually gut check and use this in order to think through the user experience without actually clicking through it myself. I find that sometimes I get pretty desensitized to clicking through forms that I've built. So excellent. Here are the exemptions that we talked about that we added. And now it's verifying the continue button exists and everything looks good. Okay. Great. And then it's checking out current work situation, which is also a part of our new policy change. Great. So in just a few minutes, it seems like we've effectively, implemented at least a huge part of our work in order to apply this federal policy change and then ultimately had Claude test it out itself. Great. And as a result, I have this GIF as well that I can download and show to my team to prove at least, a first run at making this policy change. My next step would actually be to run all of our unit tests, but I just wanted to show you guys one more skill as well that I made for the purpose of this demo. So something that I noticed as Claude was going through the cloud and Chrome steps here is that it's quite a few form pages. And although my all might be necessary, I just wanna see or have a sense of what the user experience would actually be like in terms of how long it would take them in order to get something done. So I built another skill called trace flow, which actually acts as a persona affected by the able-bodied adults without dependence changes and traces their full path through the application. This comes up with a, an estimation of how long it would take them, any repeated questions. It helps me understand, you know, any improvements that I could make to the form while we're here implementing this change. Great. So again, on the, modernization piece here, my next step would actually be to go ahead and map all of the dependencies. So because we have a little bit of time, I'm gonna go ahead and kick that off too. The next step is called modernize map. Modernization, Map, I believe. Awesome. Oops. Slightly wrong one. I'll go ahead and copy directly so that I don't, mistype here. Here it is. Modernize map. Excellent. Excellent. So what this is gonna do is actually build a dependency and topology map of the legacy system, the call graph, data lineage, and so on, and visualize it for us so that we, in addition to this architecture flow, have a good sense of, an artifact that we can take a look at. Great. So we're still working through this trace flow, but essentially what we have now is a working federal policy change that we're now testing these or experience effects, of implementing that change. Again, we have kicked off, a sub agent here, which again is going to, protect the overall context window from bloat. And looks like that just, finished up. So here's the full report again. And so this is a a persona that Claude generated, in order to reflect what someone might go through now that they have these work requirements. So here's the flow trace of all of the pages that they're seeing. They're seeing landing, inter basic info, contact info, and so on. Little quite a few screens here and then an estimate of how much time they would spend per screen. So ambitiously knowing that they, assuming that they would know all of the pieces of information, it would take them about sixteen minutes, and the two new pages maybe add around thirty five seconds. I'm curious for folks who work on these forums. You know, is that a good estimate, or should I adjust my skill? Seems a little bit quick. But great. And then here I see some UX recommendations. So screens that could be combined, abbreviated, any redundant questions that I might be able to cut out, and then any drop off risk. So for example, any personal details, that are just a huge stretch of yes or no questions. It noted that there was no progress indicator and so on. So these could be improvements that I could think about making, that I think are actually present in the current, Minnesota benefits. So they are they already made these. Great. Awesome. Okay, great. So it looks like this went ahead and finished and now is in analysis topology. So let's go ahead and take a look at that. And I actually wanna open this up so that we can review it together. Here it is. Great. So in just a few seconds, Claude took a look at my entire dependency tree and made me this nice map so that I can understand exactly how this works as I think about modernizing. Here's the data lineage that we were talking about earlier where pages config YAML, controls a lot of the flow of the logic of the application. And then here is the user view of exactly what happens when a user is walking through the application itself. Of course, we can iterate on these mermaid diagrams, and inform Claude. But right now, right, I have a really good plan or idea of what I can take on between my assessment and my architecture And then I can call those other plan other, commands rather to extract the rules, write me a brief, and then ultimately harden and test any modernization changes. Based on the assessment, it looks like a lot of this is gonna be migrating libraries, as well as, downstream dependencies. So, not bad at all and, especially for for something that hasn't been touched in a few years. Great. That was mostly what I had planned for the for the webinar today. I'd love to see if there are any questions. I wanna make sure there's plenty of time. And I'll keep Cloud Code open now just in case folks wanna explore a different path or take a look at something that we ran previously. Awesome. Thanks for that, Lizzie. Thanks. Yeah. I see some good chatter in the chat about this. Just a reminder to folks to keep please thank you for putting stuff in the q and a and uploading. We'll get to that section soon. But one question that was directly relevant to this one, Yeah. Carly, who I think worked on this, she says designer on this. Amazing. Can Claude visually show what changed and how it compares to the former app application? I'm I assume she's talking more about UI. So the Mervyn diagrams were great, but, she said if it curious if completely new pages were created or just new selections on an existing page. Absolutely. That's a great question, Carly. So especially if you guys are using cloud in Chrome, cloud can, of course, understand and see which files were changed and the downstream changes there. But I would love to just have the opportunity to even ask cloud. Cloud can, of course, see what it saw, in context already with cloud in Chrome. So I'll just ask for the new pages that you added. Can you give me a quick assessment of how the UI, changed? And because I had a really robust Cloud MD, right, Cloud is taking a look at the existing designs and actually working from existing UI modules. So here is a quick list or overview of all of the new screens. There were just two added. So headers, sub headers, checkbox questions, as well as anything that's missing. So for example, as opposed to other pages, we're missing explanatory tests text as well as context or context fragment, meaning an icon. So something to add next time around. So cloud can definitely interrogate and look at the UI that it's created and then offer any improvements. Alright. Let's switch over to q and a now. Awesome. Thank you for that, Lizzie. Would you be able to k. Let's see. Here. And it looks like the first question the most uploaded question from Kevin. Many state environments are in a position where systems have been updated for decades in response to new policy and regulation without the time needed to unwind prior policy often results in overlapping and conflicting code. And also many times the biggest issues are organizational in nature, silos, fragmentation, decision making, gridlock. So what ways have you seen these tools address these types of issues? I think that's an excellent question. And, two thoughts, and and I'll let let's say I'll let you weigh in on the technical side too. One is this approach of doing documentation and code based understanding first for all those layers can help you upfront understand the dependencies, between the layers and then sort of the the good and the bad code to your point. I think on the organizational side, what we're seeing is a number of folks, use co work and other things actually on the policies themselves on things like organizational structure to help inform internal discussions about what needs to change, from a process perspective. Certainly, this doesn't solve all of those organizational problems. Right? But if it can be a tool and input into better decision making and into visualizing what might be wrong, then it can help with some of those things. Yeah. Absolutely. I think that question really stresses for me the importance of a lot of the design choices that were made in creating that modernization plug in. The step that we didn't ultimately get to because I wanna make sure that we had time for q and a was extracting rules. And that step actually will surface, rules that are in conflict that are encoded within your code base that perhaps folks have forgotten about, or otherwise not kept up to date. So I think that that, would love for folks to try that out and and give us feedback and and let us know. Yeah. Certainly, quad code is great at interrogating a code base, understanding inconsistencies, and surfacing them to you to be the final arbiter. Cool. Second question from Denise. How do you measure the efficiency of an engineering team that is using cloud code? Previously, we used velocity and story points. How do you measure an engineering team's performance? Lizzie, you wanna start with that? Yeah. Happy to. Yeah. So I guess one meta point is that we want to start with something that your team is already measuring. So for some folks that might be story points, for other folks that might be commits or size of commits. It might be PRs. Ideally starting with something that you already have a baseline for such that you have something to compare to. From there, what I've seen, we have entire guides. So happy to add this as a follow-up or drop a link, in between questions. We actually have guides for measuring the value of cloud code. What I've seen in the field is really taking a look at, commits that cloud code was involved in. We have integrations with GitHub that allow you to track this and then an entire panel, in the admin console that allows you to track that as well, as well as PRs affected by cloud code. We also look at things like exception rate. So acceptance rate rather. So, how much are folks actually accepting cloud codes changes or rejecting them and having to iterate as a measure of cloud codes efficacy within your environment. So contributions to commits, contributions to PRs, as well as, acceptance rate. Awesome. Next question is, how does cloud code scale for very large monolithic enterprise applications with millions of lines of code in the API, UI, and stored procedures? Yeah. I was just thinking about, the slide that I was hoping to show to you all, as I think that this is super relevant. Essentially, Do you want to share it. Lizzie? Would you mind actually? I just brought it up. I think. it might. be helpful to actually have a visual. Great. Awesome. So, like I mentioned earlier, you know, CloudMDs are available at every level of your code base. So for customers, for example, who work within a very large monorepo, we recommend creating CloudMD files within the different subdirectories. And then from there, Cloud actually walks up your directory tree to discover CloudMD files all the way to the root. This is one way in order to organize context for your code base. But we'd love to hear a little bit more, maybe offline if folks wanna reach out about, you know, what they're running into or any limitations of this approach as we've definitely seen, different customers have success with a with a few different strategies, but tends to be pretty unique to people setups beyond setting up a hierarchical cloud m d setup here. That was great. Thanks, Lizzie. And I just wanna, plus one Kevin's comment inside the chat, which he put a link from our blog, about how Cloud Code works in large card bases. Okay. Let's see other questions. So it looks like, how do we create wait. I think this one got oh, saw this question disappeared on my thing. Well, I'll I'll answer this next one, which is, is there a Cloud Code government version, or do we use enterprise or personal accounts backed by the government? So, Dennis, it's a great question. I know there were a number of things about procurement in the chat, so we will transition over to that, actually. So in short, there is depends on your security, qualifications. But for example, if you need FedRAMP high in order to work in with PII or CJIS data or other things, CloudCo is accessible via, I'll just jump here. CloudCo is accessible on AWS, gov cloud as well as Google Vertex, shared workloads. So it's FedRAMP high. And that's probably a really good way fast way to get started, for the sort of most security intensive tasks. That also then stays in your own infrastructure. And Cloud Code itself, at least in the CLI or as a plug in to IDEs like Versus Code, are just run on your local machine as well. But I'll I'll talk through this slide too while we're at it since a lot of folks talk about procurement. This this is sort of the some different ways you can get started with cloud code. From left to right is sort of the easiest to more intensive that involves folks on the Anthropic team as well. So on the left, just getting a Teams subscription, I imagine some of you have personal pro or Mac subscriptions, You can just buy it self serve on the Endropic website. Right? That's a way that I recommend a lot of smaller teams get started. Second would be, as I mentioned, working through a cloud provider, which is if you already have an AWS contract, Google contract, or a Microsoft Azure contract, taking that API key from those different cloud providers, and then you don't also need to work directly with the Anthropic team. From a billing perspective, that's often another way that folks, get started really quickly. So, like, the Singapore GovTech team, I think, is using a lot of, AWS in their environment. The third path is for states and localities that wanna go direct and also potentially use, quad design and other things as well, you can go through the Carahsoft, NASPO, and Omnia contracts, and I would just fill out the form on our website. And then there are some federal folks on the call as well, so we're also on the GSA schedule, as well for US federal. Okay. Let's see if we have one or two more question. Okay. So Jason had a question, Lizzie, that was for the modernization plug in, is that just modernizing the code, or does it also modernize things like pass Great question. Yeah. I believe it takes a full look? at the entire infrastructure and the data flow. So for example, I think one of the things that it noted was sort of an outdated compiler. Yeah. So it's pretty in-depth, and it covers sort of the entire app end to end, not just, for example, moving from Java to, a different language. It's taking a look at, like, dependencies including libraries as well as what is used to to run and, and set up the the app itself. I'm just taking a look right now. Yeah. It's covering runtime, framework, build system, databases, encryption, external APIs, the whole the whole gamut. Another question is, how do we create a high quality cloud dot empty file for a legacy project when the readme is outdated so cloud has enough context to understand the code base and assist effectively? Yeah. Great question. So Claude actually with the init command will read all of the files within the directory that you've initialized it in and actually do that documentation for you. So it's tracing, for example, all of the data flow, dependencies, imports across files, such that it's doing the hard work of actually auditing your code base, and then leaving you with the output. That being said, I think that it's worth, sort of gut checking that assessment and taking a look at, the files themselves just to make sure that cloud is looking in all of the right places. I would really push you to rely on on cloud for that though. In states like Utah where we've done pilots, folks have documented what were previously completely undocumented code bases, that they now use in order to handle net new builds. So for example, API migrations and so on. Awesome. We're getting close to the end here. So I'll just put a plug as well to join our cloud community. Whether following us on socials, we just had COVID cloud, our big annual conference, and different events. And then also you can apply to be a cloud ambassador as well. So and and I appreciate there are a number of folks who have been putting in the chat various blogs. I think, Endropic is a research lab first and foremost. We try to put out as much, helpful research documentation as we can. So definitely encourage you to check out our our documentation too. Alright. Thank you all so much. I know we have two minutes, so maybe we can take one last question. Or Lizzie, any any last remarks you wanna share or tips for everybody? Yeah. Maybe I'll I'll make one more while you look for one last question. Is just one thing that I'll say is that I am so excited by your excitement. Just seeing how empowered folks who are civil servants and working in the government and gov tech space, how empowered folks feel in order to take control of these systems, to modernize them, and to meet the needs of residents is so inspiring for me. And so I feel incredibly lucky to be working with you all. And, you know, this is an open conversation. If you saw something in this demo that doesn't feel, like it would work in your environment, we'd love to hear your feedback, and we'd love to make this work for you all to to diffuse some of these benefits. So thank you for your excitement. Really excited about it. Awesome. I'll echo that as well, Lizzie, and, and just say I super appreciate all the folks sharing best practices and folks that are creating their own MCP servers and skills and, sort of putting them online for others to share. I think we really wanna create a community and of of best practice and people learning from each other. There's only a couple of us, unfortunately. So we really wanna empower you to, to build and share with each other. And that's that's what gets me super excited in in Utah or Singapore or any of these other places is when the developers are building skills and learning from each other and sharing them publicly. So keep doing that. Great. Thank you so much, Awesome. everyone. Thank you all so much.