Table of Contents

• Introduction
• Context
  • The platform
  • Setup of the run
• How the run unfolded
  • The pipeline as executed
  • Timeline
  • Live log
  • Effort by agent
• The MAGI board in detail
  • Independent analyses
  • The three proposals
  • Cross-review with authors masked
  • Preventive review by QA, SRE, Security and the Tech Writer
  • Claim verification and selection
• Implementation: the code written by the developers
  • DEV1, the writer
  • DEV2, the pair
• Verification and reviews of the implemented change
  • QA: acceptance scenarios
  • SRE
  • Security
  • Tech Writer
  • Final review by the three architects
• Functional requirements: from request to evidence
  • Traceability
  • Requirement-by-requirement outcome
  • Findings overall
• Discussion
  • What the architecture changed in this run
  • Threats to validity
  • Cost of robustness
• Second run: the same request on Amazon Bedrock AgentCore
  • What AgentCore changes
  • The deployment in the AWS console
  • The run: a second design round
  • What it took to get a SUCCESS
  • What the gates did not see
  • Independent check outside the platform
  • Two runs side by side
• Conclusion
• Appendix: mandatory gates

Well, here we are again. After the autopsy of the agentic loop I wanted to see the engine on something bigger than a Python upgrade: a long, demanding change request, written by a human, in Italian, for a service that already exists. Not a toy, not a fix. A feature.

Table of Contents

• From a loop to a team
• The three endings
• The cast
• The graph
  • The brief
  • The architect’s tools
• The model proposes, the code decides
  • When a check fails: the code or the test?
• Thinking, only where it is needed
• The loops, and their bounds
• The journal: how roles talk to each other
• The job, and who holds the keys
• One engine, many projects
• LangGraph: what is used, and what is not
• Case study: Python 3.15 on flask
  • First act: the engine dies with the application
  • Second act: a repair in 7 minutes and 37 seconds
  • What the case shows
• How it got here: a day of corrections
  • Six replays of the same pull request
• Who watches the engine
• What it costs
• Reflections
  • What is still missing
• Conclusion

Well, here we are again. The first version of this engine was a loop: a writer, two reviewers, a judge for failing tests, a test steward, a documentation reviewer, all around a set of checks. It worked, and then it started to fail in ways a loop fails: one reviewer call that hung for twenty minutes, a writer that used eight rounds and proposed nothing, roles that sent the same change back to each other over and over, and a run that lasted 49 minutes.

Table of Contents

• AI-First and AI-Native
• Aurora: a Real AI-First Showback
• The Security Review as a Usage Strategy
• The Team’s Own Account
• Where the Speed Goes
• What AI-Native Looks Like
• The Sameness Risk
• How You Would Know
• Conclusion
• Reflections

Here we are. Everybody wants to measure how much faster AI makes developers, and it’s fair: an agent writes code faster, that’s indisputable. The number lands on a slide, next to a dollar figure and a session count, and everyone nods. Nobody asks what it’s divided by, or what happens to the code after it’s written.

Table of Contents

• Introduction
• The Problem: A Ticket for a Question
• Enter ldapsearch
• Why a Web UI on Top of It?
• The Architecture
• Setting Up the LDAP Client
• Searching Users and Groups
• Groups With Thousands of Members: Ranged Retrieval
• Running It
• Security Considerations
• Reflections
• Conclusion
• References

Here we are, one more ticket for a question that has a one-line answer.

Introduction

Every infrastructure person knows the scene. You need to know if a colleague is in a group, or who is in a group, or in which OU an account lives. You have no access to the domain controller, no AD console, no RSAT. So you open a ticket, wait for someone to read it, and get back a screenshot two days later.

Table of Contents

• Introduction
• From One NUC to Five Sites
• The Real Problem Isn’t Compute, It’s Memory
• Docs as Code, With Rules
• The Layout: Where New Things Go, Decided Once
• Templates: the Only Way New Hosts Look Like Old Hosts
• Runbooks Instead of “I Remember How I Did This”
• STATUS.md: the One File That Tells the Truth
• The Migration Folder: Rigor Where It’s Easy to Cut Corners
• Sysadmin via MCP: Claude Remote Agent, With Guardrails
• Reflections
• Three Questions for Your Own Docs
• Does This System Have a Name?
• Case Study: Watching the Agent Actually Use These Docs
• Conclusion

Table of Contents

• Why a Fallback at All
• Picking the Hardware
• Flashing OpenWrt
• The LTE Interface: qmi and the Vodafone APN
• Multi-WAN with mwan3
• An Emergency Wi-Fi AP
• The LuCI Dashboard, in Practice
• Conclusion
• Reflections

Here we are. In Italy, and we all know how it goes: it works today, tomorrow who knows.

Why a Fallback at All

I live in the countryside outside town, more farmland than periphery really, so I already count myself lucky to have FTTC at all. Mine is saturated and picks up crosstalk (diafonia) from neighboring pairs, which means the sync rate wanders and, every so often, the line just drops for hours.

Table of Contents

• The Problem
• Naaa… the alternatives
• The Pipeline
• The ai-analysis Job, Commented
• Downloading Results, Bundling the Source
• The Empty Report
• Downloading Artifacts, Watching the Run
• The AI Scripts
• The Report That Caught the Bug
• The Full Results, as an Example
• The Numbers
• Security Considerations
• Monitoring and Observability
• Conclusion
• Reflections

Here we are.

My debug/test API, pytbak, runs a proper CI: unit tests, linting, a Docker build, Trivy scanning, Checkov, a Kubernetes syntax check. Nothing exotic, just the usual pile of gates everyone bolts onto a pipeline these days. And every single one of them talks a different language. Trivy prints CVE tables. Checkov spits out a SARIF file and rule ids that mean nothing unless you’ve memorized them. kubectl describe gives you a wall of Kubernetes internals. pytest just wants you to count green dots. Each of these is perfectly readable, as long as you already speak that tool. Stack them all in one Actions log and you basically get a bunch of people talking over each other, none of them talking to you, unless you already know exactly where in the wall of text to look.

Table of Contents

• The thing I did not want to do
• Enter gh-aw
• Five workflows, one that runs itself
• How a run is wired
• The workflow file, in full
• PR #8: a hidden proxy endpoint
• What the run looked like
• The review it posted
• A finding is a challenge, not a verdict
  • The rate-limiter that is not a bug
  • The blocklist claim that is wrong in a detail
  • The firewall that fails silently
• Asking it to fix something, without letting it
• Pairing it with cybersecurity skills
  • How the agent picks its skills
• What the framework gets right
• Security considerations
  • The trust boundary, drawn
  • The prompt-injection threat model
  • Turning it off
• Cost and observability
• Conclusion
• Reflections
  • Why an LLM here, and not just more CI
  • The gaps that still bother me
  • What is still missing

Well, here we are: I wanted a second reviewer on every pull request, a sanity pass on every failed pipeline, and a monthly security sweep, and I was not willing to hand a language model a write token to get any of it.

Table of Contents

• Introduction
• The Police Uniform Analogy
• The Problem
• The Architecture
• The Proxy Worker
• Security Considerations
• Conclusion

Here we are.

Introduction

I love Cloudflare. I use it for all my projects. The free tier is generous, the API is clean, and the developer experience is miles ahead of competitors. If you’re building anything on the internet, Cloudflare should be your first stop.

But here’s the thing: Cloudflare’s trusted reputation can be used against you.

Table of Contents

• Introduction
• The Problem: A PDF Is Not an Interface
• The Architecture: From Contract to Skill
• Part One: What the App Must Be
  • Example 1: A Health-Check Clause Becomes Four Endpoints
  • Example 2: “No Root” Becomes a securityContext Block
  • Example 3: “No Persistent Data in a Container” Becomes Three Manifests
  • Example 4: A Four-Layer Image Hierarchy Becomes a Dockerfile and a Tag Strategy
• Part Two: What the App Must Say
  • Example 5: “Logs MUST Be JSON on stdout” Becomes a Logger and a Field Contract
  • Example 6: A Three-Tier Metrics Rule Becomes an Annotation and a NetworkPolicy
  • Example 7: “MUST Send Traces to a Collector” Becomes an SDK Init and an Egress Policy
  • Example 8: “Alert on Trends, Not Numbers” Becomes a Recording Rule and an HPA
• Part Three: Where the App Lives
  • Example 9: A Naming Convention Becomes a Derivation Rule
  • Example 10: “Never Commit a Plain Secret” Becomes Vault or AWS Secrets Manager
  • Example 11: “The Management Port MUST NOT Be Public” Becomes Three Absences
• Part Four: How the App Ships
  • Example 12: “No Human Tampering With the Artifact” Becomes a CI Workflow With Teeth
  • Example 13: Terraform Guardrails Become a Module Call You Cannot Widen
  • Example 14: “MUST Be in the Service Catalog First” Becomes Labels and a Generated Entry
• The Real Speedup: Building Something the Contract Never Anticipated
• How to Make Skills Actually Respected: The Gate
• From a Working App to a Platform Citizen
• Does the AI Actually Comply?
• Security Considerations
• Download the Skills
• Conclusion
• Reflections

Well. Every platform team eventually writes the same document: a PDF (or a Confluence page pretending to be one) that says what an application must do before it’s allowed to run on the shared cluster. Containerized. Non-root. Health endpoints on a specific port. No plain secrets in Git. It’s correct, it’s thorough, and almost nobody who needs to follow it has actually read it end to end.