Topic

Continuous Integration/Deployment (CI/CD)

All digests tagged Continuous Integration/Deployment (CI/CD)

· 21:21

How Forward Deployed Engineering is done at Factory — Eno Reyes

Forward Deployed Engineering (FDE) is evolving from traditional professional services consulting into a strategic function where engineers act as 'the tip of the spear' for product development. The core goal is to build an autonomous 'Software Factory' within a customer's environment. This factory automates the entire signal-to-deploy pipeline—from capturing external signals (e.g., bug reports, Slack conversations) through planning, coding, and rigorous validation (SAST, linters, type checkers)—with minimal human intervention. Success hinges on achieving 'agent readiness,' which measures the density of deterministic validation loops in a codebase, enabling massive migrations (e.g., 30-50 million lines of code) autonomously.

Key takeaways

  1. The Shift from Consulting to Product Strategy

    Factory argues that FDE should not be professional services work on behalf of a customer, but rather the stream of information gathered from critical customers. This data is fed back into the product to rapidly improve it, making the deployed engineer an integral part of the product's evolution.

  2. The Software Factory Pipeline 8:23

    This factory concept describes a continuous process where external signals flow in, are prioritized into plans, converted into code changes (the source of truth), pass through automated validation stages (linters, type checkers, SAST tools), and finally deploy. The goal is an uninterrupted signal-to-deploy flow without human intervention.

  3. Data Ownership and Autonomy 10:57

    To ensure scalability and security, the deployed engineer must utilize a model independent agent harness (like Droid) that guarantees the customer owns all traces and data. This allows for highly secure deployments, including air-gapping in sensitive environments like finance or healthcare.

  4. Agent Readiness as a Metric 20:05

    Autonomy is measured by 'agent readiness,' which quantifies the number of deterministic validation loops (e.g., passing linters, type checkers) present in a codebase. A high volume of these loops allows advanced agents to operate on complex tasks for extended periods without human intervention.

Watch on YouTube Full article

· 31:44

Brian Douglas - The beginners guide to training AI on your own code - AI Native DevCon June 2026

This talk outlines a closed-loop system for training AI agents using proprietary code execution traces. The core concept involves capturing every agent interaction (telemetry) via an open-source proxy (tapes.dev), structuring this data into a content-addressable Merkle DAG. This raw trace data is then processed by streaming tools like Kafka and Flink SQL to detect anomalies, which feeds back into the agent's next run—creating a 'self-healing loop.' The captured traces are used for supervised fine-tuning (SFT) or Direct Preference Optimization (DPO) to embed learned skills directly into local models, eliminating reliance on external training data.

Key takeaways

  1. Closed-Loop Agent Training 3:50

    Agents generate data by running in an environment; this telemetry is captured and used immediately for model improvement. This creates a self-healing infrastructure loop, allowing agents to learn from failures (anomalies) and successes.

  2. Data Capture Infrastructure 10:30

    The open-source proxy, tapes.dev, intercepts LLM API calls to build a content-addressable Merkle DAG of every conversation turn, requiring zero instrumentation.

  3. Anomaly Detection and Feedback 2:00

    Streaming pipelines (Kafka/Flink SQL) run continuous anomaly detection on session data (e.g., stuck loops, token spikes). Alerts generated by Flink are read by the agent before its next execution, enabling self-correction.

  4. Knowledge Transfer Methods 22:00

    Captured traces can be used for Specialized Fine-Tuning (SFT) or Direct Preference Optimization (DPO). SFT embeds skills into the model, while DPO uses preference data derived from successful vs. failed sessions.

Watch on YouTube Full article

· 56:48

POC Prison: Why agentic systems never escape the lab and how to fix that in 90 days - Luise Freese

The talk argues that most agentic AI systems fail to move from Proof-of-Concept (POC) to production because they are blocked not by model limitations, but by fundamental organizational and governance realities. The speaker proposes a structured, 90-day program focused on building the 'paved road'—an operational backbone—to ensure agents can run safely in messy, legacy enterprise environments with clear accountability.

Key takeaways

  1. The POC Prison Problem 17:05

    POCs are often temporary, unmeasured, and reversible experiments that fail because they lack a defined path to production ownership. This creates an 'AI zombie' state where the system exists but delivers no measurable value or transformation.

  2. The Three Pillars of Enterprise Readiness 24:10

    Successful deployment requires addressing technical, organizational, and cultural gaps. The biggest hurdles are unclear ownership (who owns it when it breaks?), lack of dedicated funding for operations, and a culture that rewards demos over deployment frequency.

  3. The 90-Day Transition Program 29:10

    To escape the POC prison, implement a structured 90-day program: (1) Document current reality (ugly processes/data); (2) Achieve commitment and accountability by selecting one initiative; (3) Deploy into real systems under supervision to build the paved road.

  4. Governance Must Be Code 38:20

    Compliance and governance cannot live in slide decks or meetings. They must be embedded directly into the delivery process (e.g., 'governance as code'), making rules executable, auditable, and non-negotiable.

Watch on YouTube Full article