Jonathan Lalou's Blog

Lecturer

Sudi Mandyam is an Engineering Manager at Intradiem, bringing extensive experience in software engineering, site reliability engineering, and cloud technologies. With a background from Visvesvaraya Technological University and roles at organizations including Fastute.io and Navro, Sudi has established himself as a problem solver, leader, writer, and mentor in the technology sector. His insights into AI-driven transformations stem from hands-on leadership in engineering teams navigating rapid industry shifts.

Abstract

In this insightful presentation, Sudi Mandyam challenges prevailing narratives around artificial intelligence displacing developers. Instead, he positions AI as a powerful accelerator for career advancement, particularly for aspiring technologists. Through historical context, evolving AI capabilities, and practical demonstrations, the talk equips attendees with strategies to transition from fearing obsolescence to embracing architectural leadership in an agentic AI era.

The AI Shift: Perception Versus Reality

Sudi opens by highlighting the interconnected nature of technology, opportunities, and problems. He notes that while some perceive AI as a threat to coding professions, this view represents only one facet of a multifaceted evolution. Drawing an analogy to brick-making, he emphasizes that even as AI generates code, human architects remain essential for designing and constructing robust systems.

The presentation traces the rapid progression of AI frameworks over recent years. In 2022, tools like ChatGPT emerged as disruptors, initially seen as potential replacements for search engines. By 2024, solutions such as GitHub Copilot and advanced prompting techniques focused on enhancing speed and efficiency in code generation. However, challenges persisted, including model hallucinations arising from suboptimal prompts or model selections.

Advancing into 2025, agentic programming gained prominence with tools like Cursor and Windsurf, offering improved context handling for microservices and classes, thereby reducing “slop code.” Despite these advances, widespread adoption without adequate guardrails led to security concerns and operational issues. Sudi identifies the current landscape as the “agentic engineering era,” a new discipline layered atop traditional software engineering. Here, context-aware agents function as collaborative colleagues rather than mere coding engines, empowered by frameworks such as CrewAI and Google ADK.

A persistent limitation remains: agents perform only as effectively as the context provided. “Garbage in, garbage out” continues to apply, underscoring the need for sophisticated knowledge management.

Building Organizational Intelligence: LLM Wiki and Intelligent Triage

To address contextual gaps, Sudi introduces the LLM Wiki pattern, inspired by concepts from Andre Karpathy. This approach curates organizational information into a consumable markdown format via an incremental wiki compiler, creating a “second brain” that persists beyond individual experts. Unlike traditional retrieval-augmented generation that may require repeated parsing, the wiki maintains coherent, evolving knowledge repositories.

This second brain proves invaluable across scenarios, particularly incident management. Sudi presents the Intelligent Triage Mesh, which integrates LLM Wiki data, metrics, runbooks, and observability traces from tools like OpenTelemetry and DataDog. A multi-agent orchestration engine evaluates incidents, using confidence thresholds to determine whether automated remediation suffices or human intervention is required.

A live demonstration illustrates these principles in action. Simulating payment failures, an orchestrator leveraging the LLM Wiki decides between auto-remediation and human escalation. Implemented in Go with Google ADK, the system features a main Gemini-powered orchestrator alongside local models for specialized agents. Global policy overrides, managed via the second brain, allow non-technical stakeholders like product managers to update behaviors without code changes.

This methodology significantly improves key metrics such as Mean Time to Recovery (MTTR) within DORA frameworks, transforming incident resolution from hours to minutes.

Conclusion

Sudi Mandyam masterfully reframes AI not as a replacement engine but as rocket fuel for technical careers. By advocating a shift to agentic engineering mindsets and demonstrating practical implementations like contextual wikis and intelligent orchestration, the talk provides actionable pathways for developers to thrive amid technological disruption. Ultimately, the message resonates clearly: problems breed opportunities, and proactive engagement with AI tools positions aspiring speakers and engineers for sustained success.

Links:

• Video URL
• Sudi Mandyam on LinkedIn
• Intradiem

Lecturer

Jim Newton is an Assistant Research Professor at EPITA, a prestigious engineering school in Paris, France. A veteran Lisp programmer since 1988, Jim has worked extensively with various dialects, including Common Lisp, SKILL++, and Clojure. His research focuses on the theoretical foundations of type systems in dynamically typed languages. At EPITA, he teaches courses on functional programming using Clojure and Scala. He is the author of several research papers and a PhD thesis titled “Representing and Computing with Types in Dynamically Typed Languages,” which forms the basis for the Regular Type Expression (RTE) library.

Abstract

While string-based regular expressions are a staple of modern programming, their application to sequences of heterogeneous types remains a relatively unexplored domain. This article details the development of Regular Type Expressions (RTEs), a framework for recognizing regular patterns within sequences of mixed-type elements in Clojure. We examine the transition from classical character-based Finite Automata to Symbolic Finite Automata, where transitions are governed by type predicates rather than literal characters. The discussion covers the theoretical challenges of implementing such a system, including the embedding of a Simple Type System (SETS) into the Clojure runtime, the construction of Deterministic Finite Automata (DFAs), and the complexities of subtype determination in a dynamic environment.

Beyond Strings: The Concept of Regular Type Expressions

Clojure programs frequently manipulate sequences—lists, vectors, or streams—that contain a variety of data types (e.g., a mixture of integers, strings, and keywords). While developers often need to validate the structure of these sequences, standard regular expressions are limited to character data. RTEs generalize the concept of regular languages to the level of types. Just as a standard regex might match the pattern a(a|b)*b, an RTE can be defined to match a sequence that “starts with an integer, contains zero or more strings or doubles, and ends with a keyword.”
Jim Newton’s work bridges the gap between the flexibility of dynamic typing and the rigor of formal language theory. By treating types as the alphabet of a regular language, RTEs allow developers to specify complex structural constraints on data. This is particularly useful in Clojure for validating macro arguments, processing heterogeneous data streams, or implementing sophisticated pattern-matching algorithms that go beyond simple structure-based destructuring.

Theoretical Challenges and Implementation

The implementation of RTEs in Clojure required solving several deep theoretical problems. Unlike character-based regex engines, where the alphabet is finite and each character is distinct, the “alphabet” of types is potentially infinite and overlapping. For example, a value might simultaneously satisfy the types Number, Integer, and Positive-Integer.

1. The Simple Type System (SETS)

To support RTEs, a fundamental type system (SETS) had to be embedded into the Clojure runtime. This system supports boolean algebraic operations on types: union, intersection, and complement. This allows for the definition of complex types such as “an element that is a String but not ‘admin'” or “an element that is either an Integer or a Keyword.”

2. Symbolic Finite Automata

The core of the RTE engine is a Symbolic Finite Automaton. In a standard DFA, a transition from one state to another is triggered by a specific character. In a Symbolic DFA, a transition is triggered if the next element in the sequence satisfies a given type predicate. A significant challenge here is ensuring the DFA remains deterministic. If an element matches multiple outgoing transitions (due to overlapping types), the automaton would become non-deterministic. To solve this, the system must be able to partition the type space into disjoint sets.

3. Subtype Determination

A critical requirement for DFA construction is the ability to determine if one type is a subtype of another. In a dynamic language like Clojure, which allows arbitrary predicates as types, this is not always decidable. Jim’s research introduces a “clever procedure” for DFA construction that maintains determinism even when the subtype relation cannot be fully determined, ensuring that the library remains robust across a wide range of use cases.

Code Sample: Using RTEs in Clojure

(require '[clojure-rte.core :refer [rte-match]])
;; Define an RTE: an Integer, followed by one or more Strings, 
;; and ending with a Keyword.
(def my-pattern '(:cat Long (:* String) Keyword))
(rte-match my-pattern [1 "hello" "world" :done]) ; => true
(rte-match my-pattern [1 :done])                 ; => true
(rte-match my-pattern ["wrong" :done])           ; => false

Practical Implications and Conclusion

The development of the clojure-rte library provides Clojure developers with a powerful tool for data validation and pattern recognition. It allows for the detection of unreachable code (by identifying patterns that can never be matched) and enables highly expressive type-based dispatch. Because the system is built on a solid theoretical foundation, it handles edge cases—such as empty sets or overlapping type definitions—with mathematical precision.
This project is part of a larger, multi-language research effort, with implementations also available in Scala, Python, and Common Lisp. By bringing the rigor of Symbolic Finite Automata to Clojure, Jim Newton has provided a compelling example of how theoretical computer science can enhance the practical tools of modern software engineering, particularly in the realm of dynamic, data-driven applications.

Links:

• Jim Newton on GitHub
• Clojure-RTE Library on GitHub
• EPITA Research Profile
• Watch the Lecture: Recognizing Regular Patterns

Lecturer

Gerrit Grunwald is a highly regarded software engineer and advocate with four decades of experience in the technology sector. He is a prominent figure in the Java community, recognized as a Java Champion and a JavaOne Rockstar. Gerrit is deeply committed to open-source software, having contributed to and led numerous projects such as JFXtras, TilesFX, Medusa, and JDKMon. He founded and leads the Java User Group Münster and is a frequent speaker at international conferences. Currently, Gerrit serves as a Developer Advocate at Azul.

Abstract

This article provides an analytical overview of the modern Java Virtual Machine (JVM) landscape, distinguishing between the OpenJDK project and its various commercial and community distributions. It evaluates the shift in Java’s release cadence and the implications for long-term support (LTS) in corporate environments. A significant portion of the analysis is dedicated to the optimization of Java runtimes through modularity and the jlink tool, demonstrating how developers can significantly reduce deployment sizes and enhance security. Finally, the article categorizes the plethora of available JDK distributions—from major cloud providers like Amazon and Alibaba to specialized runtimes like GraalVM—offering a guide for selecting the appropriate distribution based on specific use cases.

The Distinction Between OpenJDK and Distributions

A fundamental misunderstanding in the Java community is the conflation of “OpenJDK” with the software installed on a user’s machine. OpenJDK is not a downloadable product but rather the open-source project hosted on GitHub that contains the source code for the Java Platform, Standard Edition (Java SE). What developers actually utilize are “builds” or “distributions” of this source code.

The OpenJDK ecosystem is characterized by its collaborative nature, with significant contributions from tech giants such as Oracle, Amazon, ARM, Google, Intel, and IBM. This multi-corporate backing ensures the longevity and stability of the platform, preventing it from becoming a “one-man show”. Since moving to GitHub with JDK 16, the transparency and accessibility of the source code have further improved, allowing for faster build times and broader community involvement.

Release Cadence and Support Models

The evolution of Java’s release model marks a critical transition from multi-year development cycles to a predictable six-month cadence. Historically, long gaps between releases (such as the five years between JDK 6 and JDK 7) led to massive, overwhelming updates that were difficult for organizations to adopt.

The current model classifies releases into two categories:

1. Feature Releases: Released every six months, these versions typically receive support for only half a year.
2. Long-Term Support (LTS) Releases: These versions are designated for extended support, often spanning a decade or more, providing the stability required by enterprise applications.

This dual-track approach allows the language to innovate rapidly through feature releases while providing a safe harbor for production environments on LTS versions.

Efficiency through Modularity: The jlink Revolution

One of the most underutilized innovations introduced in JDK 9 is the modularization of the Java runtime. By breaking the monolithic JDK into 69 distinct modules, Oracle enabled developers to create custom, stripped-down runtimes tailored to specific applications.

The tool jlink allows for the creation of a custom Java Runtime Environment (JRE) containing only the modules necessary for a particular application. The impact on deployment size is profound:

• A full JDK 21 installation requires approximately 340 MB.
• A standard JRE for the same version takes about 150 MB.
• A jlink-optimized runtime for a simple application (like a push notification server) can be as small as 48 MB.

echo Example of using jdeps to find required modules
jdeps --ignore-missing-deps --print-module-deps MyProject.jar
echo Example of using jlink to create a custom runtime
jlink --add-modules java.base,java.logging --output custom-runtime

Beyond storage savings, modular runtimes enhance security by reducing the attack surface. If a vulnerability exists in a module that has been excluded from the custom runtime (such as the desktop module in a server-side application), the application remains unaffected.

Mapping the Distribution Jungle

The JVM landscape is populated by numerous distributions, each offering different levels of support, licensing, and platform optimizations.

Community and Vendor Builds

• Eclipse Temurin (formerly AdoptOpenJDK): A widely used community build that is TCK (Technology Compatibility Kit) compliant.
• Amazon Corretto: A no-cost, multiplatform distribution used internally by Amazon for its AWS services.
• Azul Zulu: A TCK-compliant distribution offering broad platform support.
• Oracle OpenJDK: The free, GPL-licensed build provided by Oracle.

Region-Specific and Specialized Distributions

In the Asian market, distributions like Alibaba’s Dragonwell, Huawei’s Bi Sheng, and Tencent’s Kona are dominant. These often include specific optimizations for the cloud infrastructures of their respective parent companies.

Advanced Runtimes: GraalVM and Beyond

GraalVM represents a specialized branch of the JVM ecosystem, offering high-performance polyglot capabilities and “Native Image” compilation. Native images allow Java applications to start in milliseconds by compiling them into platform-specific executables, though this comes at the cost of peak performance and longer build times compared to the standard JIT (Just-In-Time) compilation used by the HotSpot JVM.

Conclusion: Strategy for Selection

Choosing the right JVM distribution is a strategic decision based on support requirements, cost, and technical constraints. For most production environments, sticking to an LTS version from a reputable vendor (like Azul, Amazon, or the Eclipse Foundation) ensures stability. Meanwhile, developers should leverage modern tools like jlink to ensure their deployments remain lean and secure, regardless of the distribution chosen.

Links:

• Gerrit Grunwald on X (Twitter)
• Harmonic Code (Gerrit’s Blog)
• OpenJDK Official Website
• Azul Systems Website
• Lecture Video: Welcome to the Jungle

For many Java developers,
generating cryptographically secure random values appears straightforward:

SecureRandom random = new SecureRandom();

or perhaps:

SecureRandom random = SecureRandom.getInstanceStrong();

Both approaches produce a SecureRandom instance. Both are
designed for cryptographic use cases. Both are significantly more secure than java.util.Random.

Yet beneath these seemingly simple APIs lies a surprisingly
complex interaction between the JVM, security providers, operating system entropy sources, and cryptographic standards.

Understanding these details is important because
the choice of random number generator can impact:

• Application startup time
• Cryptographic strength
• Portability across platforms
• Container and cloud deployment behavior
• Compliance requirements
• Operational reliability

This article examines how Java’s secure random number generation works, what differentiates new SecureRandom() from
SecureRandom.getInstanceStrong(), and which approach should be preferred in modern enterprise environments.

Why Cryptographically Secure Randomness
Matters

Modern applications rely on secure randomness far more often than many developers realize.

Common examples include:

• Session identifiers
• JWT signing keys
• Password reset tokens
• OAuth state parameters
• CSRF protection
• TLS handshakes
• Key generation
• Digital signatures
• Encryption initialization vectors
• Nonces

The fundamental requirement is unpredictability.

An attacker capable of predicting future outputs of a random number generator can often compromise the entire
security model of an application.

This is why Java provides SecureRandom, a cryptographically secure pseudo-random number generator (CSPRNG), specifically
designed to withstand prediction attacks.

What Happens When You Call new SecureRandom()?

Consider the following code:

SecureRandom random = new SecureRandom();

Most developers assume this directly instantiates a specific implementation.

In
reality, the JVM delegates the selection to the Java Security Provider architecture.

At runtime, Java:

1. Inspects the configured security providers
2. Searches for available SecureRandom implementations
3. Selects the preferred implementation
4. Instantiates and seeds it

The resulting algorithm depends on several factors:

• JDK version
• Operating system
• Security provider configuration
• Security policy

On contemporary JDKs (17, 21 and beyond), the implementation is frequently one of:

DRBG

or

NativePRNG

depending on platform and configuration.

You can verify the actual implementation:

SecureRandom random = new SecureRandom(); System.out.println(random.getAlgorithm()); System.out.println(random.getProvider());

Typical output:

DRBG SUN

or:

NativePRNG SUN

The important observation is that new SecureRandom() does not imply a particular algorithm. It requests the JVM’s default
secure random implementation.

Enter SecureRandom.getInstanceStrong()

Java 8 introduced a new API:

SecureRandom random =SecureRandom.getInstanceStrong();

This method has a different objective.

Rather than selecting the
default implementation, it requests the strongest secure random generator configured on the platform.

Internally, Java consults the following security property:

securerandom.strongAlgorithms

located in:

$JAVA_HOME/conf/security/java.security

Typical values may look like:

securerandom.strongAlgorithms= NativePRNGBlocking:SUN, DRBG:SUN

Java attempts to instantiate the first suitable candidate.

Unlike new
SecureRandom(), the resulting implementation is explicitly influenced by the platform’s definition of “strong”.

Historical Context: /dev/random
versus /dev/urandom

To understand why this distinction exists, we need to revisit Linux entropy management.

Historically, Linux exposed two primary
entropy interfaces:

/dev/random

and

/dev/urandom

/dev/random

• Uses entropy collected from environmental noise
• May block when entropy is considered insufficient
• Traditionally regarded as the most conservative source

/dev/urandom

• Non-blocking
• Uses a cryptographically secure internal PRNG
• Continues producing output even when entropy pools are depleted

For many years, security guidance often favored /dev/random for highly sensitive operations.

Consequently, some JVM implementations mapped “strong”
random generation to entropy sources capable of blocking.

This design decision eventually led to one of the most infamous operational issues in Java security.

The
Startup Hang Problem

Many developers encountered situations similar to the following:

SecureRandom random =SecureRandom.getInstanceStrong();

Application startup would appear frozen:

Starting Spring Boot application...

And then nothing.

The process was waiting for entropy.

This behavior was especially common in:

• Virtual machines
• Cloud environments
• Docker containers
• Kubernetes clusters
• Minimal Linux distributions

The issue was not Java itself. The underlying operating system simply refused to provide additional entropy at that moment.

How Modern Linux Changed the
Equation

Modern Linux kernels use the getrandom() system call and maintain cryptographically strong entropy pools that become secure shortly after system
initialization.

Today:

• Linux entropy management is significantly improved
• OpenJDK implementations have evolved accordingly
• Container platforms inherit entropy from mature host systems
• Blocking behavior is far less common

As a result, the historical distinction between /dev/random and /dev/urandom has become much less relevant for most production workloads.

The Rise of DRBG

Since JDK 9, Java includes support for NIST SP 800-90A Deterministic Random Bit Generators (DRBGs).

SecureRandom random =SecureRandom.getInstance("DRBG");

DRBG implementations provide:

• Well-defined cryptographic properties
• Explicit security strength
• Standardized behavior
• Alignment with modern compliance frameworks

What Should You Use in Spring Boot on EKS?

Consider a typical modern deployment:

Spring Boot↓ Container↓ Amazon EKS↓ EC2↓ Linux Kernel

For this environment, the recommended choice is usually:

private static final SecureRandom RANDOM =new SecureRandom();

or, when explicit algorithm selection is desired:

SecureRandom.getInstance("DRBG");

Using SecureRandom.getInstanceStrong() is generally unnecessary unless your
organization has specific compliance or regulatory requirements demanding the strongest available implementation.

Conclusion

The distinction between new
SecureRandom() and SecureRandom.getInstanceStrong() reflects the evolution of both operating systems and the JVM.

For most enterprise Java workloads,
including Spring Boot applications deployed on Kubernetes, EKS, ECS, OpenShift, or traditional Linux servers, new SecureRandom() provides an excellent balance of
security, performance, portability, and operational reliability.

When stronger guarantees or compliance requirements exist, DRBG or getInstanceStrong() may
be appropriate. However, these should be deliberate architectural choices rather than defaults applied indiscriminately.

In modern Java platforms, secure randomness is no
longer primarily about finding the strongest entropy source. It is about selecting a solution that delivers robust cryptographic guarantees while remaining operationally
predictable at scale.

Lecturers

Resh Desai, Zach Miller, and Jake Farrell presented this session. Resh Desai works as a solutions architect at Amazon Web Services, driving forward developments in secrets management. Zach Miller is a Senior Worldwide Security Specialist Solutions Architect at AWS, specializing in cryptography, keys, secrets, and certificates. Jake Farrell serves as Senior Director of Engineering at Acquia, which provides open digital experience platforms.

Abstract

The presentation sheds light on the evolution of secrets management, highlighting AWS Secrets Manager as a central tool for handling the complete lifecycle of sensitive credentials. It weighs the advantages and drawbacks of centralized versus decentralized approaches, outlines key capabilities like encryption, automated rotation, cross-region replication, and high-volume retrieval, and details Acquia’s comprehensive migration efforts. In addition, it explores strategies for multi-tenant separation, patterns for Kubernetes integration, future synergies with agentic AI, and the latest service improvements that support third-party rotations and easier container-based deployments.

Core Functionalities of AWS Secrets Manager

AWS Secrets Manager provides a purpose-built service dedicated to managing the entire lifecycle of application secrets, database credentials, and API keys, setting it apart from IAM for identity management or KMS for cryptographic operations. By design, every secret undergoes envelope encryption with AWS-managed KMS keys, though users can opt for customer-managed keys to support scenarios such as cross-account sharing.

This setup integrates smoothly with CloudTrail to deliver thorough auditing of all actions, from creation and modification to deletion. Automation through Lambda enables rotation schedules that align precisely with enterprise policies, whether set at 30 or 90 days. For resilience, multi-region replication ensures secrets remain available during regional failovers. The service handles up to 10,000 transactions per second for retrieval, further enhanced by an open-source agent that implements caching with configurable time-to-live periods, thereby improving both efficiency and the overall developer experience.

Together, these features create a secure and traceable environment that integrates seamlessly with the wider AWS security landscape.

Navigating Centralized and Decentralized Deployment Choices

When designing secrets storage, architects must decide between consolidating secrets in a single dedicated account or distributing them closer to the applications that consume them. Centralized configurations often resonate with organizations in regulated sectors, as they allow for standardized practices in naming, tagging, and permission enforcement—typically achieved through enforced CI/CD pipelines or bespoke abstraction layers. Such consistency bolsters monitoring and control across the enterprise, although it requires significant initial investment in development and can introduce latency when adopting newly released capabilities.

On the other hand, a decentralized model empowers individual application teams to manage secrets directly via consoles or SDKs, offering greater adaptability to unique requirements. This approach streamlines onboarding and accommodates specialized needs more naturally, but it calls for robust supplementary governance to ensure alignment with broader standards.

In practice, the ideal configuration depends on factors like secret creation processes, ongoing management, replication demands, access patterns, and visibility needs, reflecting insights gathered from diverse customer experiences rather than a one-size-fits-all rule.

Acquia’s Migration Experience and Multi-Tenant Architecture

Acquia maintains oversight of over 300,000 distinct secret paths distributed across multiple AWS accounts, supporting millions of daily ephemeral pod instances and tens of thousands of hourly API interactions. Moving away from older systems required careful categorization of secrets into groups such as customer-supplied elements (including third-party tokens and environment variables), internal service communications, and emerging hybrid forms suited to AI agents.

To manage this complexity, Acquia developed a custom fronting API that applies type-specific rules for validation, scoping, and lifecycle policies, such as mandatory rotation or timed expiry. Rigorous least-privilege principles ensure complete separation between platform operations and customer data. For delivery into runtime environments, the organization relies on open-source components like the External Secrets Operator combined with AWS CSI drivers, which synchronize and inject secrets into Kubernetes as variables, configuration templates, or command-line flags. Strategic caching layers further reduce direct API calls, delivering noticeable gains in speed and expense control.

Through this disciplined, layered framework, Acquia achieves robust multi-tenancy while addressing gaps that IAM alone cannot fully cover in interconnected service scenarios.

Future Directions in Agentic AI Collaboration

Looking ahead, Acquia’s designs feature an AI gateway that provides a unified point for observing model invocations routed through Amazon Bedrock, complemented by a standardized factory for quickly provisioning secure agents. By embedding Secrets Manager deeply, the platform enables on-demand injection of properly scoped credentials, allowing smooth evolution alongside emerging AI features without compromising protective measures.

This ongoing partnership with AWS has yielded tangible benefits in operational streamlining, lower maintenance burdens, and enhanced overall performance.

Latest Service Developments and Their Wider Impact

Innovations continue to simplify adoption in container environments, with EKS add-ons now automating the installation and configuration of CSI drivers. The introduction of managed external secrets brings one-click rotation capabilities to external providers like Salesforce, removing the need for custom scripting and eliminating risks of desynchronization.

Native integrations now span more than 55 AWS services, making secret management largely invisible to end users. These progresses reduce entry barriers to advanced security practices, enabling teams to concentrate on innovation even as autonomous systems increase demands on privilege management.

In essence, effective secrets governance forms the bedrock of durable, expandable systems vital for both current operations and forthcoming intelligent workloads.

Links:

• Lecture Video
• Jake Farrell on LinkedIn
• Acquia Official Website

Lecturer

Annie Freeman is a Developer Advocate at Coralogix, specializing in full-stack observability platforms and the responsible deployment of AI applications. With a background in green software practices and a focus on sustainability in technology, Annie explores how visibility into AI systems can address challenges related to cost, ethics, and operational reliability.

Abstract

The rapid adoption of AI systems, particularly those involving large language models and agentic workflows, introduces significant complexities around trust, resource consumption, and ethical behavior. Traditional monitoring approaches often prove insufficient for these dynamic environments. Annie Freeman examines how observability, implemented through OpenTelemetry, can establish robust systems of trust around AI applications. By analyzing four distinct layers of observability—from development tools to quality monitoring—the discussion highlights practical strategies for instrumenting AI workloads, detecting issues such as hallucinations or policy violations, and implementing real-time guardrails. These insights enable organizations to build AI solutions that are not only performant but also accountable and sustainable.

The Fundamental Challenge: Why Traditional Monitoring Falls Short for AI

AI systems differ fundamentally from conventional software in their non-deterministic nature. The same input can produce varying outputs, agentic loops may execute unpredictable numbers of tool calls, and decision-making processes remain opaque. This unpredictability creates multiple layers of risk: potential harm from inappropriate responses, escalating operational costs from uncontrolled resource usage, and difficulties in capacity planning due to variable inference demands.

Users require consistent and reliable experiences. Company leadership must ensure investments yield clear business value without runaway expenses. Developers, increasingly reliant on AI coding assistants as production dependencies, need confidence in the generated outputs. Traditional metrics focused on uptime or basic performance fail to capture these nuances. Without targeted observability, teams operate with limited visibility into model behavior, making it impossible to verify ethical alignment or optimize resource utilization effectively.

Establishing Foundational Observability: Development and Operational Layers

Observability begins at the development stage, where AI coding tools such as Claude Code or CodeWhisperer generate substantial portions of application logic. These tools emit OpenTelemetry data natively, providing metrics on token usage, cost per session, model selection patterns, and code acceptance rates. Such visibility transforms subjective assessments of tool effectiveness into data-driven insights, enabling teams to optimize developer productivity and identify which models deliver the highest value for specific tasks.

Operational metrics extend this foundation into production environments. Key signals include token consumption trends, model invocation patterns, and response finish reasons. These indicators function analogously to HTTP status codes, revealing whether completions result from natural termination, length limits, or other constraints. High-spending users or unusual patterns, such as excessive retry loops, become immediately apparent. Organizations can then implement targeted optimizations, such as adjusting model sizes for specific use cases or imposing limits on tool call iterations.

The unified nature of OpenTelemetry ensures that AI telemetry integrates seamlessly with existing application monitoring. This avoids data silos and enables comprehensive system analysis. Teams gain the ability to correlate AI behavior with broader application performance, facilitating more informed architectural decisions.

Enhancing Decision Transparency and Real-Time Protection

Decision tracing provides critical context for understanding not just what an AI system produces but why it arrived at particular conclusions. By instrumenting agentic loops with custom spans, teams can capture detailed information about each step: input validation, prompt construction, tool selection, and reasoning chains. This granular visibility transforms black-box operations into auditable processes.

OpenTelemetry’s semantic conventions standardize the collection of this data, ensuring consistency across different AI workloads. Traces reveal the complete journey of a request, from initial user input through multiple reasoning iterations to final output. Such transparency supports debugging, compliance requirements, and continuous improvement efforts.

Quality monitoring introduces an additional safeguard layer. Small language models serve as specialized evaluators, analyzing outputs for hallucinations, toxicity, policy violations, or relevance issues. These evaluators operate with high accuracy due to their focused training, providing rapid feedback without the latency of larger models. When combined with guardrails, this approach enables real-time intervention. Suspicious inputs or outputs can be blocked before reaching users, maintaining system integrity and user trust.

Practical Implementation and Long-Term Benefits

Implementing these observability layers requires intentional design but yields substantial returns. OpenTelemetry’s vendor-neutral approach prevents lock-in while leveraging existing infrastructure investments. Teams can begin with basic instrumentation and progressively add sophistication as needs evolve.

The framework supports multiple stakeholder requirements simultaneously. Users benefit from consistent, safe interactions. Leadership gains visibility into costs and value delivery. Developers receive actionable insights for refining both AI components and their integration with business logic.

As AI adoption accelerates, observability becomes the cornerstone of responsible deployment. Systems built with comprehensive monitoring demonstrate greater reliability, ethical alignment, and operational efficiency. The investment in observability infrastructure pays dividends through reduced incidents, optimized resource usage, and enhanced organizational confidence in AI capabilities.

By treating observability as integral to AI system design rather than an afterthought, teams can move beyond experimental prototypes toward production-grade solutions that earn and maintain user trust.

Links:

• Video: Un-observable AI is un-trustworthy AI by Annie Freeman
• Annie Freeman on LinkedIn

In the crucible of code creation, where reliability reigns supreme, Rob Richardson, a testing titan and DevOps devotee, distills the discipline of .NET testing with ASP.NET Core’s crafted clarity. As a polyglot programmer and pipeline proponent, Rob reveals the rigor of XUnit, the framework favored by Microsoft’s makers, to fortify features against fragility. His live-coded liturgy, bereft of slides, builds bulwarks—dependency dissolution, mock mastery—ensuring applications ascend with assurance.

Rob revels in the rush: testing as theme-park thrill, where validation vaults vexation into victory. ASP.NET Core’s architecture, he asserts, is testability’s triumph—dependency injection dismantling dependencies, XUnit’s exactitude exposing errors.

Foundations of Fortitude: XUnit’s Exactitude

XUnit anchors assurance: facts ferret functionality, theories thread theorems—Rob’s repertoire renders regressions rare. His canvas: a sample ASP.NET Core canvas, controllers carved, services sculpted. Dependency injection decouples: IHttpClientFactory forges facades, mocks mimicking markets.

Rob’s ritual: arrange, act, assert—test triples taming turmoil. His demo: endpoints exercised, responses ratified—StatusCode 200, JSON jousted—validation via verbatim victories.

Mocking the Monolith: Dependency Dissolution

Dependencies daunt: external APIs, databases defy determinism. Rob’s remedy: Moq’s mimicry—interfaces impersonated, behaviors bespoke. HttpClient’s havoc harnessed: fake factories fabricate fetches, ensuring endpoint explorations endure.

His nuance: minimal mocks—focus on functions, not frameworks. Rob’s rule: test the terrain—controllers’ contracts, services’ semantics—sans superfluous simulations.

Pipeline Prowess: DevOps Discipline

CI/CD consecrates confidence: GitHub Actions galvanize gates, .NET CLI commands—restore, build, test—tightening tolerances. Rob reveals: dotnet test triggers triumphs, TRX reports tabulating truths. His flourish: workflow dispatch, a “run now” rune, ridding redundant revisions.

Performance persists: hundreds hum in seconds, containers catalyzing celerity. Rob’s report: test tabulations, timing tallied—confidence cemented.

Validation’s Vanguard: Building Belief

Rob’s rallying cry: from zero to zenith—one test begets battalions. His exhortation: embed tests in ethos, pipelines as provers, features as fortified. XUnit’s x-factor: debuggability, discoverability—bugs banished before birth.

His horizon: testing as triumph, where .NET’s native nous nurtures resilience, reliability revered.

Links:

• Rob Richardson on LinkedIn
• Rob Richardson’s website

Lecturer

Barry van Someren operates a compact DevOps hosting and consulting enterprise named CoffeeSprout ICT Services. Previously engaged as a dedicated Java programmer, he now oversees Java-based systems and develops in-house solutions. Barry positions himself as an expert in averting common operational pitfalls such as memory exhaustion or storage shortages.

Abstract

This article scrutinizes the unconventional deployment of Claude Code, an AI-driven coding aide, in domains extending far beyond software creation. It probes into Barry’s methodologies for leveraging the tool in operational duties, infrastructure orchestration, and ad hoc automations, grounded in tangible scenarios. The examination encompasses the inception of these applications, practical executions, triumphs alongside mishaps, and ramifications for forthcoming AI-facilitated workflows in DevOps landscapes.

Inception and Justification for Extended Applications

The genesis of employing Claude Code for purposes unrelated to programming emerged from routine engagements with large language models in configuration oversight. Barry initially harnessed these models to craft Ansible playbooks, a YAML-centric framework for delineating system states. Ansible facilitates the depiction of desired configurations, enabling automated enforcement across servers. During one such interaction, the model proposed executing a command to ascertain a file path, sparking the realization that Claude could transcend mere suggestion to active participation in debugging and setup on development platforms.

This pivot stems from the acknowledgment that numerous operational elements mirror code structures. Infrastructure configurations, for instance, can be codified, while fleeting assignments may not warrant full-fledged scripting. Recurring chores often reveal themselves post hoc, prompting Barry to instruct Claude to formulate reusable scripts after task completion. Notably, this approach eschews intricate prompt crafting; initiating a dialogue within Claude’s interface, refining directives iteratively, suffices for efficacious outcomes.

Furthermore, the rationale hinges on friction reduction in learning novel utilities. Barry recounts configuring a rudimentary virtual machine, where Claude undertook preparatory steps, thereby expediting assimilation of unfamiliar technologies. This proves particularly advantageous in conference settings like Devoxx, where novel concepts abound, allowing practitioners to experiment swiftly without exhaustive manual setup.

Claude Code’s allure lies in its subscription framework, mitigating earlier credit-based expenditures that could escalate to substantial sums daily. The advent of affordable plans democratizes access, rendering it viable for exploratory uses. Its acumen in encoding and tool proficiency outpaces contemporaries, although rivals like ChatGPT’s Codex narrow the disparity. Consequently, Barry advocates for its adoption in streamlining DevOps, transforming mundane operations into efficient processes.

Methodological Executions and Illustrative Cases

Barry’s technique involves granting Claude terminal access within controlled environs, such as virtual machines or containers, to execute commands and scripts. This necessitates safeguards: employing disposable instances, restricting privileges via non-root users, and isolating sensitive data. For demonstration, he configures a Spring Pet Clinic application on Ubuntu, commencing with package updates and Java installation.

In one instance, Claude autonomously installs PostgreSQL, initializes a database, and integrates it with the application by modifying configuration files. It generates passwords—albeit simplistic ones—and applies them consistently, showcasing its aptitude for cross-file correlation. Another example entails heap analysis on a Java application; Claude employs jmap to capture heap dumps, analyzes them with jhat, and identifies memory leaks, all while navigating command-line intricacies.

A compliance scenario highlights versatility: adhering to energy conservation regulations, Claude devises scripts to throttle CPU frequencies during off-hours, generates audit logs, and verifies adherence, yielding a 15% reduction in power consumption. Similarly, it processes Excel sheets to execute scripts per user, excluding managerial roles, demonstrating data handling prowess.

These cases underscore repeatability without elaborate guidance. Barry emphasizes commencing with explicit plans, segmenting tasks, and verifying outputs. For Git repositories, Claude clones projects, inspects commit histories, and pinpoints version-specific issues. In Kubernetes contexts, it traverses namespaces, scrutinizes deployments, and peruses pod logs expeditiously.

However, executions demand vigilance. Barry recounts an episode where Claude rebooted a machine prematurely, failing to update boot configurations correctly, underscoring the imperative for output scrutiny. Nonetheless, the tool’s self-correction upon feedback enhances reliability.

Evaluation of Outcomes and Derived Insights

Assessing these applications reveals both efficacies and deficiencies. Successes include adept repository analysis, where Claude discerned alterations across versions, aiding troubleshooting. Its proficiency in interlinking configurations—such as database credentials in application properties—proves invaluable for intricate setups. Moreover, it accelerates tool acquisition, beneficial for client engagements involving novel technologies.

In Kubernetes diagnostics, Claude’s rapid log inspection outpaces manual efforts, facilitating swift resolutions. Log analysis on sanitized files identifies anomalies effectively, while test data generation populates schemas comprehensively. One-off automations address procrastinated tasks, and local container setups streamline development without advanced frameworks.

Conversely, pitfalls abound. Premature completion declarations necessitate clear doneness criteria and measurable objectives. Reading comprehension lapses, as in the misinterpretation of grub update outputs, mimic human errors but require intervention. Context exhaustion precipitates erratic behavior, mandating task fragmentation.

Barry advises defining scopes meticulously, verifying successes, and managing contexts to avert spirals. Despite these, the tool’s utility in DevOps outweighs risks when confined to non-production realms.

Ramifications and Prospective Trajectories

The implications extend to redefining DevOps workflows, where AI aides like Claude diminish manual toil, permitting focus on strategic endeavors. This fosters agility, particularly in compliance and reporting, where generated artifacts ensure regulatory adherence efficiently.

Looking ahead, the convergence of open-source models like Mistral with frontier capabilities portends broader accessibility. Barry speculates that simpler deployments may soon operate on local models, reducing dependency on proprietary services. Tools like Aider, permitting model selection, herald this shift.

In essence, Claude Code’s repurposing exemplifies AI’s potential in operational spheres, promoting efficiency while necessitating prudent governance. As models evolve, their integration into daily practices promises transformative, albeit cautious, advancements in technology management.

Links:

• Lecture video: https://www.youtube.com/watch?v=nPoC6m3axeU
• Barry van Someren on LinkedIn: https://www.linkedin.com/in/barryvansomeren
• Barry van Someren on Twitter/X: https://twitter.com/bvansomeren
• CoffeeSprout ICT Services website: https://www.coffeesprout.nl/

Lecturer

Elizabeth Fuentes is a Senior Developer Advocate at Amazon Web Services (AWS), specializing in the intersection of Artificial Intelligence and DevOps practices. With extensive experience in cloud architecture and software engineering, Elizabeth focuses on how Generative AI can streamline complex CI/CD pipelines and enhance Site Reliability Engineering (SRE). She is a key contributor to AWS educational initiatives, having co-developed advanced courses on AI-driven automation. Joining her is Laas Alina, a software architect and open-source enthusiast who focuses on implementing multi-agent systems and the Model Context Protocol (MCP) to solve observability challenges at scale.

Abstract

As software systems grow increasingly distributed and complex, traditional observability—centered on manual log analysis and reactive dashboards—is becoming insufficient. This article explores the paradigm shift toward AI-driven observability, where Generative AI serves not just as a query tool, but as an active participant in failure detection, correlation, and resolution. By leveraging Amazon Bedrock and Amazon Q, organizations can transition from “reactive” to “predictive” DevOps. The discussion analyzes the methodology of building AI agents that simulate architectural stress, automatically explain multi-layered failures, and provide traceable, actionable recommendations. We examine the implementation of the Model Context Protocol (MCP) in establishing sophisticated multi-agent systems (MAS) that transform raw data into contextual understanding, ultimately reducing the Mean Time to Resolution (MTTR) and enhancing systemic resilience.

The Evolution of Observability: From Metrics to Contextual Understanding

The traditional pillars of observability—metrics, logs, and traces—provide the “what” of a system’s state but often fail to provide the “why” in real-time. In high-velocity DevOps environments, the sheer volume of telemetry data can overwhelm human operators, leading to “alert fatigue” and delayed responses to critical incidents. Elizabeth posits that the integration of Generative AI marks the fourth pillar of observability: Contextual Intelligence. This evolution moves the industry beyond simple threshold-based monitoring toward systems that understand the semantic relationship between a failed deployment, a spike in latency, and a specific line of code.

By utilizing Large Language Models (LLMs) through Amazon Bedrock, DevOps teams can ingest vast amounts of unstructured log data and receive summaries that highlight anomalies that might be missed by traditional regex-based filters. The methodology involves training the AI to recognize “normal” operational patterns and identifying deviations not just by value, but by the intent of the system’s behavior. This contextual layer allows for a more nuanced interpretation of system health, where the AI can distinguish between a benign resource spike and a precursor to a cascading failure.

Architecting AI Agents for Predictive Troubleshooting

The transition to AI-driven observability is characterized by the deployment of “Micro-agents”—specialized AI entities designed to handle specific segments of the DevOps lifecycle. These agents operate within a Multi-Agent System (MAS), where they collaborate to solve complex incidents. For instance, a “Monitoring Agent” might detect a performance degradation and immediately trigger a “Diagnosis Agent” to correlate the event with recent CI/CD pipeline changes.

Elizabeth and Laas Alina emphasize the importance of the Model Context Protocol (MCP) in this architecture. MCP acts as the communication backbone, allowing agents to share context without losing the “lineage” of a decision. When an AI agent recommends a specific architectural change or a rollback, it must provide clear traceability. This is crucial for maintaining trust in automated systems. The agents do not operate in a vacuum; they interact with tools like Amazon Q to provide developers with instant explanations of failures directly within their Integrated Development Environment (IDE) or chat interface.

// Example of an AI-driven Observability Agent Configuration
agent:
  name: "IncidentDiagnosticAgent"
  provider: "AmazonBedrock"
  model: "claude-3-sonnet"
  capabilities:
    - log_analysis
    - metric_correlation
    - trace_summarization
  mcp_config:
    protocol_version: "1.0"
    shared_context: "deployment_metadata"
  safety_guardrails:
    - max_token_usage: 4000
    - human_in_the_loop_required: true

Transforming CI/CD through Generative AI and Simulation

Beyond reactive troubleshooting, AI-driven observability empowers proactive system design. One of the most innovative concepts discussed is the use of AI agents to simulate “stress-test” scenarios within a digital twin of the production environment. These agents can intentionally inject failures—similar to Chaos Engineering—and then observe how the observability stack responds. This creates a feedback loop where the AI helps engineers identify “blind spots” in their monitoring before a real incident occurs.

Furthermore, Generative AI transforms the CI/CD pipeline by automatically generating “failure explanations.” Instead of a developer sifting through a 5,000-line build log, Amazon Q can provide a concise summary: “The build failed because the new database schema in commit X is incompatible with the connection pool settings in environment Y.” This level of automated insight accelerates the “inner loop” of development, allowing engineers to focus on innovation rather than infrastructure archeology.

The Human-AI Partnership: Strategic Implications

A common concern in the industry is the replacement of human engineers by AI. However, Elizabeth argues that the future belongs to the “augmented engineer.” AI is a force multiplier that automates the repetitive, “drudge work” of observability—log parsing and initial triage—allowing human experts to focus on high-level strategy and complex architectural decisions. The goal is to transform teams from being “reactive” (fighting fires) to “proactive” (preventing fires).

Implementing these systems requires a cultural shift toward AI-literacy within DevOps teams. Organizations must establish safety guardrails to ensure that AI-driven recommendations are validated and that automated actions (like auto-remediation) have clear rollback paths. By embracing AI as a strategic tool, DevOps and SRE teams can achieve a level of operational excellence that was previously unattainable, ensuring that as systems grow in scale, their reliability grows in parallel.

Links:

• Amazon Bedrock Service Page
• Amazon Q Developer Information
• AWS DevOps Solutions
• Model Context Protocol (MCP) Specification

Lecturer
Will Sentance is the founder of Standard Material and Codesmith, organizations at the forefront of physical AI infrastructure and AI/software engineering education. A speaker, educator, and practitioner, Sentance bridges software engineering expertise with emerging robotics and autonomous systems. He contributes to research at Oxford and leads initiatives training talent for the next wave of intelligent physical systems.

Abstract
In this forward-looking keynote at Devoxx Greece 2026, Will Sentance explores the profound convergence of software engineering and physical intelligence. Robots and autonomous systems are transitioning from specialized, brittle demonstrations to capable, generalizable agents operating in real-world environments. Sentance details the technological breakthroughs in hardware, data, and foundation models driving this transformation and argues that traditional software engineering skills are central to building the platforms, data pipelines, and integrations required for scalable physical AI deployment.

The Remarkable Progress in Physical Intelligence

Physical AI—systems that sense, understand, and act upon the physical world—has advanced dramatically. Robots now follow natural language instructions, handle novel objects, and demonstrate emergent capabilities. Foundation models for robotics enable zero-shot generalization and long-horizon planning across diverse embodiments.

Companies like Physical Intelligence, Agility Robotics, and others are moving from laboratory experiments to industrial and domestic applications. This shift is fueled by massive investment and rapid iteration.

Core Technological Enablers

Three key areas have transformed the landscape:

Hardware Revolution: Affordable, off-the-shelf components—from full humanoids to grippers and sensors—dramatically lower barriers. Edge computing platforms provide sufficient power for onboard inference.

Data Explosion: Teleoperation, simulation (including sophisticated world models), and real-world deployment generate multimodal datasets at unprecedented scale. Techniques like action chunking address real-time requirements.

AI Models: End-to-end learning replaces traditional control theory. Vision-language-action models predict continuous action trajectories, enabling flexible behavior without exhaustive manual programming.

The Physical AI Technology Stack

Sentance outlines a layered architecture:

• Real-time Control: Low-level, deterministic operations managing actuators and safety at high frequency.
• Platform and Middleware: Abstractions like ROS providing integration, simulation interfaces, and developer tools.
• Intelligence Layer: Foundation models processing vision, language, and proprioception to generate actions.
• Data and Learning Loop: Continuous collection, training, evaluation, and deployment cycle.

Opportunities for Software Engineers

Contrary to initial impressions, software engineers are perfectly positioned to lead this revolution. Approximately 80% of the required work involves familiar disciplines: systems architecture, platform engineering, data pipelines, low-level optimization, and agentic integration.

Roles at leading organizations emphasize scalable frameworks, reliable deployment, observability, and integration of AI models into production—skills honed in cloud-native and distributed systems development.

New challenges center on real-time constraints, physical dynamics, and managing massive multimodal datasets, but these build directly upon existing expertise.

Getting Started with Physical AI

Sentance encourages practical experimentation using affordable hardware like the SO-101 and open tools. Developers can quickly train policies for simple tasks such as closing a laptop lid, experiencing the full cycle from data collection to deployment.

The physical world represents the next major platform for code. Software engineers who embrace this frontier will shape the coming industrial transformation.

Links:

• Video: Code That Moves the World
• Will Sentance on X/Twitter