Author: Alan Shimel

  • Why Code Validation is the Next Frontier

    Why Code Validation is the Next Frontier

    Shared staging environments were never designed for a world where dozens of changes land in a codebase every hour. Yet most engineering teams still depend on them as the primary checkpoint before production. Alan Shimel and Arjun Iyer, CEO of Signadot, dig into why that model is falling apart and what needs to replace it.

    The root of the issue is straightforward. In a microservices architecture, verifying a single change means understanding how it interacts with every other service it touches. Shared staging environments try to replicate that, but when multiple engineers and AI tools are pushing changes at the same time, those environments become noisy. A test failure might be caused by the code under review or by an unrelated change from someone else. That ambiguity erodes confidence in the entire release process.

    Iyer makes the case that validation needs to move out of shared environments and into isolated, on-demand setups that reflect real production behavior. The goal is to give every change its own context for testing, eliminating the crosstalk that makes shared staging unreliable. This becomes especially important as AI-generated code increases the volume of changes flowing through a pipeline, since the validation layer has to keep pace without becoming the new queue that everyone is waiting on.

    The conversation raises a question that teams are going to face more frequently: is the deployment pipeline built to handle the throughput that modern development tools are capable of producing? For many organizations, the answer is not yet, and closing that gap is where the next wave of engineering investment is likely to go.

  • Giving AI Agents the Keys to Real Infrastructure

    Giving AI Agents the Keys to Real Infrastructure

    AI coding assistants can generate pull requests faster than most teams can review them, and that mismatch is creating a new kind of bottleneck across engineering organizations. The volume of AI-generated code is growing rapidly, but without a reliable way to validate that code against real production environments, teams are left choosing between slowing down to manually review everything or accepting the risk of pushing untested changes forward.

    Alan Shimel speaks with Sumeet Vaidya, CEO and co-founder of Crafting.dev, about the emerging concept of closed-loop autonomous development. The idea is straightforward: rather than treating AI agents as tools that hand off code for humans to verify, give those agents the ability to test their own output against live dependencies and real infrastructure before a human ever needs to get involved.

    The conversation explores what it takes to make that work in practice. Traditional sandboxing approaches struggle to replicate the complexity of production environments, where services interact with databases, APIs and other systems in ways that simplified test setups cannot capture. Vaidya argues that the next step for AI-assisted development is not better code generation but better code validation, ensuring that what gets produced actually behaves correctly in context.

    For DevOps and platform engineering teams, the implications are significant. If AI agents can reliably validate their own work, the role of human engineers shifts from gatekeeping individual pull requests to overseeing outcomes and setting guardrails. That changes how teams think about automation, testing pipelines and the division of labor between humans and machines in modern software delivery.

  • AI Is Forcing DevOps Teams to Rethink Observability Data Management

    AI Is Forcing DevOps Teams to Rethink Observability Data Management

    As AI coding tools accelerate software delivery, they are also intensifying a problem DevOps and SRE teams have been dealing with for years: the unchecked growth of observability data. In this conversation, the founders of Sawmills argue that telemetry volume is no longer just a cost issue. It is becoming a data quality problem that affects how effectively teams can monitor systems, troubleshoot incidents and make sense of production behavior.

    Ronit Belson and Erez Rusovsky describe how the rise of AI-generated code is making observability harder to manage. Instrumentation is often treated as an afterthought, which means more logs, metrics and traces are being generated without much discipline around relevance, quality or downstream impact. The result is familiar to many DevOps teams: rising observability bills, more noise in monitoring systems and growing difficulty separating useful telemetry from unnecessary data.

    Rather than waiting until data lands in production systems and then trying to reduce cost or improve signal quality after the fact, Belson and Rusovsky describe a model in which telemetry is reviewed and optimized closer to the point where code is written and deployed. That includes looking at instrumentation itself, not just the systems consuming it.

    They also touch on a broader operational shift now underway. As organizations become more comfortable with agentic AI, there is growing interest in using agents not only to write code, but also to continuously manage repetitive operational work. In the observability context, that means identifying noisy telemetry, highlighting gaps, feeding lessons from production back into development and helping teams keep data both useful and affordable.

    The bigger takeaway is that observability can no longer be treated as a downstream concern. If AI is going to keep increasing the speed of software creation, DevOps teams will need stronger control over the telemetry that software generates.