Swapping the model is the easy part. Everything wired to it is the project. Teams wire a model into their services, data, workflows and controls. Then a better model ships, or a customer needs a different environment, and the work around the model gets revisited. That surrounding system is what we built Guidepad for. Our patented Platform-as-Data architecture makes the system definition executable. It lives as records that Guidepad reads at runtime to build and govern the running system: - Types and Operations: the objects in your system and the actions available through auto-generated APIs. - Services and Environments: the long-running pieces of your system (a model, a database, an API, a front end) and where each one runs (cloud, on-prem, or edge). - Workflows and data mappings: how the work connects and where its data lives. - Data pipelines: ETL defined as records the runtime executes, not pipeline code. - Policies and authority: what people and agents are allowed to do. Take a model change. Point the model binding at another supported model service. Take an environment change. Point the environment binding at another environment you've prepared, such as a second cloud. The bindings change. The workflow and policy definitions stay intact. For consulting and forward-deployed engineering teams, those definitions become reusable assets. Each deployment gives the next one a starting point, so customers go live faster and margins improve. That's the idea behind Platform-as-Data: make the system itself programmable. Change the definition. The running system follows. guidepad.io

Agents aren't just writing code anymore. They're starting to contribute to system design. That shifts our highest leverage from implementation to specification, verification, and engineering the harness. At @aiDotEngineer, I talk about the shift. And the harness.

Enterprise AI is breaking at the same point every time. Chat works. Agents demo well. Then everything falls apart in production. Why? Because everyone is building leashes: permissions, guardrails, monitoring. That’s not enough. A leash tries to stop an agent from doing the wrong thing. A harness ensures the system only allows the right things to happen. We’re entering a world of: • dozens (soon hundreds) of models • multi-step agent workflows • constantly changing architectures The problem is no longer intelligence. It’s control. Not control of the model. Not control of the interface. Control of how: • data becomes context • context becomes reasoning • reasoning becomes decisions • decisions become action That’s the missing layer. At Guidepad, we built a patented Platform-as-Data architecture that governs systems at runtime: • workflows are executable • actions are enforced • decisions are traceable We don’t leash agents. We harness systems.

Context graphs are right — but incomplete. They don’t work when they’re reconstructed from logs and traces. They work when they’re produced by the system itself. That’s why we built our Platform-as-Data architecture, so context is generated by the system itself, not inferred after execution. That means modeling the system as data: • Intent • State transitions • Environments (cloud, on-prem, edge) • Operations — the executable actions that move the system between states (human + agent) AI doesn’t need more DevOps, MLOps, or Observability glue. The future isn’t more tooling around the stack. It’s fewer tools — and a system where intent, state, and execution are explicit

The next evolution of platform engineering is emerging — not more tools, but Generative Systems. Infra, Kubernetes, data pipelines, ML workflows, environments… We’re still stitching them together by hand. The result? - Fragile platforms - Constant drift - ML teams blocked by infra - AI that never makes it to prod At Guidepad, we built the next layer: Platform-as-Data. ✅ One system model for DevOps, DataOps & MLOps ✅ Define intent → system generates itself at runtime ✅ Cloud, hybrid, on-prem, air-gapped — same model ✅ AI-native: embeddings, experiment tracking, model deploys Instead of managing tools, the platform becomes generative, your APIs, workflows, services, infra all built from data. Developers describe intent. Guidepad assembles the system. The OS for autonomous engineering is here. 👉 DM us for a walkthrough. #PlatformEngineering #MLOps #DevOps #AIInfrastructure #GenAI #Kubernetes

The convergence of modern infrastructure is here: Cloud, Kubernetes, MLOps, Security, Compliance, Data Pipelines, Workflows… all stitched together by hand. The result? - Fragmented toolchains - Endless integration tax - Models that never make it to production At Guidepad, we built the next layer: Platform-as-Data. ✅ Unified control plane for DevOps, DataOps, and MLOps ✅ Define once → run anywhere (cloud, hybrid, bare metal, air-gapped) ✅ AI-native from the start — with declarative pipelines, feature stores, and governed deployments Instead of piecing tools together, Guidepad treats the entire system as data. That means developers program the system itself, not its parts. We’re building the OS of the modern engineering era. 👉 DM us if you’d like to learn more or see a demo. #PlatformEngineering #MLOps #AIInfrastructure #DevOps

🚀 Introducing the next evolution in distributed systems management! 🌐 See how we integrate Terraform & OpenTofu to redefine runtime state management. #DevOps #StateMachines #IaC guidepad.io/blog/introducing… #OpenTofu

The Real AI Coding Race: Why Success Lies in the Interface, Not the Model medium.com/@ivanburazin/the-… Thanks @swyx, @gneubig, @tylerjdunn, @zvonimirsabljic, @itamar_mar commenting drafts

We're going live at the @RawkodeAcademy with our good friends at @guidepadio. Mathew Citarella will be guiding us, pun intended, as we add a new feature to the Guidepad platform: NodeJS Lambda support. piped.video/watch?v=mM1bXEK7…

🚀 Dive into the Guidepad MLOps plugin demo to see how our experiment tracking framework revolutionizes model development! Easily log metrics, manage artifacts, and ensure model reproducibility, both locally and remotely. #MLOps #DataScience #MachineLearning #Serverless guidepad.io/blog/experiment-…

I often talk about what the future of IaC might look like, but what I envisage doesn't exist. So I set a challenge to the @guidepadio team ... how far did they get us? Let's take a look!

🌟 Breaking new ground in #Serverless! Discover how Guidepad is changing the game with our unique approach to portable code in distributed systems. 🚀 👨‍💻 For devs: Dynamic, real-time changes in your apps! 🔗 Dive in: guidepad.io/blog/portable-un… #Guidepad #CloudComputing #FutureIsNow

🌟#StartupSpotlight: @guidepadio 🚀 Transforming #SoftwareDevelopment with a novel Platform-as-Data approach! 👨‍💻Redefining how developers manage complex systems. 📅Catch their pitch at #BatcheryDemoDay on Dec 12th! RSVP➡️ kern.al/event/batchery-batch… #TechInnovation #Guidepad

AI for Dev Tools: Create Software Requirements with Userdoc thenewstack.io/ai-for-dev-to… @ricmac #AI #DevTools #developers #Userdoc

Today is a special video, because I got to kick the types on a new technology that isn't quite public yet; and I have the utmost pleasure to share it with you ... NOW 😀 Let me introduce you to guidepad. piped.video/HuQ6inYEBrs

[New post] w/ @martin_casado @satishtalluri We are seeing the emergence of *new architecture patterns* that extend strong transactional guarantees beyond the database, into the distributed apps themselves. Let's dive in 👇 a16z.com/2023/04/14/the-mode…

Is infrastructure-as-code the start of the commoditization and abstraction of cloud providers? Or will it simply just drive more spend? A few ideas: • IaC turns cloud infrastructure from a GUI to an API layer. I believe this also changes the end-user of many of these services, disintermediating many purely operational roles (e.g., Cloud IT) and going directly to developers. API layers can be abstracted away much more easily. • The new API layer is wholly controlled and tightly coupled to the underlying cloud provider. All IaC is bottlenecked by the underlying APIs. Terraform and Pulumi are ultimately limited by the underlying layer (e.g., Cloudformation in AWS). Updates will always come to cloud provider-controlled SDKs first. • Mid-tier SaaS applications will be overtaken by simple CDK configurations. Code can be copied more efficiently than GUI configurations. This means that a developer can copy-paste an architecture or framework (say, CDN + serverless functions). Why pay for third-party providers to do the same? • Developers crave commoditization. Operation-type folks are OK with getting AWS-certified and learning cloud-esoteric features; developers are not. Instead, developers want abstractions that they can build on – IaC provides that foundation. The surface area is so large that cloud providers can't possibly solve for all solutions. The question: will these abstractions capture the value they create (what's the business model)? • Competitors can commoditize the layers, too. No cloud provider supports native Terraform – instead, they built their own abstractions – AWS Cloudformation, Google Cloud Deployment Manager, and Azure Deployment Manager. But what if Google Cloud decided to support Cloudformation as a way of making AWS workloads more portable to Google Cloud? There are enough differences that this is hard to imagine, but it's not impossible (maybe for a third-party like Hashicorp, it is).

For anyone trying to figure out how to combine LLMs and dev tools: Someone replied to my thread asking for paper referencess. Here's a short list of program synthesis papers with that either already use machine learning, or could benefit from AI-based search. 1/