Your API isn’t an MCP tool! What’s intuitive for humans often overwhelms agents. Discover how to design MCP tools with AI agents in mind — and why AgentExperience (AX) matters — in my latest article in AINativeDev.

Out of the blue, AWS just dropped Kiro , a new AI-powered IDE — a VS Code–based, agentic platform that some are calling a Cursor killer . At its core is Anthropic’s Claude Sonnet 4, and it introduces a structured approach called spec-driven development . The idea? Take vibe-coding one step further by splitting the process into two clear phases: Plan first — Define what needs to be built through structured specs. Execute second — Let agents carry out the work, task by task. It’s a clean break from chaotic code generation — and a signal that the future of AI coding tools might be less “guess and generate” and more “think, then build.” Let’s look at the 4 new features that Kiro enables for vibe-coders: 1. Spec Coding — Plan First, Code Later! One of the most significant innovations introduced by AWS and Kiro is the use of structured spec files before any code is generated. This planning-first approach helps provide clarity and context for both developers and AI agents. Kiro generates three key files: requirements.md – Defines what needs to be built using user stories, acceptance criteria, and functional requirements. design.md – Describes the high-level architecture, components, and interfaces involved. tasks.md – Breaks the project into smaller, actionable tasks that can be executed independently. By defining the scope and structure upfront, this approach enables large language models to produce more reliable, production-ready code, addressing a key limitation in many current AI-powered IDEs. 2. Hooks — DRY! In the Infrastructure as Code world, the principle of Don’t Repeat Yourself (DRY) is key to reducing redundancy. Kiro’s Hooks follow the same idea — designed to automate and standardize repetitive tasks in your workflow. Hooks can be triggered automatically (e.g. on file save or commit) or manually. When triggered, they send a predefined prompt to an AI agent to carry out a task. These can be used for: Generating or updating unit tests Refreshing documentation Performing security checks or code audits 3. Agent Steering — Keep Your AI from Going Rogue! To maintain consistency across a codebase, Kiro supports steering files that provide additional context to the AI engine. The default files include: product.md – to describe product goals and business logic tech.md – to document technologies, APIs, or libraries in use structure.md – to define project structure, naming conventions, or folder layout You can also create custom steering files. These files act as long-term knowledge sources that ensure the AI aligns with how your team works. 4. Auto Pilot Mode — Go get a coffee! Kiro supports two modes of execution for tasks: Autopilot , where tasks run end-to-end with minimal input Supervised , where each change is shown as an inline diff before being applied Final Thoughts: The AI IDE space is evolving quickly. We’re seeing major players enter with different ideas about how AI should support software development. Kiro stands out with its structured, spec-first approach and focus on long-term code quality. Still, this space is in its early stages. It’s too soon to say which tools or approaches will become the standard. But one thing is certain: we’re at the beginning of a major shift in how software is built and maintained. P.S. Follow me on LinkedIn

How to Introduce Crossplane in Your Organization — And Keep Everyone Smiling Lately, I’ve seen many people in the Crossplane community struggle to convince their teams that Crossplane is a good fit for managing infrastructure and application stacks. Changing minds is hard — especially when it means stepping out of a familiar workflow. I find this challenge fascinating, so I decided to write this blog post to explore the common hurdles people face when introducing Crossplane to their teams. But before we dive in: Setting the level source: Upbound Blog Crossplane is an open-source CNCF project that enables you to build control planes on Kubernetes. It provides you with the tools to abstract infrastructure and service configurations into higher-level APIs, tailored to your organization’s needs, and expose them to developers. apiVersion: platform.example.org/v1alpha1 kind: XApp metadata: name: my-xapp spec: image: xapp:1.25 replicas: 2 bucketName: my-xapp-bucket Some of the most important advantages include: Syntax: It’s all YAML — no new DSLs to learn. (We love YAML, don’t we? 🙂) Real-time Observability: You can view the status of each resource in real-time and some metrics to see how things are looking. Continuous reconciliation: Crossplane constantly checks that the actual state of your resources matches the desired state. Self-healing infrastructure: As part of the reconciliation loop, if something drifts or breaks, Crossplane works to restore it automatically. Real-time observability: You get live status updates and metrics for every managed resource. With Kubernetes huge adoption in the past years, Crossplane and similar (yet less mature) project Kro seem to be our best shot in deploying services and their cloud resources, through Kubernetes native abstractions. But before you even get to the technical stuff, the biggest challenge is simply getting people to step out of their comfort zones. It’s less about YAML and more about psychology. Teams are used to their tools and workflows — asking them to try something new can feel like suggesting they switch to tabs instead of spaces. Change is uncomfortable, and unfamiliar ideas often trigger resistance. Helping people see a new perspective takes patience and storytelling. Here are some classic “Wait, but…” moments you’ll hear as soon as you mention Crossplane: But we need to educate everyone to use crossplane! Of course you need to! The good news? Since Crossplane uses YAML, it’s usually easier for developers to pick up compared to learning a whole new DSL like Terraform. If your team is already familiar with Kubernetes, adopting Crossplane feels natural — mostly just small changes in code. I’d argue that what you should be more worried about is to educate yourself (Platform/Cloud Team) to understand Crossplane and start using it. But why not use Terraform? Lack of reconciliation is a big pain! How do you make sure what’s defined in code matches reality? Run Terraform on every stack every five minutes? Set up a cron job for that? Believe it or not, some companies sell exactly that — a continuous Terraform runner — as a paid service. On top of that, building a reliable CD pipeline for Terraform is not easy, whether you’re doing it yourself or using open-source tools like Atlantis. As one developer from a company specializing in Terraform CD pipelines put it: “Atlantis and other open-source tools send many customers our way. Honestly, we tell them to try those first before buying our product.” Sounds like a clever sales pitch, right? But there’s definitely some truth to it, which highlights a clear gap in open-source solutions for Terraform drift detection and continuous delivery — a gap that’s arguably intentional, since vendors want to offer features you have to pay for. And I haven’t even started on how much harder it is to teach Terraform’s concepts and HCL to developers, compared to the simplicity of a YAML-based Crossplane XRD. But we need a PhD in Kubernetes! Nah — if you can pronounce “kubectl,” you’re 80% of the way there. But all our infra is already in Terraform! Migrating from Terraform to Crossplane is not necessarily disruptive! Using Crossplane Terraform Provider, you can import your existing Terraform-managed infrastructure under Crossplane’s control. This enables a smooth transition where you can continue using your familiar infrastructure as code, while gradually replacing Terraform modules with native Crossplane Compositions at your own pace. This blog post goes deeper into this. But our infrastructure has complex logic! Perfect — so does spaghetti, and people still love it! Crossplane Composition Functions allow you to use a general-purpose programming language like Python or Go in your composition, which allows you to implement advanced logic to template resources, like loops and conditionals. So the sky’s the limit for what you can do there. But it’s not compatible with our current workflows? Crossplane is the Kubernetes approach to creating control planes and naturally fits into GitOps workflows with tools like Flux and ArgoCD. It’s less about replacing your workflows and more about enhancing them with powerful automation and standardization. But Crossplane is not production-ready! Ah, the classic skepticism — like saying Kubernetes wasn’t production-ready in 2016 (spoiler: it runs half the internet now). Sure, Crossplane is still an incubating CNCF project, and is about to release a new major version v2 soon. So it’s fair to say the product is maturing, and it’s not a one-size-fits-all solution. This doesn’t mean you should stay away from it; maybe even an opportunity for your team to start small, learn from your mistakes, and interact with the crossplane community. Think big, start small, fail fast, Iterate a lot. If this helped you, a few claps go a long way (and make my day 🙂 ). P.S. Follow me on LinkedIn

This presentation covers fundamentals of how Crossplane operates to practical insights on how to leverage its capabilities and if/where it should be used over other IaC tools like Terraform.