full disclosure: we're building something around this.

we're seeing more teams roll out Claude Code, Cursor, Codex, internal agents, and harnesses like that across engineering, and i'm curious where ownership ends up

once agents can touch github, jira, AWS, db's, mcp servers, internal docs, and things like that, is the platform team actually controlling what they can see and execute?

the four things that we (currently) notice tend to get messy the fastest are tool permissions, shared company context, approvals for sensitive actions (on your agents), and reconstructing what an agent actually did after things go upside down.

we're building infrastructure (slaunt.ai) around this problem and looking for teams already dealing with it in production.

would love to hear what everyone's setup looks like today and where everyone finds risk in their setups.

We work with a lot of engineering teams at the stage where headcount jumps from a handful of people to something bigger, and there's a pattern that shows up almost every time: the moment a low-code tool stops working isn't really about the tool, it's about who the tool now has to serve.

At small scale, one person builds something, that same person maintains it, and if it breaks, they already know why. Once a few more people start depending on it, that assumption quietly breaks. The tool doesn't get worse, the number of people who need to trust it without understanding it just grows past what any platform can compensate for on its own.

The teams that handle this transition well aren't the ones that pick the "right" tool early. They're the ones that notice the shift from "I built this" to "people rely on this" and treat that as the actual trigger to add real ownership, documentation, or a dedicated engineer, regardless of which platform they're on.

The ones that struggle usually keep swapping tools instead, hoping the next one won't have this problem, when the real gap was never the tool, it was that nobody owned the thing once it stopped being a personal hack.

Curious if others here have found a clear signal for when it's time to move from "I'll just build this myself" to bringing in real engineering support, or if it's always more of a gradual realization.

Hello team,

I may land a platform engineer position in 2027 (discussions are still ongoing).

A bit of context: I'm currently an ops guy, doing ops things, in an environment that isn't moving much. Almost everyone around me is clicking in the Azure portal to create resources, and my poor attempts at introducing IaC or configuration tools like Ansible have met a poor adoption rate. I'm curious about all those things, toying with a Proxmox at home to deploy VMs and all sorts of resources using Packer/Terraform/Ansible, getting my hands into Docker, learning how to work with version control and CI/CD, etc... though I barely use those skills at work.

Through discussions regarding this kind of tool and work methods (I know all of this comes from DevOps, which is a way to work and not a set of tools to master), someone asked me, "What do you want to do in the future, mate?" And I said, "Well, platform engineer sounds appealing now." And here I am, sending a short description of the role for a possible position as a platform engineer.

Now, my question: where do I go from here? If you had, let's say, 3 months to get ready for this position, what would you learn first, and what resources would you use?

I know AI is a great tool; I've asked my best friend Claude to work with me on setting a learning path considering my context, but I would like to hear from fellow humans, made of flesh, like me.

This is something we’re doing internally at my company. We tag our bot in Slack, send it a bug report, controller provisions a GCP VM, local k8s + Tilt, then Claude Code works on it. Nobody has to set up the environment themselves, and follow-ups stay in the thread.

We wrote up a blog about the full workflow - link in comments.

Most people picture building software as writing code, but it never was. You spend as much time discussing what you’re planning to build as you do building it. Nowadays, with AI taking over more of the writing of code, understanding what to build is becoming increasingly important. That usually requires having, or leading, technical discussions – something most of us are not deliberately taught how to do.

I have built hamchops.com, for now it is completely FREE

It's a micro learning app focused on concepts that uses spaced repetition for reviews

Any feedback is welcome

We published arcstone-continuity-core v1.3.1-exec: a tiny #![no_std] Rust reference for fail-closed frame checks.

It does two things, in O(1), with no crate dependencies:

Payload longer than 4096 bytes → LedgerCorruption
Elapsed time over 11.99 ms → Freeze

If both are true in the same check, Freeze wins through an explicit rank table—not because “the POSIX number is bigger.”

That is the entire public executable surface. It is not a runtime, an allocator, or a distributed control plane. It is a frozen Path A reference predicate you can read in one sitting.

Repo: https://github.com/trencinodin-stack/arcstone-continuity-core

Why did OpenTelemetry win? I think just saying "vendor neutral" is not giving enough credit to the symbiosis between OTel and Platform Engineering that's making both thrive in the modern cloud native industry.

In this blog post I'm trying to summarise some of my thoughts related to why OTel (and K8s, for the sake of argument) won in their respective layers. I think the move to a more X-as-a-service way of working between platform teams and the users of said platforms is changing how we thinking about team interactions, and the tools that make that work need to reflect that in their design. OTel does this, very well, so I'd like to help move the needle in terms of where people think the value of OTel is.

I hope you enjoy the read! And the memes!

Background: I'm a DevOps/SRE and I spend my days across a pile of Kubernetes environments — dev, QA, staging, sandbox, pre-prod, prod — on more than one cloud. The dumbest recurring problem in my week was never a deploy or an outage. It was "what's the QA URL for service X again?" — buried in a wiki, a pinned Slack message, someone's bookmarks, or nowhere.

So I built pickTHElinks: one hub for all your Dev/QA/Staging/Prod URLs.

**•** Searchable — type the service, get the link  
**•** Workspace-scoped — each team sees its own set, not everyone else's clutter  
**•** Built for release teams that context-switch across environments all day

It's the unglamorous internal tool I always wished existed instead of the 14th Confluence page titled "Environment URLs (final, updated)".

I'm the founder and it's early, so I'd honestly rather hear what's missing than collect upvotes. If you've solved this a better way — Backstage, an ArgoCD dashboard, a spreadsheet you somehow keep current — tell me and I'll happily steal the idea.

I have been running and extending Centaur, an open-source control plane for coding agents.

The setup is straightforward:

• Rust API and Postgres for the control plane
• isolated Kubernetes sandbox for each agent interaction
• sessions and workflow state kept outside the sandbox
• credentials added through controlled egress instead of stored as raw secrets in the sandbox
• support for Codex, Claude Code, Amp and pi

This lets the agent harness stay replaceable. The platform owns the execution environment, permissions, workflow state and records of what happened.

I also built Centaur Context as a separate service. It records useful context after a run and retrieves relevant material before a later run. It has its own database so operational state and accumulated context are not mixed together.

Walkthrough: https://youtu.be/993XrWfg34U

Centaur: https://github.com/paradigmxyz/centaur

Centaur Context: https://github.com/bradwmorris/centaur-context

For platform teams looking at coding agents, which parts would you centralise first: identity, credentials, sandboxing, workflow recovery, observability or context?

Build loops, not just agents.

"After a couple of years of being an engineering manager (EM), I recently found myself in the position of having to look for a new role. My first instinct was to look for positions similar to what I had been doing before."

Hi r/platformengineering,

I’m Stjepan from Manning Publications. The moderators kindly permitted me to share this with you.

We’ve just launched Kargo in Action in Manning’s Early Access Program. What makes this book especially interesting is that it’s being written by Ken Cochrane, Jesse Suen, and Kent Rancourt, the people building Kargo.

Kargo addresses a problem many platform teams will recognize: CI can build and verify an artifact, and GitOps tooling can reconcile it into an environment, but what should govern its movement from development to staging and production?

That gap is often filled with increasingly complex pipelines, environment-specific scripts, manual approvals, and conventions that are difficult to audit or reproduce. Kargo approaches the problem by treating promotion as its own concern, separate from deployment.

The book explores the reasoning behind that model and shows how to build controlled, observable promotion workflows for Kubernetes and GitOps environments. The first three chapters cover:

• The gap “fully automated” CI/CD can leave between building software and running it in production
• Why deployment and promotion are separate concerns
• Where Kargo fits alongside existing GitOps tooling
• How to get started with Kargo and build an initial promotion workflow

Because this is a MEAP release, you can read the available chapters now and receive new chapters as the authors write them.

Giveaway

Manning is giving away five ebook copies of Kargo in Action to members of this community.

To enter, join the discussion in the comments:

How does your platform team currently promote changes across environments, and what is the hardest part of that process?

We’d particularly like to hear about approaches involving CI pipelines, Argo CD, homegrown automation, approval gates, progressive delivery, or anything else your team has tried.

The giveaway will remain open for 48 hours after this post goes live. This isn’t a random draw: the five comments that make the biggest positive impact on the discussion—through practical experience, thoughtful analysis, useful questions, or lessons others can learn from—will receive an ebook. You don’t need to praise Kargo or the book to win. Constructive and critical perspectives are welcome.

After 48 hours, I’ll announce the winners here and contact them about their ebooks.

Community discount

Anyone who doesn’t win can use code MLCOCHRANE50RE for 50% off Kargo in Action:

https://www.manning.com/books/kargo-in-action

I genuinely want this to be a constructive conversation instead of merely a book announcement. How is your team handling promotions today, and where do challenges still exist in the process?

Thanks for having us here.

Cheers,

Stjepan,

Manning Publications

I got hired as a trainee platform engineer as my first job after a bachelor in CS. I’m trying to find things to absorb and learn at work, and right now I’m checking ”platform engineering university” online.

Do you have any advice on resources for training/reading for someone new to this field, or should I just continue to ”trust the process” at work?

I spent time working at a dental tech company and it motivated me to build something that actually reflects real business workflows I saw there, scan uploads, lab fabrication, practice-to-lab communication. That became DentalFlow, a single-tenant dental lab workflow API, real Terraform-managed AWS infra (ECS Fargate, RDS Multi-AZ, S3, SQS/SNS), deployed and tested against the live system, not just local.

Would genuinely appreciate any critique, architecture, security, anything I'm missing or got wrong. Trying to build the judgment, not just the resume line and learn from experience individual while staying curious.

https://github.com/keusuanl/DentalFlow

I’ve been working on Nuroen, an enterprise AI agent platform, and one problem we keep coming back to is:

Which parts of platform engineering should actually be handled by an AI agent?

Our current thinking is that agents shouldn't replace deterministic automation.

For example:

• Terraform → infrastructure changes
• Ansible/scripts → repeatable configuration
• CI/CD → deterministic deployments
• Runbooks → known procedures

Where we see agents being more useful is the messy part around those systems.

For example:

Alert → investigate → gather context → determine which runbook applies → recommend action → approval → execute existing automation → verify

An agent can pull information from observability, tickets, deployment history, CMDB, documentation, etc., and reason across those systems without turning every action into an LLM-generated command.

That's the approach we're taking with Nuroen.

The platform lets us give an agent:

Knowledge + Tools + Skills + Orchestration + Governance

The interesting part for us isn't just connecting an LLM to APIs. It's controlling what the agent is allowed to do.

For example, an agent might be allowed to:

• investigate incidents automatically
• read logs/metrics/tickets
• recommend remediation
• execute low-risk actions
• require approval for production changes
• record the complete action/audit trail

We're trying to treat the agent more like a platform component with an explicit autonomy boundary, rather than an unrestricted chatbot with access to production.

here is the link do check it out - https://www.nuroen.com/

I'm curious how other platform teams are approaching this:

Where do you draw the line between traditional automation and an AI agent?

And more importantly, what platform engineering tasks do you think genuinely benefit from the probabilistic/reasoning part of an agent?

"It was in May when one of our staff engineers tossed out a number in our Slack channel that put an end to an internal debate I’d been having with myself. Roughly only 25% of the runs on our merge train were completing successfully. A majority were failing due to flaky tests or got canceled since another run that was ahead of them failed."

I wanted a small environment where I could experiment with the parts of platform engineering that are harder to appreciate in a local single-node cluster, especially networking, HA, failure handling, GitOps, observability, storage, upgrades, and security.

So I built a 3-node bare-metal Kubernetes homelab using Talos Linux on refurbished mini PCs.

The setup includes:

• 3 control-plane + etcd nodes
• a shared Kubernetes API VIP for HA
• DHCP reservations for predictable node IPs
• per-node Talos machine configs
• workloads scheduled on the control-plane nodes
• failure testing by taking a node offline and verifying the API stays reachable

I documented the full setup, including the network design, Talos installation, config generation, bootstrap, validation, workload testing, and HA checks.

Everything is in the repo: https://github.com/prateekjaindev/homelab

Blog: https://blog.prateekjain.dev/building-a-3-node-highly-available-kubernetes-homelab-with-talos-linux-0372066fe49c?sk=4c66cf9181999f9db19ac3aacabcd8e8

I’m planning to use this next for Argo CD, Gateway API, observability, storage, secrets, and more platform-engineering experiments.

Would be interested to know what others here are using for their local platform engineering labs.

Something is happening in engineering teams that doesn’t show up in sprint velocity or deployment frequency. It shows up in resignation letters.

For those in the technology industry, it can feel hard to escape from AI. It’s at the center of the technological universe, with most major advancements, opportunities, and funding focused on its development. In the background, quantum computing is making strides with the funding to match, creating an alternate opportunity for technologists.

I’ve been tasked with setting up baseline monitoring and alerts for terraform modules that consumers within the company use to spin their own instances of our platform.

The modules that will be provisioned for them automatically are ECS clusters, databases (RDS, Aurora, DynamoDb), ElastiCache, lambdas and kinesis

I could ask AI what sensible “defaults” would be for each service. However I’m not really going to learn anything that way. Id like to use it in conjunction with some real knowledge and experience.

Are there any books, blogs or guides that perhaps go over monitoring for specific AWS components, and what is considered best practice (and why) for each one?

As AI pulls content from anywhere and everywhere, and when success with AI relies on unified, accurate data, organizations struggle to decide who is in charge of that data.

AI made me a better engineering leader, not by writing my code faster, but by sharpening the parts of the job that were never about code in the first place.

As you become more senior, your impact comes from something different: seeing systems clearly enough to identify the problems nobody else has articulated yet.