AWS re:Invent 2025 - Accelerate Terraform Provider development workflows with Kiro (DVT216)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Accelerate Terraform Provider development workflows with Kiro (DVT216)

In this video, two Pauls from AWS and HashiCorp discuss how agentic AI is transforming the software development lifecycle beyond traditional IDE-based coding assistance. They demonstrate how Q Developer CLI enables organic transformation, where ops engineers can analyze, plan, and modernize applications conversationally across all SDLC phases. HashiCorp shares impressive results: 90% faster development time, 600+ Terraform resources built, and significant efficiency gains in managing 3,000+ open issues with their AWS provider. The session showcases real demos of building Terraform actions with Kiro, introduces HashiCorp's MCP servers for Terraform integration, and emphasizes the human-agent partnership where agents handle toil-based tasks while humans focus on strategic orchestration and contextual wisdom.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Welcome to DVT 216: Introduction by the Two Pauls

Hi, everybody. Thank you for your time today and welcome to DVT 216. We're thrilled that you're here with us this morning. Thank you very much for coming to re:Invent. Thank you for spending the next hour with us on this, the final day, the last gong of re:Invent 2025. We got it, we made it. Well done team. I hope everybody's had a truly excellent week. Hopefully, you got to make some new friends along the way and catch up with some old friends. I hope you learned something new and I hope you felt a little bit inspired along the way because that's certainly what re:Invent feels like for me. So thank you for being here. We appreciate you joining us this week.

So because it's Friday, and we shouldn't have to put any brain cycles into anything too taxing today, we've decided that today's session is only going to be staged by Pauls. That way, you can go back home with a little bit more content in your head, hopefully the content from today's session, and you don't have to remember one more thing. So thank you again for your time. My name is Paul Stafford. I'm part of the worldwide team that looks after our customers' growth and success with Kiro and Q Developer. I've been with AWS for six years now, and I'm based in Melbourne, Australia.

Prior to this, I've been a product director and a solution architect and business development manager, and a developer as well. In fact, I think of myself mostly as a recovering developer. I cut my teeth way back in the day, building Java integrations between carrier grade voice systems. If there are any telecom heads in the audience that want to reminisce about the scars and the good old days, please come find me afterwards. I love chatting about that stuff. But I'm also thrilled to introduce you to Paul Thrasher, who is the far better Paul, the Paul with the cooler last name certainly, who's graciously agreed to share the stage with me today.

Thanks, Paul. So I'm Paul Thrasher. I'm project director for Agentic Fabric at IBM, HashiCorp, now IBM, and Agentic Fabric is doing AI projects within HashiCorp's board. So I started way back in the day with a Bachelor of Fine Arts in Design. Been a programmer for over 16 years. I was doing PHP at first, but I got into, you know, Python, Node.js, Go, Swift. Been really loving Swift lately. I've been with HashiCorp for a bit over 8.5 years and got into product management about three years ago.

Since then, I became director of product for our Terraform ecosystem. So at first managing providers but also doing, you know, partner integrations, and now I'm doing AI for all of HashiCorp up here. So, you know, I've been all over the place so I think at this point I just like to build stuff so here we are on stage building some stuff. Awesome. Fantastic. Thank you very much, Paul. Much appreciated.

Session Overview: The Evolution of Agents and Human-Agent Partnership

So, rather than, I suppose, show you a very sequential agenda slide, which I'm sure you've seen enough of during this week, we thought it'd be a good idea to give you a synopsis of what you're going to hear and see over the next 60 minutes, followed by some topic specifics. And that way we can effectively convey both the thematics as well as the molecules of what it is that you're going to hear about in this breakout session. In what is probably the understatement of the week, I'm going to say that agents are undergoing significant transformation. What used to be assistive tooling is now quite sophisticated and autonomous. And at its crux, that's what you're going to hear today. You're going to hear a story of change.

We're going to talk about how agents and their use cases have changed. We'll talk about how the SDLC is in the progress and the process of changing. We'll talk about how services like Kiro have changed, but most importantly, we'll also focus on HashiCorp and the change that they went through to solve one of their most pressing challenges by using agentic AI within their SDLC. Importantly, you're also going to see the practical reality of the human-agent partnership in action. And it is a partnership where agents have become active collaborators with us, with developers in the development process.

So, in creating the session, Paul and I wanted to ensure that all of the topics in the next 60 minutes were underwritten with a very followable how and what format. So based on a rough calculation of time and slides, the next 60 minutes is going to be divided thusly. And as you can see, we're going to put a bit more time into the how slides and the how details. And rightfully so, this is a level 200 session. So we will cover the evolution of agents, the human-agent partnership. We'll go into Agentic AI across the SDLC. We'll have some demos. We'll obviously talk about HashiCorp's challenge, and then we'll talk about tooling and MCP will be an element of that.

So if we do our job properly, we'll hopefully get you thinking about not just the technological change, but we'll also get you thinking about the paradigm shift that folks are going through as they're approaching software development in late 2025 and obviously next year as well.

So you'll spend roughly the next twenty-ish minutes with me, and we'll go through that contemporary evolution concept. We'll talk about patterns, we'll talk about use cases, we'll talk about adoption. And then Paul will take the stage for the good stuff.

Paul's going to talk through some demos that he's recorded, and he'll talk on the reality of how this works for HashiCorp and the benefit that they've seen and drawn into their own customers and their own partner ecosystem. But if there was only one thing that you took away from today, and if there was only one thing that you recalled in the weeks to come, Paul and I would really like it to be this quote from this session. Yes, AI agents can create and achieve great things, but it's the human who provides the contextual and tooling wisdom, the strategy that prevents agents from assuming in the dark.

Defining AI Agents: Components, Capabilities, and AWS's Three-Layer Stack

Now, we'll revisit this quote later on in the slide deck. We'll decompose it further once we've gathered a little bit more detail through the course of the session. What are AI agents? Autonomous or semi-autonomous software systems that can reason, plan, and act to accomplish goals in digital environments. You may have seen this definition knocking around on the internet recently in the last couple of days. And whilst I understand its intent, I'm not really a fan of it.

I prefer an agent is a system that you give agency to complete a task according to independence, tooling, and context that you allocate. These days, Agentic AI is context-aware, it is proactive in its actions, and it can maintain continuity over tasks. And when you wash everything else away, it's these three concepts that enable us to partner effectively as humans, as developers, working with the agents themselves. And this is obviously all in the purpose and the intent of having an intelligent collaborator in our software development activities.

So I thought it worthwhile putting a couple of points of definition on the table right at the get-go because there is some ambiguity around terminology with Gen AI and Agentic AI and everything in between. At AWS we think of generative AI as this three-layer stack. I'm sure you've seen this during the course of the week or maybe previously. At the bottom, we have services, infrastructure services that our customers use to build and train their own models. In the middle is Amazon Bedrock, which is used to create generative AI applications. And then at the top is the agent-based managed AI services such as Kiro and Q Developer.

At AWS we consider Agentic AI to be about task management, and specifically toil-based tasks. And I'll say that word a lot during the next sort of 15 minutes, toil. This is where you give a large language model agency to complete something on your behalf because as it turns out, having an agent that you can allocate an activity to is a powerful productivity and efficiency concept. And part of the reason for that productivity and efficiency is simplicity.

Because agents are actually only composed of four main components, memory, which is where the LLM sits, tools, which is all about integration powers, and MCP lives here, and that's a little bit of a foreshadowing for what's to come with Paul a little bit later in the hour. And then planning, which is self-management, workflows, separate data sets, and so on. And of course the final thing is outcome, which is the actual task that you've given to the agent itself.

One of the key reasons why agents are becoming increasingly attractive is because of the generational advancements of the technology and integration in all of the tech behind these concepts. And I promised Paul I wasn't going to mow his lawn too much with this slide. My apologies, Paul, but it would be shameful of me not to mention that HashiCorp obviously contributes significantly to the tool and planning elements with Agentic AI through the technology and services that they have created.

One further point of definition for the table before we go any further, if you don't mind. We're seeing customers drive value with Agentic AI across two primary categories, accelerating software development and reimagining workflows across the business. The prior is about using AWS pre-built Agentic services, and the latter provides the tooling for building your own agentic solutions. For the sake of today, we are focusing only and solely on the prior. We're focusing only and solely on accelerating software development.

From Coding Companions to Full SDLC Integration: The Evolution of Q Developer

So when Agentic Services first appeared on the scene, they were almost solely coding companions. They helped developers with the ideas of things like code completion and auto suggestion, which was and is quite a polarizing topic for many developers. The playground of early Agentic AI was phase 3 of the SDLC which was all about what developers do through an IDE as part of the design activities and associated process.

In the dawn days of Agentic AI, which granted was only two-ish years ago or so, the benefits of agentic AI were quartered behind qualifications like being a developer, having an IDE, and working in phase three of the SDLC. Finding ways to expand the value of agentic concepts beyond those qualifications has certainly been one of the driving forces in where Q Developer have gone over the last twelve months, specifically to be more reflective of the full SDLC and the complete list of personas who interface with it. Our customers started talking with us with the primary question being, where are folks spending their time in the SDLC? Because it's not solely code creation.

During our discussions, our observation became, if modern development is about things other than just the act of development, how can we bring the value of agents to all areas of the SDLC where people are working? Or to put it far more poetically as it says on the slide, how can the value of agentic AI be more prevalent? Good application design is a product of multiple personas across all six phases of the SDLC, from scope and standards to documentation and modernization and measurement. As a quick matter of note, the text that's in pink is not random SDLC verbiage. These are areas and actions where Q Developer, through either the CLI or IDE modalities, can influence SDLC task and toil and collaborate effectively with the folks who actually work in those phases.

Our view on this ended up being that we needed to democratize the task and toil value of agentic AI so that it was more accessible outside of the IDE by people who aren't developers and didn't work in phase three of the SDLC. So earlier this year, we released two features to drive that concept. The command line interface, meaning no need for an IDE, and agentic chat, which opens the door to conversational natural language engagements without having to manage the context between individual bespoke agents. It has been fascinating to see the use cases that have boiled up and been uncovered as a result of this.

One of my favorites is something that we're socially starting to call organic transformation, which is when a modernization target is identified by operations from stage six of the SDLC and it is analyzed, planned, designed, and implemented agentically without the need to traverse through half the SDLC through process and through phase. Now we get to have a little bit of fun, and now I get to take you through how you would effectively instantiate or do something like organic transformation with the Q Developer CLI and what that potentially looks like.

Organic Transformation in Action: A Payment Processing System Case Study

In this situation, I'm an ops engineer at a fictional company. I've received a ticket saying that our payment processing system is struggling. You can see some of the details up there. There are things like CPU utilization is currently twenty-five percent, it's underutilized, it's taking four point two two hours to run fifty thousand transactions. There is a commercial impact, and it should be taking well under an hour. Now, I should point out that in this scenario, I used the Q Developer CLI to query a very simple Java application that I created to reflect the process of organic transformation within the time that we have.

The eagle-eyed amongst you will no doubt have seen a few of the awful things that I put into this application, things like hardcoded database credentials and artificial timers. It reads like a laundry list of terrible things that you should not do to innocent applications. Whilst this is a simple application, it's also intended to be really a worst case example of something that many companies may have, which is a modernization target that has performance and security issues.

As a good ops engineer, I know that I need to get into an analytical mindset really quickly and identify what's happening with this application. So I open my command prompt, I type Q Developer CLI, which drops me straight into the interface, and from there it's a very usable conversational style of engagement. As you can see, my initial prompt says analyze the payment processor Java file in the legacy payment system. Now, there are many reasons why this is not a great prompt. In fact, it's an awful prompt, and chiefly it's things like vagueness and lack of purpose, but that is by design at this point in time because we're wanting to see how we can build this up in a manner that begets ongoing and continuously improving hygiene.

Nonetheless, within a few seconds, Q Developer has given us a response. You can see we've got some of the details in there categorized by security. It's obviously picked up the fact that there are hardcoded credentials. It sees SQL injection vulnerabilities. From a performance perspective, it's telling me I'm not doing any connection pooling and I'm doing a lot of synchronous processing. There are leaks. Architecturally, I'm missing transaction management and there's absolutely no error handling.

It's a bit of a nightmare. But importantly, it's starting to identify risk and scope and actions that should be taken and the priority in which they should be taken and should be considered. So yes, Kiro is telling me that there are performance issues, but perhaps more importantly, there are some major security concerns, and in a rather direct manner it's saying that's a priority we should actually be looking at. And as a good ops engineer, now's the time where I get into the power of an iterative conversation with the service, and I go deeper into the actual analysis.

I do have a pom file, which means there's integrations. So, review the pom file, identify outdated dependencies with security vulnerabilities, suggest modern alternatives. So good. My prompting is evolving and it's becoming a little bit more specific in my conversation. And as a result, I'm getting some specifics in return. This is good, we're starting to build our context, we're starting to build our momentum. You can see there CVEs are starting to surface, modern alternatives or frameworks are being suggested, and that's all good because this is some of the stuff which is gonna make lighter of the action that I'm gonna have to take in the not too distant future.

So let's quickly review what we've just done to our SDLC in that very short interaction by agentically actioning it with some of the toil that we've got in our daily environment. So analysis of new functionality, creation of new features, security updates, codebase, architectural amendments, all usually begins in phase one with BAs, tech BAs, project managers, architects working together. And they would normally ensure some of the toil-based action detailed in our working examples such as scope and usage analysis and risk capturing. But by actioning this agentically, we're moving those tasks to an agent and we're working iteratively with that agent to complete that task. And this frees up the tech BAs, the architects, and so on to focus on higher value concepts like analyzing and facilitating technical solutions or identifying the technical aspects of business solutions. By shifting the toil to an agent, we are upping the efficiency of stage one. And we're starting to gather momentum as we start moving into phase two.

So, happy with the analysis of the service, I now move into the planning and design phase. And you can see over there, we're saying what are the three immediate improvements I can make to the payment processing system that should have the biggest impact. Focus on quick wins. Now, based on the language that I've used in my prompt, Kiro is starting to see that I'm edging forward and that I'm starting to look for details that are more related to planning and design work. So you'll start to see specifics in the responses, such as replace this with this. Kiro is now using the contextual awareness that we've started to create and that we're developing to get tactical on the specifics, which is a prime example of a toil-based task that an agent can handle.

And that goes deeper in there in the output into things like vulnerabilities and DB transaction management and the memory and resource leaks that we spoke about earlier. But this is also where we start to see output around the expected outcome and the implementation plan. And if this was real life, we would again be iterating with Kiro to get very specific on details like help me create a risk management plan, help me create an ROI estimate, help me create those assets that are important. Help me design this into being a cloud service, and so on and so forth. And much like we saw with analysis, by using agentic chat, we have moved additional tasks to the agent and we're working iteratively with that agent to complete those actions.

Planning and design is one of those areas in the SDLC where there's deep potential for efficiency through agentic collaboration. Primarily because you have BAs and project managers and developers and architects all working in close collaboration to establish foundational information like project foundations and what are we actually gonna do. And this can be a very toilsome action, very time-consuming action, specifically around some of the topics that you see there with things like practice and standards and dependencies and the actual implementation details itself.

And now we get into the really, I suppose, the important part, the phase that really matters, which is the idea of implementation. And you can see, my prompting is getting far more verbose at this point in time and far more honest with Kiro as well. I have a high priority ticket about the payment processing performance in the legacy payment system. Based on all of the context we have investigated so far, create a specific and detailed plan to address the performance and security issues we have uncovered. Prioritize the plan according to what will have the largest impact in our organizational priorities of secure customer data, outstanding customer performance and frugality. In order to expedite the approval of this plan, I'm gonna have to go through a change review board. I need details like clearly identify the value in terms of ROI, success criteria, uplifted customer experience, and so on and so forth. Identifying the actual actions, who's responsible for doing what.

Now, you can clearly see that the prompting has evolved. It's purposeful, but it's not restrictive. As a result, I have a much richer response, one that I can work with within the bounds of my prompt that draws upon the foundational context that we have been developing and gathering as we step through what would normally be phase one and phase two and phase three of our SDLC.

And in this scenario, Kiro outputs a step by step implementation plan that I or anyone or even Kiro itself can agentically complete. And that's where we start looking at things like creating this into an asset that we can take to our change review boards or work as an escalation or create integrations with third-party systems like Jira and so on. And importantly, that includes the systematic creation as opposed to the subjective creation of projected results and the risks we're planning to mitigate and the success criteria that may actually contribute towards what our definition of done detail is actually about.

So what we find happening at this point in time is something that's really interesting that we didn't really quantify too much at the beginning. By giving folks the ability to designate their task and toil, it gives them the ability to shift their value elsewhere as they allocate tasks and manage the associated return. The classic example here being a senior developer who gets to think as a tech leader or an ops engineer who gets to think architecturally, or a project manager who gets to think programmatically, because they are managing and reviewing outcomes and actions that are always of a specific standard, which has some very deep and inherent quality benefits attached to it.

Great. Okay, so let's go back five minutes to the quote of the polls and apply that lens to everything that I've just said. It's still the human who provides the contextual and tooling wisdom, the strategy that prevents agents from assuming in the dark. This collaboration with agents addressing the toil-based activities and humans giving humans the ability to address the higher order values like orchestration and so on is a powerful concept. So let's take that concept of human-agent collaboration a level lower and get into the deep details with real world specifics. And for that, please join me in re-welcoming Paul Thrasher back to the stage. Thanks, Paul.

HashiCorp's Challenge: Scaling AWS Terraform Provider Development

So at HashiCorp, what problem are you trying to solve? So with our AWS Terraform provider and the AWSCC Terraform provider, we're seeing constantly accelerating growth. So here you can see we've currently have around 3,000 open issues, 518 open PRs last I checked. And we have over 3,000 contributors, but only one software engineering team at HashiCorp. So that team is supporting over 5 billion downloads. I think it was at 5.3 or 5.4 last I checked, which is about more recently over 5 million a day. So every day they're dealing with supporting quite a bit of users and a growing amount of resources that bring in PRs and issues.

So how does this team keep up with the constant changes and growing issues, PRs, downloads, support? And you can see that without any changes it would increase past our ability to maintain that. So it's been hard to scale, of course. So scaling the team, to bring on new members and onboard them, you need to have Terraform experience, SDK which is how you build a Terraform provider, Golang and AWS experience all within the same engineer. And of course you can train that, but as much as you can come in with for a new engineer, obviously helpful.

Writing PRs, you know, of course it's more time consuming than reviewing them. It gets our overall velocity down, so each engineer has to keep up. This is most of their job. New contributors, bringing them on, onboarding, they've got to pick up on standards, the principles, the ways of working, how we operate within HashiCorp and within this team, which is constantly changing as we deal with the growth here. Code quality, so we need sanitized compliant code. Of course it's got to be high quality always, ideally improving over time and so, you know,

going through that process of hiring, writing the PRs, and onboarding new folks, you've got to keep that rigor and keep the code quality high. And security risk, as you can imagine, with our large customers and the large scale of Terraform and AWS, all those require a good amount of scrutiny to make sure that there's no malicious code getting in through that process as we bring in all these different contributors. You can probably imagine some of the risks there where if code were injected and gets into our contributors, all of a sudden they've got their own code within banks and other security products all over the place.

And all that, of course, ends up with this review bottleneck with the amount of external contributors. Also, they all need experts reviewing that have that expertise in those different technologies and services. And so this limits the amount of reviewers we can have, but also just the time it takes to get through that. So I think the point here is that it's tough to scale this, and so you've got to consider what are your options over time, how do you make improvements to your process and keep up with that load.

So, of course, mainly it's a lot of hard work. But also now we get, we get some AI here. I've worked with the raw models, building things in-house, trying different approaches, and I think that this greater efficiency doesn't reduce engineering roles, it expands what teams can achieve. So what do we want? What are we looking for out of this? We want our human teams to be more effective. We need to scale their work, their efforts. We want it to be easier for our engineers and external teams maintaining their own providers, so it's not just about this AWS team too.

At HashiCorp, we're trying to scale these efforts across many partners, and we already spent a lot of time here through these maintenance cycles, the different investments in working through the PRs and reviews and scaling our hosting services, along with our ability to keep up with more contributors. So it's not new for us. So we've explored AI as an option, of course. We explored trying just the raw models early days, a year or so ago before agents, or even now you can see how potentially the throughput might be faster because you can parallelize a bunch of work.

It can be faster to implement as far as getting these things along a path, maybe throwing in a CI/CD or some kind of consistent process when changes come in. And it can be good for exploration or trying things out, but the results have been unpredictable for us. They're hard to repeat. Just because you prompt one thing one way, it's not going to work the same for another similar resource. You need pretty in-depth understanding of these resources, and it depends really heavily on the prompting, and these are kind of operating once the results come out.

We've tried instruction-based agents, so that's most of the agents you've seen out there. They're good for guiding us along those workflows. They can follow patterns that we set if you follow them along with them, and it doesn't need too much structure or checkpoints. In some cases, you can try to get the one-shot results and see how far you can get, if it goes and codes for 30 minutes for you. But it's still limited by the prompting, as Paul was showing us. You still need that user vigilance to check in on the code and make sure it's good, and it can still, between implementations, drift along, misinterpret, kind of go in the wrong directions.

So we've also recently tried spec-driven agents with Kiro, now that Kiro's been out. We've seen it delivering consistent high-quality work for us, which has been great, of course, and we get well-defined requirements after we put that rigor and pre-prompting in.

It's been great for the complex work that we've done within the AWS provider. I think the caveat there is that it takes a lot of upfront thinking and design. But this is something we already do at HashiCorp. That's part of our process anyway. As you know, you see with the SDLC, we're already going through these phases, so that upfront thinking just kind of matches our flow anyway.

So we've got some fun numbers. This was honestly great for us and really encouraging with 90% faster output for the development time for some of our provider resources and actions, as I'll show you. We've also developed over 700 high quality configuration documentation resources. I think there are thousands of resources that we're managing and having to keep up with and develop, and so the documentation of that is a big part. We've applied AI to that as well, and the quality has stayed high. We get quick iteration speeds, and it comes along with the tests and different controls through that process as well.

Throughout development, we've built over 600 Terraform resources, and the time spent there was significant before. We've gotten over 600 so far. I think this was a week or two ago when I checked this number. It's definitely higher now, but also 500 Terraform actions have been created so far. Overall efficiency, we've seen around 90% time savings, and that's been across the actions and the Terraform resources. In some cases, a Terraform resource might take a full 40 hours of work to develop, and we've seen that brought down to about 4 hours. So great speed up for us, really encouraging.

So how do we follow the SDLC process at HashiCorp? Within this analysis and planning stage, we produce PRFAQs and PRDs. I believe PRFAQs came from Amazon, nice thing to steal from them. So that's kind of the pre-planning. That's a lot of product management work, highly collaborative with the engineering still, but that pre-work to figure out what we need to go out and build. RFCs have been used forever at HashiCorp, and that's kind of the process of the engineers pre-designing what they're going to go build, kind of calling the shots through that design implementation phase. And then of course engineering happens all within our IDEs and GitHub.

With the testing and integration, we have the usual unit and integration tests, of course. But with the AWS Terraform provider, it's fairly large, and as you can imagine, doing integration tests across every single AWS service is not just slow but expensive. So that's more of an async, less often process. But for us, documentation is also key. That's a huge part. If we can't bring that to you in a way that you can consume and understand it, then we didn't do our job. It's not useful for anybody. So through the maintenance process, that's back to that constant vigilance and going through those issues and PR reviews that kind of feedback into that analysis and planning stage.

Demo: Building Terraform Actions with Kiro Through the SDLC

So I'll kick off the first demo here. We'll show off how we applied the SDLC phases within Kiro. We're going to be building a new Terraform action for the AWS provider. So actions are new to Terraform. The models don't understand them. They understand building it within Go. If you search Google for Terraform anything, it's going to give you a bunch of HCL code. So on this side, it's kind of unknown to a lot of the usual processes that you'd hope would just work for you. In this case, it's going to be a DynamoDB create backup, which just triggers backups for DynamoDB. And this is all real code we're going to ship as well.

So this is the analysis and planning stage. We started creating the steering docs.

Kiro helps with that. I think in some cases it's just one click, it'll kick it off for you. So we go through those PRVQ and PRD stages at HashiCorp, and it kind of reflects our typical process, just as it is now in the Kiro way of doing that. And in some cases you might want to do these as separate steps working with your team so iterate collaboratively, throw those in the repo, get feedback, but we want to show an end to end demo here of how we work so we just kind of go through it quickly and it's sped up because the LMs aren't the quickest thing to run through when we want to show the full stage here.

So the spec here is how to read the repo and kind of work in the way that we want. So we had one of the Terraform AWS Provider engineers. He's an excellent engineer. He's built a very large amount of resources already, so he's very familiar with the code base so he can get in there and prompt it and tell it exactly kind of how we want to approach this work. So it is not implementation yet. This is writing the spec of how you want to operate once you start triggering the next work. This is just the requirements.

So here we write this back out manually based on the documentation. You can see them including other files, and just giving it good examples to pull from. And we allow it to refine the document. It can make some updates, go check out those files, a bit of prompting, and there we go. It's, I love this part, the LM does a bit of work for you, but it's grounded in what we want out of this process and out of this document. So then those files will be available as part of a library that we're building, so you can create actions similar to what we did for you if you're maintaining a Terraform provider, which is great. As a PM I'm doing a talk, but I also want to extract some product value out of this. So in some of this work I'll share later how we kind of bring it to you guys.

So this is phase two, it's the design and implementation SDLC stage. So we asked it to create the plan for us. And right away it kicks off, kind of writing some code, doing it step by step. And Kiro's going to write the code for you based on those steps that you kind of laid out in the task doc. So it's sped up, but for our engineering time, that was real time and how we developed this feature. I think it was one hour twenty minutes total, so to condense that down into about six minutes for you all we speed it up, but this was the real-time process for us. And so he's following along with the LM making sure that the code is produced properly. You can see him updating the tasks and changing that based on the feedback from those earlier tasks. And you know, this is of course like it's going to land in production, so you got to make sure it's up to that standards and quality.

In this case he didn't run into any major errors. We've been through this process a few times. We used Kiro's CLI before this a few times. That was some of our earlier improvements. So Kiro was relatively new for us, but already he was able to kind of hit the ground running in a lot of ways with his experience and working through the code. And Kiro's going to make sure that this package that he's building here is consistent with the other code and the other services that have been developed. So it's a bit easier when we had a couple of examples. You know, writing the first ever action of course was a long process of back and forth with Terraform Plugin Framework and SDK and other provider work, but once we had a few you can kind of lean on those earlier examples.

So continued step by step, make sure it's progressing correctly, and then you know, each of those tasks as we're going, they all refer back to those steering notes also. So in phase three, this is the testing and integration phase. So we already started writing the test here according to that task list spec.

You go through each of those steps in the task file, and then near the bottom, that's usually where the tests and documentation are written out, so you'll get to those near the bottom. Similar to the last one, it's doing live development here, and this is a chance to make sure through these tests that the code's correct, it's doing the right things, it's the right output that we expected. It's writing the unit test for us, and so we get to make sure it all works.

After the unit tests, it goes into end-to-end testing. I think it got tripped up on some credentials. You need your AWS credentials to be able to run these and test them out, but it was able to quickly create a DynamoDB table and then kick off that action to trigger the backup. So we did get a test fail here, but Kiro was able to read the output there and go back into the implementation and fix that up, and then retest it again, and then pass. So we still need to give it human-readable instructions, but Kiro's doing all the actual work and the testing, the actual code, and we kind of just care about the natural language flow and path to assist it.

Near the end, you'll see it also creates the docs for us. So the docs can also take a long time. They're based on the API generally within the AWS reference docs, and this is going to follow the standard format here and standards that are the same in our other docs. So it's a little bit more tedious, but it's still kind of formulaic as far as the docs because we often need to support so many of them. So you can kind of see how we're coding with the agent rather than just Kiro doing everything by itself. From there, of course, we move it into a pull request with GitHub, and then see what AI friend we can get to review the code too.

MCP Servers and HashiCorp's AI-First Future: Terraform Kiro Power

As we're developing this, we're thinking about how can we help you all with your AI workflows. What does HashiCorp have for the rest of us? That was a central part of the workflow that we've been developing and working through, which is through MCP servers, and we wanted to bring some of that efficiency to our users. So you've probably seen a bunch of talks around MCP this week, but what's our perspective? How do we think about it? For us, it's an open-source project that helps assist with your AI workflows. It brings context into that developing environment as you're working through. We're actually seeing some more IT business use cases coming out of our MCP servers as well, even just for Terraform specifically, but it gives us that connection between our tools and the models within the agent or even other contexts, and then we get the quick plug-and-play integrations. We've seen we can write this MCP server, go give it to partners, place it in other products, which is something we've not really been able to do before.

So our MCP server within Kiro, you can see some of the quick setup here, but an example prompt might be something like, I need help setting up my S3 storage buckets within Terraform. It's a very common task, but it's one you usually still have to go down over to the docs and go look that up. So in this case, the MCP server will work within that workflow and kind of the same pattern that you might do. I kind of see it as we have these workflows within our products, either open source or commercially, and we just want to assist with those. So this one will search content within the registry, and it can pull content from multiple docs to kind of triangulate how to create a resource and combine those results and create the resources you need. So, quick demo, I just want to show off our MCP server within Kiro.

So, could you help me create an S3 bucket using Terraform? It's a simple use case. I've created so many buckets, I don't know at this point. I've lost track. But it's going to just start from scratch. That was an empty repo there. And it uses our MCP server, and it got the latest provider version. It works with all the providers, not just AWS. It also checks multiple resource docs and grabs the best one for that context. It's nice that the model just knows how to do that, and the agent supports that. Then you could take all this information and feed it back into those steering docs for Kiro, but we're keeping it simple within this demo at least.

We can also ask it to use public or private modules for you. So if you're in HCP Terraform, you probably have your own best practices built into policy and modules, and you can grab that. Here we have it follow a CIS policy that it grabs from that registry, and it even updates the code to conform to the policy here. Later, you'll see it also works along with the Terraform CLI. So here it is. It'll do some formatting. It doesn't really make sense to have MCP run a format for you when it knows the CLI very well. So it just runs that. For basic formatting and validation, I think that's a great use case for those. Otherwise, I personally don't think that agents should be running the rest of Terraform plan and apply. We have HCP Terraform to help you go through that process for collaboration and security.

So in the end we get an S3 bucket with logging and policies, and it's made sure it's not public. So it follows not just best practices, but the policies that are within your business, and it's usable in production and conforms to what you would expect from any human going through the PR process. So what's next for HashiCorp? We've been introducing a bunch of AI-first development practices. We've kind of doubled down on that human-agent partnership, and we've kicked off a dedicated team just for provider development and authoring configuration with AI agents. So I think you'll see a lot more assistance there and more tooling.

We also learned about Kiro Powers along with everyone else this week a few days ago, and yesterday we quickly produced and pulled together our docs and MCP server. We got legal approval and marketing support, and we went out as a launch partner yesterday, even though we just learned about it this week. We developed these specs and different aspects of it. We're going to launch elsewhere, but we now have HashiCorp Terraform Kiro Power. So that team is going to be working on things like that that help you develop your config and also Terraform providers.

We'll be giving out official agent documentation for Kiro and other agents, providing some of these tools. Each of these tools kind of have their own proprietary support, so we'll be building for that. I think this helps HashiCorp, IBM, our partners, the whole ecosystem, and our users. It makes it a lot easier to work within these kind of AI agent contexts. There's a lot more to come from us, I think. We're hoping to accelerate quite a bit with AI within HashiCorp and pull in newest ideas from the rest of the industry, which is of course how we've always operated, and so very similar processes now that AI is in play.

You can go check out our Terraform MCP server. We've got some QR codes to leave up for a minute. And we've also built them for Vault and Vault Radar. I think you'll see more to come. But through there, also check out our Kiro Power, and I think soon you'll see documentation around best ways to use this MCP server.

Looking Ahead: The Future of Human-Agent Collaboration in Software Development

Thank you, Paul. Thank you, Paul, much appreciated. And before we wrap up in a minute or two's time, I did just want to very quickly publicly doff my hat and acknowledge the work that you and the team have done as part of the incredible gains you've gotten around things like 90% time back into the day of your people. So well done to you and the team for everything that you've done in that process. Really is an amazing result.

So between Paul and I, we've talked about the many ways that the agents are transforming the SDLC. We've gone through things like backlog grooming, we've talked about things like requirements generation, we've talked about intelligent orchestration and so on. This holistic integration of agents into the SDLC is kind of changing it from being a bit of a linear sequential process to being something that's a bit more dynamic and loop-shaped in the way that it goes. Where it goes is something that's going to be really interesting for all of us to watch over the next very short period of time.

But one thing it is doing is enabling the efficiency and the quality of delivery that Paul has just been covering. And I know we keep harping on this point, but none of that actually occurs without that synergistic relationship where humans and agents co-create. And that goes across things like ops engineers using agents for things like infrastructure orchestration and monitoring and incident response and so on. But it also goes to tech BAs who are using it to analyze requirements and create user stories. And if you're a purist like me and you love the when then shall approach to user stories, have a look at what Kiro can do.

It also goes into things like architects simulating system designs and doing things like ensuring compliance, assessing scalability, project managers for sprint planning and stakeholder communication and risk analysis. The result is a more inclusive and efficient development environment where every role contributes meaningfully to software delivery, and that's an exciting concept. If I was to crystal ball the next 12 months, I think this is what it would look like for me. Without doubt, agents are going to gain greater autonomy, such as when we start to uncover use cases like organic transformation that we spoke about and the adoption thereof.

But that's directly linked to something that we're calling true collaboration, which doesn't mean heavier collaboration in this context. It means effective oversight, which, as we discussed, is one of the keys to that human-agent partnership. And lastly and finally, our third and final point for the session for the day is higher quality output from the SDLC means a quicker, straighter path to organizations and developers capturing the opportunities that they're working on through software creation. So where can you learn more?

There is still one of these things happening at this point in time. If you haven't gone and seen the House of Kiro yet, which is in this building in the Venetian, level 2 in front of the expo, go through and have a look and a walk through the spooky House of Kiro. It's an exciting little thing to do. It's kind of a cool experience. And there's great swag on the other side as well. So thank you everybody for your time today. We really appreciate you spending an hour with us. It's been fantastic. Thank you Paul for being on stage with me. Travel safe back home and we look forward to seeing you next year. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.