# pulumi-neo Published articles for pulumi-neo. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Neo Security: Securing Infrastructure in the Agentic Era DevFeed: [Neo Security: Securing Infrastructure in the Agentic Era]() Original publisher: [Read original article]() Author: Joe Duffy Published: 2026-08-28T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [Security](), [cloud-infrastructure](), [Artificial Intelligence](), [Infrastructure as code](), [Static code analysis]() Tags: [agent](), [agentic](), [ai](), [aws](), [azure](), [cloud-infrastructure](), [infrastructure-as-code](), [kubernetes](), [product](), [pulumi](), [pulumi-neo](), [security]() ### AI overview Pulumi is opening a research preview of Neo Security, an agent that analyzes cloud infrastructure for exploitable flaws. It builds a threat model, maps attack paths, and produces an actionable security posture report, including for infrastructure provisioned across AWS, Azure, Google Cloud, and Kubernetes. ### Source excerpt Recently, AI systems have started turning up exploitable flaws in code that survived decades of human review. The frontier labs have released useful tools to help uncover many of these flaws through agent-led static code analysis. This is a huge leap ahead, but cloud infrastructure has many exploitable flaws that code analysis alone cannot find. These flaws are often as severe as the ones in code, or worse, and they await discovery by malicious agents on offense. We realized recently we can uniquely help here. At Pulumi, we have complete visibility into your entire cloud estate: infrastructure resources, their semantics, connections and dependencies between them, runtime logs and information, and more -- and have built an entire context graph out of them that is accessible to agents. Thanks to large language models, the cost of analyzing that full context graph is no longer prohibitive. As a result, today we're opening a research preview of Pulumi Neo Security. Neo Security is an agent that can find exploitable flaws in your cloud infrastructure. It starts with a threat model of your cloud estate, and then works systematically through every potential point of attack. The result is a security posture report that is immediately actionable thanks to Pulumi's infrastructure as code technology. Neo Security works on your existing infrastructure regardless of how it was provisioned, across any of our thousands of cloud providers including AWS, Azure, Google Cloud, and Kubernetes. We're releasing it in research preview to begin, so we can work closely with customers to run and address any findings. If you'd like to give it a try, contact us. How it finds attack paths Neo Security's aim is to provide a high-confidence, actionable security posture report. It gets there in three passes. The first builds a threat model, before it looks for anything. It works out what your crown jewels are, which resources are accessible to outside actors, which accounts hold production data, wh ## Pulumi Context API: query your infrastructure as a graph DevFeed: [Pulumi Context API: query your infrastructure as a graph]() Original publisher: [Read original article]() Author: Levi Blackstone Published: 2026-08-26T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [API](), [Graphs](), [Cloud APIs](), [infrastructure as code (IAC)](), [Command-line interface](), [JSON](), [pulumi-neo]() Tags: [agent](), [ai-agents](), [api](), [cli](), [features](), [graph](), [iac](), [infrastructure-as-code-iac](), [json](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [rest-api]() ### AI overview Pulumi is launching the Context API, a read-only API that connects Pulumi-managed and discovered resources, stacks, and their relationships into a graph. Available in public preview for Enterprise and Business Critical organizations, it supports infrastructure-impact, coverage, and cleanup queries through the Pulumi CLI or REST API. Pulumi Neo uses it out of the box, and other authenticated agents can access its schema and query guidance. ### Source excerpt Every platform team fields the same questions: What is running? What breaks if we change this? What can we safely delete? The answers exist, but they're scattered across state files, cloud consoles, and the memories of whoever set things up. Today we're launching the Pulumi Context API, a read-only API that connects Pulumi-managed and discovered resources, stacks, and their relationships into a graph. It's designed agent-first: Pulumi Neo, our infrastructure agent, uses it out of the box, and other agents can fetch the current graph vocabulary and query guidance on demand. It's available in public preview for organizations on the Enterprise and Business Critical editions. Answers that follow infrastructure relationships Pulumi already records the resources your programs manage, their dependencies, how stacks consume each other's outputs, and the resources Pulumi Discovery finds outside infrastructure as code (IaC). The Context API connects this data so you can ask questions that depend on the relationships: Impact: Which stacks are affected if we upgrade this provider? If this stack changes, what consumes its outputs? Coverage: How much of our infrastructure lives outside IaC, and in which accounts? Cleanup: Which stacks have no dependents and are candidates for retirement? A query is a JSON document with a handful of clauses. anchor names the starting nodes, traverse follows relationships from there, and return chooses what comes back. You can run a query through the Pulumi CLI or REST API. Here's a selector that starts from AWS provider instances older than version 7.0.0 and follows incoming provided_by relationships back to the visible resources they manage: { "anchor": { "nodeType": "resource", "match": { "type": "pulumi:providers:aws", "fields": { "provider_version": { "op": "lt", "value": "7.0.0" } } } }, "traverse": [ { "edgeTypes": ["provided_by"], "direction": "in", "alias": "managed" } ], "return": { "select": ["anchor", "managed"] } } A response for one m ## Pulumi Introduces Notification Center for Pulumi Cloud DevFeed: [Pulumi Introduces Notification Center for Pulumi Cloud]() Original publisher: [Read original article]() Author: Tom King Published: 2026-08-11T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud]() Tags: [console](), [email](), [esc](), [features](), [github](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [real-time](), [review](), [slack]() ### AI overview Pulumi introduces Notification Center, an inbox in the Pulumi Cloud console for task completions, approval requests, and billing alerts. Notifications appear in real time, link directly to the required action, and can be delivered in the console or by email with per-type preferences. ### Source excerpt Plenty happens in a Pulumi organization while you're looking somewhere else. Neo finishes a task you kicked off just before taking lunch. A teammate submits an ESC change request that needs your approval before it can land. Until now, catching any of that meant either keeping the right tab open or hoping the right email reached you. Today we're introducing the Notification Center: a single inbox in the Pulumi Cloud console for the things that actually need you. It lives behind the bell in the sidebar, with a dot when something's waiting. Notifications arrive in real time -- no refresh -- and each one carries exactly one action: Review request, View task, Update billing. Click it and you land on the page where you can do the thing, not on a dashboard where you have to go find it. What you'll hear about We've started with the moments where being a few minutes late actually costs you something: a Neo task that's paused waiting on your approval, a Neo task that's finished, an ESC change request waiting on your sign-off, and billing conditions like a locked organization or a trial that's about to end. Relevant people in your organization will be notified when there's a pending approval, or billing alert. Nobody gets paged for someone else's work. Where you'll hear about it Every notification type can be delivered two ways -- in the console and over email -- and you choose per type, per channel. Organization admins set a sensible baseline for everyone; each person can override it for themselves on their account settings page. What's next The Notification Center is available today. We're starting with this set of notifications and expanding from there. If there's an event you'd rather hear about from the bell than from a colleague on Slack, we'd like to know which one. Join our Community Slack to connect with the Pulumi team and other users, or open an issue on our GitHub repository. ## Migrate CloudFormation to Pulumi with Discovered Stacks DevFeed: [Migrate CloudFormation to Pulumi with Discovered Stacks]() Original publisher: [Read original article]() Author: Alejandro Cotroneo Published: 2026-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [AWS CloudFormation](), [migration](), [Amazon Web Services](), [VPC](), [Amazon S3](), [DynamoDB](), [AWS IAM]() Tags: [aws](), [cloudformation](), [dynamodb](), [git](), [iac](), [iam](), [import](), [insights](), [kms](), [migration](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [s3](), [tutorials](), [vpc]() ### AI overview A tutorial shows how to migrate a 61-resource AWS CloudFormation stack to Pulumi using Discovered Stacks in Pulumi Cloud. It explains how to find the stack, review migration status, start the migration, resolve unmatched resources, and verify the result with a zero-diff pulumi preview. ### Source excerpt With Discovered Stacks, Pulumi Cloud does the bookkeeping for a CloudFormation migration: every resource in the stack gets an explicit migration status, and the migration is done when the code provably matches the cloud. In this tutorial, we take one real CloudFormation stack from discovered to migrated and managed by Pulumi IaC, end to end. What we're migrating Our example is payments-api, a CloudFormation stack with 61 resources: a VPC, an Aurora ledger database behind an RDS Proxy, an assets S3 bucket, a DynamoDB ledger table, a Kinesis payment-events pipeline, and the IAM roles, KMS keys, and secrets that wire them together. The plan has five steps: Find the stack in Pulumi Cloud. Review the migration breakdown at a glance. Start the migration. Resolve the stragglers, so every resource is accounted for. Confirm the quality gate: a zero-diff pulumi preview. We'll use Pulumi Neo to do the heavy lifting, but nothing here depends on it. The same flow works with your own coding agent or entirely by hand, because migration status is derived from actual stack state -- however the work gets done, the console shows the same progress. Step 1: Find your stack in Pulumi Cloud Discovered Stacks builds on Discovery, so the only prerequisite is a scanned cloud account -- the AWS account holding your CloudFormation stacks. Once a scan has run, open the Stacks page and turn on Show Discovered Stacks. Your CloudFormation stacks appear alongside your Pulumi stacks. The project name comes from the CloudFormation stack (payments-api), and the stack name encodes the account and region it came from, so the same template deployed to two regions shows up as two distinct discovered stacks. Step 2: Plan the migration at a glance Open the discovered stack's Migration tab. It lays out all 61 resources of payments-api by status, so you can visualize the migration before touching anything: 54 Ready: mapped to a Pulumi type and confirmed to exist -- importable right now. 2 Not found: mapped, but ## How to Run AI Agents on Kubernetes with Pulumi DevFeed: [How to Run AI Agents on Kubernetes with Pulumi]() Original publisher: [Read original article]() Author: Joe Duffy Published: 2026-07-28T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Kubernetes](), [AI Agent](), [Artificial Intelligence](), [GPU](), [Python](), [TypeScript]() Tags: [agents](), [ai](), [ai-agents](), [deployment](), [general](), [gpu](), [inference](), [infrastructure](), [infrastructure-as-code](), [kubernetes](), [mcp](), [platform-engineering](), [pulumi](), [pulumi-neo](), [python](), [typescript]() ### AI overview This tutorial examines how Kubernetes infrastructure must be designed differently for AI agents, focusing on GPU scheduling, long-lived state, secrets, external tool access, and governance. It covers the agentic-Kubernetes ecosystem and provisioning with Pulumi using TypeScript and Python, including the role of Pulumi Neo. ### Source excerpt Kubernetes has become the default place teams run agentic AI workloads: CNCF's 2026 annual survey found that 66% of organizations hosting generative AI models use Kubernetes to manage some or all of their inference workloads.1 An entire ecosystem has grown up around that fact -- agent runtimes, model servers, GPU schedulers -- and most of it assumes the infrastructure underneath is already handled. It usually isn't. An AI agent is not a stateless web service, and provisioning for one takes more than copying a Deployment YAML and swapping the image. I spend a lot of my time these days thinking about what changes when the thing consuming your infrastructure isn't a person or a fixed pipeline, but an agent making its own calls about what to do next -- and Kubernetes is where I keep seeing that question show up first, because it's already where most teams run everything else. This post is about that gap: what changes about Kubernetes infrastructure when the workload is an agent, what the current agentic-Kubernetes ecosystem actually looks like, and how to provision and govern that infrastructure with Pulumi using TypeScript and Python -- plus where Pulumi Neo fits once the infrastructure itself has to answer to an agent. If you haven't read our take on the broader shift toward agentic infrastructure, What Is Agentic Infrastructure? is a good companion piece; this post stays specific to the Kubernetes layer. What makes agentic AI workloads different from ordinary Kubernetes workloads? An agent's resource and governance profile looks nothing like a typical web service, largely because it schedules accelerators, holds state across long sessions, and reaches out to systems a normal Deployment never touches. Dimension Typical web service Agent workload Compute CPU, predictable Often GPU/accelerator, bursty Session shape Short-lived, stateless requests Long-lived sessions, conversational state Egress Internal services, one database Model provider APIs, arbitrary tools, other agen ## Introducing Usage Limits for Pulumi Neo DevFeed: [Introducing Usage Limits for Pulumi Neo]() Original publisher: [Read original article]() Author: John Keiser Published: 2026-07-14T15:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [AI Agent](), [Artificial Intelligence](), [Cloud]() Tags: [agent](), [ai](), [ai-agent](), [ai-agents](), [billing](), [cloud](), [features](), [notifications](), [organization](), [product](), [pulumi](), [pulumi-cloud](), [pulumi-neo](), [token]() ### AI overview Pulumi introduces usage limits for Pulumi Neo, allowing paid-plan organizations to set monthly organization and per-member dollar limits. Neo pauses when a limit is reached, resumes in the next billing period, and supports email alerts at specified thresholds. ### Source excerpt Pulumi Neo is an AI agent that takes on real infrastructure work, and it's natural to want to hand it more and more. Usage limits give you control so you can do exactly that: set a monthly dollar limit, and Neo pauses when your organization reaches it. How usage limits work Your organization limit is a single monthly dollar amount covering all Neo usage across the org. To set one: In the Pulumi Cloud console, navigate to Settings -> Billing & usage -> Neo token usage. In the Manage token usage panel, enter an organization limit. Save your changes. When usage reaches the limit, Neo pauses for the rest of the billing period and resumes automatically at the start of the next one. An Admin or Billing Manager can raise the limit to resume before then. Enforcement happens at a natural boundary in Neo's work, so a task already in progress finishes its current step before pausing. As a result, usage can go a few dollars over the set limit. Per-member limits and alerts You can also set a separate limit for each member. A member is paused at whichever limit is smaller: their own or the organization's. For example, a member with a $200 limit under a $150 organization limit pauses at $150, because the organization limit is smaller. Turn on Enable email notifications to get a heads-up before you reach the limit. Billing admins are alerted at 50%, 80%, and 95% of the organization limit, with a final notice at 100% when Neo pauses. Get started Set your usage limits and stay in control as your organization hands Neo more and more work. Usage limits are available today for organizations on a paid plan, and an Admin or Billing Manager can set them. Sign in to Pulumi Cloud and set your first organization limit Read the Neo usage limits documentation for per-member limits, alerts, and enforcement details Join the Community Slack to share your feedback ## Neo code reviews: AI code review built for infrastructure DevFeed: [Neo code reviews: AI code review built for infrastructure]() Original publisher: [Read original article]() Author: Pulumi Neo Team Published: 2026-06-22T15:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [ai code review](), [Infrastructure as code](), [pull-requests](), [GitHub]() Tags: [ai](), [ai-agents](), [ai-code-review](), [features](), [github](), [governance](), [infrastructure-as-code](), [logging](), [preview](), [product](), [pull-requests](), [pulumi-neo]() ### AI overview Pulumi introduces Neo code reviews in public preview. The feature analyzes GitHub pull requests alongside Pulumi Cloud infrastructure state, preview output, stack relationships, and dependencies to provide high-level and code-level feedback. It supports automatic or mention-triggered reviews, with governance controls including RBAC, guardrails, and audit logging. ### Source excerpt Today we're introducing Pulumi Neo code reviews, now in public preview. Neo code reviews analyze pull request changes in conjunction with what Pulumi Cloud knows about your running infrastructure, providing both high-level and code-level feedback. Normal code review agents can't reliably anticipate the impact an infrastructure-as-code change will have. This is because they don't have access to critical aspects of the IaC workflow: the potential impact the update will have, in this case the pulumi preview output; and the current state of the cloud infrastructure. Neo not only has access to both of those, but also to the entirety of your other cloud context, such as stack relationships and dependencies. Running reviews Neo can review every pull request automatically, or only when someone mentions @pulumi-neo. Either way, it skips draft pull requests and those opened by bots by default. A review is a comment, so it informs the person approving the merge and sits alongside the required checks and branch protection you already enforce. Neo code reviews run inside the same governance as every other Neo task, with the RBAC, guardrails, and audit logging your organization has set. Enable code reviews Neo code reviews are available on GitHub during public preview. They require Pulumi Neo to be enabled for your organization, the Pulumi GitHub App installed on the repositories you want reviewed, and a one-time grant from each organization user to access their GitHub account under Management > Version control. If Neo currently posts preview summaries on your pull requests, code reviews are already enabled, and they take the place of those summaries. Neo code reviews are free while in public preview. On July 1, 2026, they'll be generally available, and reviews will begin counting toward your organization's Neo token usage, at the same per-token rate as any other Neo task. The pricing page shows that rate and the monthly token allotment included with each plan. Give it a try Open ## Loop Engineering for Coding Agents DevFeed: [Loop Engineering for Coding Agents]() Original publisher: [Read original article]() Author: Engin Diri Published: 2026-06-09T00:00:00Z Content type: opinion Language: en Sources: [Pulumi]() Topics: [Loop Engineering](), [Claude Code](), [Artificial Intelligence](), [Tooling]() Tags: [agent](), [ai](), [ai-agents](), [automation](), [claude](), [claude-code](), [perspectives](), [platform-engineering](), [prompting](), [pulumi-neo](), [tooling]() ### AI overview An opinion article argues that work with coding agents is shifting from manually writing successive prompts to designing automated loops that identify work, prompt agents, evaluate results, and select next steps. ### Source excerpt For about two years, the unit of work with a coding agent was the prompt. You wrote a good one, you gave it enough context, you read what came back, and you wrote the next one. The agent was a tool, and you were holding it the entire time, one turn after another. That part is ending. Addy Osmani, a director of AI at Google Cloud, has a name for what replaces it, and I have not stopped thinking about it since: loop engineering. You stop being the person who prompts the agent. You design the loop that prompts it for you. In my phrasing: you stop being the thing that runs, and start designing the thing that runs. The leverage moves up a layer. What I want to do here is take an honest look at the pieces, and at the part nobody automates. The leverage moved up a layer The people building these tools have already made the jump. Peter Steinberger has been posting it as a monthly reminder. Peter Steinberger (@steipete) on X. Boris Cherny, who heads Claude Code at Anthropic, says the same thing about his own job. He does not prompt Claude anymore. He has loops running that prompt Claude and decide what to do next, scanning the issue tracker, the team chat, and the timeline for what to build. "My job is to write loops." A loop is a goal that prompts itself. You set the purpose, and the system keeps iterating until it's met. In practice it finds the work, hands it out, checks the result, writes down what got finished, and decides the next thing, then it pokes the agent instead of you. You build that small system once and let it run. Look closer, and a loop is really two loops nested. The inner one does the work against a spec. The outer one decides what the work should be: it watches an issue tracker, an error feed, a changelog, then writes the next spec and hands it down. Most people are still running that outer loop by hand, in their head, and calling it a backlog. The part that surprised me is that this is barely a tooling problem anymore. A year ago a loop meant a pile of ## A Five-Pattern Playbook for Running Parallel AI Coding Agents with Pulumi DevFeed: [A Five-Pattern Playbook for Running Parallel AI Coding Agents with Pulumi]() Original publisher: [Read original article]() Author: Engin Diri Published: 2026-06-02T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [AI-assisted coding](), [ai-coding](), [Git](), [GitHub](), [Pull Request]() Tags: [ai](), [ai-agents](), [ai-coding-agents](), [automation](), [best-practices](), [coding-agents](), [concurrent](), [git](), [github](), [infrastructure-as-code](), [platform-engineering](), [pull-request](), [pulumi-neo](), [self-healing]() ### AI overview The article presents a five-pattern playbook for running multiple AI coding agents concurrently. It uses issues as specifications, a plan/build/validate workflow, isolated Git worktrees, fresh-session review, and a self-healing layer. The approach is described for application code, with infrastructure work identified as a further question. ### Source excerpt AI coding has two shapes right now. One agent in a loop, sequential work, you babysitting the chat window. Call that 2x. Most teams live here. Five agents in worktrees, parallel work, fresh-context review on every change. Call that 10x. The trick: 2x is mostly prompting, 10x is mostly plumbing. The parallel coding playbook is a five-pattern setup for running multiple AI coding agents at the same time without them stepping on each other: an issue used as the spec, a plan/build/validate loop, parallel git worktrees, fresh-session review, and a self-healing layer. The whole thing targets application code. The interesting question, and the one I keep ending up at, is what changes when the five agents are touching infrastructure. 2x is prompting, 10x is plumbing 2x is one human, one agent, one repo, one branch. The agent writes, you review, you tell it to try again, it tries again. The bottleneck is your attention. Whatever the agent's raw throughput, your reading speed sets the ceiling. 10x moves you out of the per-change loop and into the issue loop. You write five issues with sharp acceptance criteria, send each one to its own agent in its own worktree, and let them plan, build, and validate end-to-end. You read five PRs at lunch instead of pair-programming on one all morning. Concurrent isolation does the work. And isolation is mostly an infrastructure problem. The five pillars The five pillars, in one sentence each. Issue is the spec. The GitHub issue carries the acceptance criteria. The pull request is the artifact that gets validated. Input and output of every implementation are versioned, scoped, and reviewable on their own. Plan, build, validate. Three stages, three artifacts. A markdown plan you can read in thirty seconds. A build that produces a diff. A validate step that checks the diff against the spec. Parallel worktrees. Each agent runs in its own git worktree so concurrent changes never trample each other. One repo, five working trees, five branches. Fres ## Bringing Neo to GitHub and Slack DevFeed: [Bringing Neo to GitHub and Slack]() Original publisher: [Read original article]() Author: Pulumi Neo Team Published: 2026-05-21T15:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [GitHub](), [Slack](), [Pull Request](), [configuration](), [Cloud]() Tags: [agent](), [ai](), [ai-agents](), [configuration](), [features](), [github](), [product](), [pull-request](), [pulumi-cloud](), [pulumi-neo](), [slack]() ### AI overview Pulumi Neo is now available in GitHub and Slack, extending its existing Pulumi Cloud console and terminal capabilities into team discussion threads. Users can ask Neo to inspect stack state, explain changes, investigate failures, and perform approved actions, with responses and follow-up work recorded in the relevant thread. ### Source excerpt This week, Pulumi Neo started working in two more places: GitHub and Slack. The agent that already runs Pulumi tasks from the Cloud console and the terminal now participates in the threads where your team discusses changes. Mention @pulumi-neo in a pull request or issue and Neo replies in the thread. Mention @Neo in a Slack channel and Neo starts a task, continuing the conversation as you reply. Neo in GitHub Mention @pulumi-neo in a pull request description, a top-level or inline review comment, or an issue. Neo sees the diff, the stacks linked to the repository, and their current state. Reviewers can ask Neo to walk through what a proposed change does, including resources that change in stacks the PR doesn't touch directly. Responses land in the same thread, so the analysis becomes part of the review record and any follow-up stays with it. Neo in Slack Mention @Neo in any channel where Neo has been added, and Neo starts a task in the thread. The reply lands in the same thread, and follow-up messages continue the conversation there. The rest of the channel can see what was asked and what Neo found. Neo has the same capabilities here as in the Pulumi Cloud console or the terminal: check stack state, investigate failures, walk through what a change will do, or carry out actions the team has approved. Integrations in action A teammate posts in #platform-engineering: "API latency p95 has been climbing for two days, nobody can figure out why." You reply: You: @Neo check the production API stack. Anything change in the last 72 hours? Neo starts a task in the thread, walks the stack history, and finds a configuration change to the load balancer's idle-timeout setting that landed Friday afternoon. It posts the change, who deployed it, and when. The rest of the channel sees the finding without you having to retell it. You: @Neo open a PR to revert idle-timeout to the previous value. Neo edits the stack's Pulumi program, runs pulumi preview to confirm the change touches only ## Neo Automations: Scheduled Tasks Shipped as Pull Requests DevFeed: [Neo Automations: Scheduled Tasks Shipped as Pull Requests]() Original publisher: [Read original article]() Author: Pulumi Neo Team Published: 2026-05-21T14:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [pulumi-neo](), [Automation](), [pull-requests](), [pulumi](), [Amazon Web Services](), [Kubernetes]() Tags: [ai](), [ai-agents](), [automation](), [aws](), [features](), [kubernetes](), [product](), [pull-requests](), [pulumi](), [pulumi-neo]() ### AI overview Pulumi Neo now supports scheduled automations that run tasks on hourly, daily, weekday, or weekly cadences and open pull requests for proposed changes. The launch includes templates for provider freshness, encryption, backup, and activity audits, along with configurable prompts, permissions, and integrations. ### Source excerpt Recurring platform work slips: provider versions fall behind, drift accumulates between checks, and the quarterly audit keeps getting pushed back another month. Pulumi Neo can now run any task on a cadence you set, opening a pull request for each run. Automations in action Your platform team runs stacks across staging and production, and the AWS, GCP, and Kubernetes providers keep shipping new versions. Nobody has time to bump them stack by stack. You write one automation: Every Monday at 8 AM, check the infra/ project for stacks where the AWS, GCP, or Kubernetes provider is more than two minor versions behind. For each one, bump the out-of-date provider, run pulumi preview, and open a PR if the preview is clean. Monday morning, Neo runs the prompt. It finds three stacks behind on the AWS provider, edits each program, runs preview, and opens a PR for each clean run. You review the PRs like you would any other dependency bump, merge them, and Neo runs again next Monday. What automations are for The launch includes four built-in templates: a provider freshness check, an encryption audit, a backup audit, and an activity digest. You can also skip the templates and write your own prompt. Pick from hourly, daily, weekdays, or weekly cadences. Each automation gets its own page in the Automations tab, where you can edit the prompt, change the schedule, run it once on demand, or pause it. Safe by default Automations default to two settings that fit recurring work. Approval mode is auto, so a run doesn't wait for human confirmation between steps. Permission mode is read-only, so a run can read state and propose changes through pull requests but can't apply changes directly. You can override either default per automation. How automations fit with the rest of Neo A scheduled task uses the same context as an interactive Neo task. Custom Instructions at the organization and project level apply, so a scheduled run respects the same naming conventions, tagging policies, and archite ## Seven Rules for Building an AI-Native Software Factory DevFeed: [Seven Rules for Building an AI-Native Software Factory]() Original publisher: [Read original article]() Author: Adam Gordon Bell Published: 2026-05-21T13:00:00Z Content type: opinion Language: en Sources: [Pulumi]() Topics: [Artificial Intelligence](), [AI Development](), [Development](), [Software Engineering](), [Amazon Web Services]() Tags: [agentic-ai](), [agents](), [ai](), [ai-agents](), [aws](), [building](), [customers](), [engineering](), [esc](), [governance](), [infrastructure-as-code](), [pulumi-neo](), [software-development]() ### AI overview Ewan Dawson describes seven rules for building and operating an AI-native software factory, based on Compostable AI's experience. The article argues that organizations should redesign software workflows around autonomous agents, start with a focused team, involve governance and compliance early, and remove risks by changing the problem rather than adding controls. ### Source excerpt Ewan Dawson is CTO of Compostable AI, where five engineers run an AI-native software factory: nineteen clients, custom AWS deployments, most of them shipped within a day of contract signing. This article is adapted from his recent Pulumi webinar, and covers rules in more depth than we had time for on stage. For the past twenty years, I've viewed software development as a craft. The best engineers drew on decades of experience to get every function right. But two years into the agentic AI revolution, I realised software is going to look more like a factory than a craft. The economics have changed. We can't treat code as bespoke anymore. To scale, we have to think industrial -- use the tools to ship more value with fewer engineers. I joined Compostable AI soon after it was founded 2.5 years ago, and I built the engineering org AI-native from day one. The technology has come a long way since then, and so has my understanding of what AI-native actually means. Here are seven rules I keep coming back to. An AI software factory is a software operation where autonomous agents write and ship most of the code. The engineers stop writing it by hand and spend their time deciding what gets built and talking to customers. The rules below are our rules for building and running an AI-native software factory. 1. Transform, don't enhance Going AI-native isn't an upgrade to your existing process. If you treat AI as a way to hand your developers smarter tools, you leave most of the value on the table. You get the leverage by rebuilding how you write software -- and the culture and processes around it. I know that's a tall order for a large, mature engineering org. My advice: start small. Pick one team or one business area and run it as a fully AI-native function. Take what you learn and roll it out from there. And do the political work early, especially with your Governance, Risk, and Compliance function. Get GRC on your side early. Otherwise AI becomes a compliance fight instead of a st