Forem: Raju Dandigam

What Most Beginners Get Wrong About Building AI Apps

Raju Dandigam — Tue, 14 Apr 2026 05:31:37 +0000

When you first start building AI-powered features, everything sounds deceptively simple. You call an API, pass some text, and get a response back. After a few experiments, it starts to feel like all AI systems are built the same way.

Then you hear terms like workflows, agents, and multi-agent systems, which only makes it more confusing. It is easy to assume these are just different names for the same thing.

That assumption is where most beginners go wrong.

Once you start building something real, something that needs to work consistently, scale, and handle edge cases, you quickly realize that these are fundamentally different ways of designing systems. The choice between them is not just about architecture. It directly affects reliability, cost, performance, and how easy your system is to debug when things break.

The biggest mistake beginners make is not understanding how decisions are made inside their system.

It’s not really about AI; it’s about decision-making

A much simpler way to think about AI systems is to ignore the model for a moment and focus on control.

In some systems, you control every step. In others, the AI decides what to do next. In more complex setups, multiple AI components collaborate and share responsibilities.

That difference in control is what shapes the entire system.

If you design everything as if the AI should always “figure it out,” you will often end up with something harder to manage than it needs to be. If you over-control everything, you may limit flexibility where it actually matters.

Understanding that balance early saves a lot of rework later.

A relatable way to think about it

Imagine you are ordering food.

In one scenario, the process is completely structured. You select items from a menu, enter your address, confirm payment, and receive your order. Every step is predefined and predictable.

In another scenario, you simply say, “I want something quick and healthy,” and the system figures out what you might like, asks follow-up questions, and adapts based on your answers.

Now imagine a third scenario where one system understands your intent, another finds suitable options, and another optimizes delivery timing. Each part focuses on a specific responsibility, and together they complete the task.

These three patterns represent very different ways of building AI applications, even though they might all use the same underlying model.

The simplest starting point: fixed decision paths

Most real-world AI systems start with something very simple. You define the steps, and the system follows them every time.

async function createSummary(text: string) {
  const cleaned = await cleanText(text);
  const summary = await generateSummary(cleaned);
  const keywords = await extractKeywords(summary);

  return { summary, keywords };
}

This approach is straightforward. Every execution follows the same sequence. If something fails, you know exactly where to look. If you need to optimize cost, you know how many model calls are happening. If you need to scale, the behavior is predictable.

This is why many production systems rely heavily on this pattern. It works well for document processing, onboarding flows, reporting pipelines, and content moderation. These are all scenarios in which the steps are known ahead of time and do not change much across requests.

Beginners often underestimate how powerful this approach is because it does not feel “intelligent.” In reality, this level of control is what makes systems reliable.

When the system needs to decide

There are cases where predefined steps start to break down. You may not know the next step until you see the input. The system may need to explore, ask questions, or adapt based on context.

That is where a different approach becomes useful.

async function runAgent(task: string) {
  return await agent({
    goal: task,
    tools: ["search", "summarize", "save"]
  });
}

Here, instead of defining the sequence, you define a goal and give the system a set of capabilities. The system decides whether it should search first, summarize later, or skip certain steps entirely.

This flexibility is valuable in areas like customer support, research, and planning. Every input can be different, and the system needs to adapt rather than follow a fixed path.

However, this comes with trade-offs. The number of steps may vary. The cost may vary. Debugging becomes less straightforward because the path is no longer fixed. You are trading control for flexibility.

This is often where beginners run into trouble. It is tempting to use this approach everywhere because it feels more powerful, but many problems simply do not need that level of adaptability.

When complexity grows further

As systems grow, you may find that a single decision-making unit becomes overloaded. Different parts of the task require different kinds of expertise. One part needs research, another needs writing, and another needs validation.

At that point, splitting responsibilities can help.

async function buildArticle(topic: string) {
  const research = await researchAgent(topic);
  const draft = await writerAgent(research);
  const final = await editorAgent(draft);

  return final;
}

Each component focuses on a specific responsibility. One gathers information, another transforms it, and another refines it. This separation can improve quality and make complex tasks more manageable.

At the same time, it introduces more moving parts. Coordination becomes important. Debugging becomes more complex. Costs can increase. This is why this pattern is usually introduced later rather than at the beginning.

Where most beginners go wrong

A common pattern I see is starting with the most flexible and complex approach first. It feels like the “correct” modern way to build AI systems.

In practice, it often leads to overengineering.

Simple tasks get wrapped in unnecessary complexity. Costs increase without clear benefits. Systems become harder to reason about. Small bugs become difficult to trace because the execution path is not fixed.

Another mistake is forcing a rigid structure onto problems that clearly require flexibility. If your system keeps adding exceptions, retries, and conditional branches to handle different cases, it may be a sign that the design needs to allow more dynamic behavior.

The real skill is not choosing one approach over another. It is knowing when each one makes sense.

A more practical way to build AI systems

Instead of picking one pattern and applying it everywhere, a better approach is to combine them.

Start with a simple, controlled structure and introduce flexibility only where it adds value.

async function handleSupport(message: string) {
  const type = await classify(message);

  if (type === "simple") {
    return searchFAQDatabase(message);
  }

  return runAgent(message);
}

In this example, straightforward questions are handled with a predictable path. More complex issues are handled with a flexible system that can adapt to the situation.

This approach keeps the system efficient and understandable while still allowing intelligence where it matters.

A useful mental model

If you can clearly define the steps, keep it simple and structured.

If the system needs to figure out the steps on its own, allow it more flexibility.

If the problem naturally breaks into multiple specialized responsibilities, consider separating them.

You do not need to start with the most advanced setup. In fact, starting simple often leads to better systems in the long run.

Conclusion

The goal is not to build the smartest system.

The goal is to build something that works reliably, is easy to understand, and can evolve as your requirements grow.

Most successful AI applications are not fully autonomous systems. They are carefully designed combinations of control and flexibility.

If you are just getting started, begin with something simple and predictable. Once you understand where your system needs more intelligence, add it deliberately.

That approach will take you much further than trying to build the most advanced system on day one.

Docker for TypeScript Developers Building AI Agents in 2026

Raju Dandigam — Fri, 10 Apr 2026 00:08:52 +0000

Modern frontend engineers are no longer just building UI layers. Increasingly, we are building systems that orchestrate AI behavior. A simple TypeScript service can now act as a coordinator between large language models, vector databases, background workers, and external tools.

That shift has quietly introduced a new class of problems. Not problems with writing code, but with running it.

You might have already experienced something like this. Your AI agent works perfectly on your machine. It calls an LLM, stores context in a vector database, maybe uses Redis for memory, and even talks to a Python service for embeddings. Then a teammate pulls the repo and tries to run it.

Suddenly, nothing works. Node versions don’t match. Python dependencies break. Redis isn’t running. Environment variables are missing. The system that felt simple is now fragile.

This is where Docker stops being “infrastructure tooling” and becomes something much

Why This Problem Is Different in 2026

Traditional web applications were mostly deterministic. If your code compiled and your dependencies matched, you could reasonably expect consistent behavior.

AI systems don’t behave that way. Even when your code is correct, outcomes vary based on context, prompts, and external services. That makes the execution environment even more critical. If the environment itself is inconsistent, debugging becomes nearly impossible.

On top of that, modern AI applications are rarely single-service systems. A typical setup might include:

A TypeScript API orchestrating agents
A vector database for retrieval
A cache or message queue for coordination
A Python service for embeddings or model execution
Optional local LLMs for development

This is no longer just a Node.js app. It is a distributed system, even during development.

Docker as the Execution Layer for AI Agents

The most useful way to think about Docker in this context is not as a deployment tool, but as a boundary.

Instead of letting your AI agent execute directly on your machine, you introduce a controlled environment where everything runs. The agent still makes decisions, but execution occurs within a container with defined tools, dependencies, and permissions.

This separation solves several problems at once. It makes environments reproducible, isolates dependencies, and gives you a safe place for agents to run code, tests, or workflows.

In practice, this means your TypeScript application becomes the orchestration layer, while Docker provides the execution layer.

Starting Simple: Containerizing a TypeScript Agent

Let’s begin with a minimal example. Imagine a small TypeScript service that acts as an AI agent using an LLM API.

import express from 'express';
import Anthropic from '@anthropic-ai/sdk';

const app = express();
app.use(express.json());

const client = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

app.post('/agent', async (req, res) => {
  const response = await client.messages.create({
    model: 'claude-3-5-sonnet-20241022',
    max_tokens: 500,
    messages: [{ role: 'user', content: req.body.prompt }],
  });

  res.json(response);
});

app.listen(3000, () => {
  console.log('Agent running on port 3000');
});

This works locally, but we want to make it portable and reproducible. A multi-stage Dockerfile gives us a clean way to do that.

FROM node:20-alpine AS builder

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY tsconfig.json ./
COPY src ./src

RUN npm run build

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY --from=builder /app/dist ./dist

USER node

EXPOSE 3000

CMD ["node", "dist/index.js"]

Now the application runs the same way everywhere. There is no dependency drift, no missing tools, and no ambiguity about runtime behavior.

Moving to Real Systems: Multi-Agent Architecture

The real value of Docker becomes obvious when you move beyond a single service.

Consider a common multi-agent setup:

A coordinator who receives requests
A research agent that fetches and analyzes information
A code agent that generates or modifies code
Redis for communication
PostgreSQL for persistence

Instead of managing all of this manually, Docker Compose lets you define the entire system in one place.

version: '3.8'

services:
  coordinator:
    build: ./services/coordinator
    ports:
      - "3000:3000"
    environment:
      - REDIS_URL=redis://redis:6379
      - DATABASE_URL=postgresql://user:pass@postgres:5432/agents
    depends_on:
      - redis
      - postgres

  research-agent:
    build: ./services/research-agent
    ports:
      - "3001:3001"
    environment:
      - REDIS_URL=redis://redis:6379
    depends_on:
      - redis

  code-agent:
    build: ./services/code-agent
    ports:
      - "3002:3002"
    environment:
      - REDIS_URL=redis://redis:6379
    depends_on:
      - redis

  redis:
    image: redis:7-alpine

  postgres:
    image: postgres:15-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=agents

Running docker-compose up brings the entire system to life. Each agent runs in isolation, but they communicate through well-defined channels. This is far more stable than trying to stitch together services manually.

When TypeScript Meets Python

Most AI systems today are not purely JavaScript. Even if your orchestration layer is TypeScript, you will likely depend on Python for embeddings, model execution, or specialized libraries.

Docker makes this integration straightforward by separating concerns into services.

services:
  agent:
    build: ./agent-service
    ports:
      - "3000:3000"
    environment:
      - ML_SERVICE_URL=http://ml-service:8000
    depends_on:
      - ml-service

  ml-service:
    build: ./ml-service
    ports:
      - "8000:8000"

Your TypeScript agent can now call the Python service without worrying about local Python installations or dependency conflicts.

async function getEmbeddings(text: string) {
  const response = await fetch('http://ml-service:8000/embed', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ text })
  });

  return response.json();
}

This separation becomes critical as systems grow. Each service can scale independently, and each stack can evolve without breaking others.

Development Experience Without Friction

One concern developers often have is that Docker slows down iteration. That can happen if you rebuild containers on every change, but it does not have to.

A better approach is to use volume mounts with a watch mode.

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY tsconfig.json ./
COPY src ./src

RUN npm install -g tsx

CMD ["tsx", "watch", "src/index.ts"]

Now you can edit code locally, and the container reloads automatically. You get the benefits of Docker without sacrificing developer experience.

What Actually Changes After Adopting This

The impact of this approach is not theoretical. It shows up immediately in how teams work.

Onboarding becomes faster because new developers do not need to recreate environments manually. Running the system becomes predictable because everything is defined in one place. Debugging improves because you eliminate environment-related variables.

More importantly, it changes how you think about AI systems. Instead of treating them as scripts or services, you start treating them as controlled execution environments. The agent decides what to do, but Docker defines how it is allowed to do it.

A More Useful Mental Model

It helps to think of modern AI systems as having three distinct layers.

The first is the decision layer, where the language model or agent determines what actions to take. The second is the orchestration layer, typically written in TypeScript, where workflows and integrations are defined. The third is the execution layer, where those actions actually run.

Docker fits naturally into that third layer. It provides a deterministic, isolated environment in which execution occurs safely and consistently.

Once you start thinking in these terms, Docker no longer feels like an optional tool. It becomes a fundamental part of building reliable AI systems.

Conclusion

The biggest mistake teams make with AI development today is underestimating the importance of the execution environment. It is easy to focus on prompts, models, and frameworks, but those are only part of the system.

What matters just as much is where and how those decisions are executed.

For TypeScript developers, Docker provides a practical way to bring structure and reliability to increasingly complex AI workflows. It bridges the gap between frontend development and distributed systems, without requiring a complete shift in tooling or mindset.

If you are building AI agents in 2026, you are already working with multi-service systems, mixed runtimes, and non-deterministic behavior. Docker is what makes all of that manageable.

Start small. Containerize a single agent. Then add services as your system grows. Over time, you will find that it is not just about making things run, but about making them run in a way you can trust.

Cypress AI Skills: Teaching Your AI Assistant to Write Better Tests

Raju Dandigam — Thu, 09 Apr 2026 23:49:32 +0000

I’ve been using AI tools like Cursor and Claude Code to help write Cypress tests. It’s fast, and for simple cases, it works well enough.

But as soon as you try to use it in a real project, the cracks start to show.

You ask the AI to write a test, and you get something like this:

cy.get('.btn-primary').click()
cy.wait(3000)
cy.get('.modal-content .success').should('be.visible')

It works, technically. But it doesn’t look like something your team would ever commit.

In most real-world projects, we avoid CSS selectors, we don’t rely on arbitrary waits, and we lean heavily on custom commands to keep tests maintainable. So instead of saving time, you end up rewriting most of what the AI generated.

That’s the gap Cypress AI Skills is trying to close.

The Real Shift: From Code Generation to Code Alignment

Most AI tools are good at generating code, but they don’t understand your codebase.

They don’t know your selector strategy.
They don’t know your custom commands.
They don’t know your conventions or patterns.

So they produce generic output.

Cypress AI Skills introduces a simple but powerful idea: instead of asking AI to generate code, you teach it how your team writes tests.

These skills live inside your project. They are not a service or a black box. Your AI assistant reads them, along with your existing code, and uses that context when generating or reviewing tests.

Getting Started

The setup is intentionally simple:

npx skills add cypress-io/ai-toolkit

Once installed, your AI assistant can use two key capabilities: cypress-author and cypress-explain.

Writing Tests with `cypress-author`

The difference becomes obvious when you actually use the skill.

Instead of a generic prompt, you explicitly guide the AI:

/cypress-author Create a login test using existing custom commands and data-cy selectors

Before generating anything, the AI looks into your project. It scans your Cypress configuration, your support files, and your custom commands.

So instead of producing something like:

cy.get('.email-input').type('test@example.com')
cy.get('.password-input').type('password')
cy.get('.login-btn').click()

It generates something aligned with your actual setup:

describe('Authentication Flow', () => {
  it('logs in successfully and redirects to dashboard', () => {
    const user = { email: 'test@example.com', password: 'Password123' }

    cy.login(user.email, user.password)

    cy.url().should('include', '/dashboard')
    cy.getByCy('welcome-message').should('be.visible')
  })
})

The important part is not just cleaner code. The AI is now:

Reusing your abstractions instead of duplicating logic
Following your selector conventions
Structuring tests the way your team already does

This is where AI starts becoming useful in a real codebase.

Reviewing and Improving Tests with `cypress-explain`

If cypress-author helps you write tests, cypress-explain helps you improve them.

You can take an existing test and ask:

/cypress-explain Review this test for flakiness and bad practices

Given something like this:

cy.get('.checkout-btn').click()
cy.wait(2000)
cy.get('.confirmation').should('be.visible')

The AI doesn’t just describe the test. It evaluates how it’s written.

It will point out things like:

Reliance on arbitrary waits
Brittle selectors
Missing synchronization with network calls

And it typically suggests a more stable version:

cy.intercept('POST', '/api/checkout').as('checkout')
cy.getByCy('checkout-btn').click()
cy.wait('@checkout')
cy.getByCy('order-confirmation').should('be.visible')

In practice, this feels less like code generation and more like having a second reviewer who understands Cypress-specific pitfalls.

What Actually Changes in a Real Project

One of the most useful ways to think about this is through transformation.

Without context, AI writes tests that are technically valid but fragile:

cy.get('.login-btn').click()
cy.wait(2000)
cy.get('.dashboard').should('exist')

With Cypress AI Skills, the same intent becomes:

cy.intercept('POST', '/api/login').as('loginRequest')
cy.getByCy('login-btn').click()
cy.wait('@loginRequest')
cy.getByCy('dashboard').should('be.visible')

The shift is subtle but meaningful. The test becomes more stable, easier to read, and consistent with the rest of your suite.

This is not about writing faster tests. It’s about writing tests that don’t need to be rewritten later.

Where This Helps the Most

In real projects, the value shows up in a few consistent places.

When refactoring older tests, the AI can take brittle patterns and align them with your current standards. Instead of manually fixing selectors and waits across files, you can guide the transformation with a prompt.

When generating tests from requirements, the AI produces code that already fits your project structure, including your helpers and naming conventions.

When debugging flaky tests, cypress-explain helps quickly identify the root cause, especially around timing issues and missing intercepts.

It also becomes surprisingly useful for onboarding. New engineers can ask the AI to explain how tests are structured or how certain flows are implemented, and the answers are grounded in your actual codebase.

A Note on `cy.prompt()`

There is also an emerging pattern around intent-based testing using cy.prompt().

Instead of targeting elements directly, you describe the action:

cy.prompt('Navigate to the final payment screen')

The idea is to express intent rather than implementation.

This can be useful in cases where the UI changes frequently or when working with third-party components where selectors are unstable.

That said, this approach is still evolving. It introduces variability and can be slower than traditional tests, so it’s better suited for exploratory or non-critical flows rather than core test paths.

Making This Work for Your Team

For Cypress AI Skills to be effective, a few foundational things matter.

Your project should have clear conventions. If your selectors and patterns are inconsistent, the AI won’t have a strong signal to follow.

It also helps to make those conventions visible. Even a simple document describing your testing approach can improve the quality of AI output.

One important practice is to treat these skills as part of your codebase. Commit them, version them, and let your entire team benefit from the same behavior. This ensures that AI-assisted code remains consistent regardless of who generates it.

And like any generated code, it still needs review. The goal is not to remove that step, but to make it faster and more focused.

What This Is (and What It’s Not)

Cypress AI Skills are not a solution for fully automated testing. They don’t magically fix flaky tests, and they don’t replace the need for thoughtful test design.

What they do is much more practical.

They reduce the gap between what AI generates and what your team expects.

Instead of treating AI as a generic code generator, you start treating it as a project-aware assistant.

Conclusion

AI is already changing how we write code, but testing has been slower to benefit because generic output rarely aligns with real-world practices.

Cypress AI Skills takes a meaningful step forward by making AI aware of your project, your conventions, and your workflows.

It’s not a dramatic shift, but it’s a practical one. And in day-to-day engineering, those are the improvements that actually stick.

If you’re already using AI tools with Cypress, this small change can make a noticeable difference.

Reference:
Cypress AI Skill

Docker as the Sandbox for AI Agents: Safe Cypress Workflows for Frontend Teams

Raju Dandigam — Fri, 27 Mar 2026 22:37:23 +0000

Introduction

A Small Mistake That Breaks Everything. An agent tries to fix a failing test. It sees a permission error and decides to help. It runs:

chmod -R 777 .

Unfortunately, your project folder is symlinked to a broader directory. Within seconds, your local environment is exposed, permissions are broken, and debugging becomes a nightmare.

This is not a far-fetched scenario. It is the natural outcome of giving an autonomous system unrestricted access to your machine.

AI-assisted development has evolved quickly. Agents can now:

Run tests
Modify files
Execute scripts
Propose pull requests

With tools and protocols like MCP (Model Context Protocol), they are no longer passive assistants. They are active participants in your development workflow.

And that raises a fundamental question: Should AI agents have direct access to your development environment at all?

The Problem with Host-Based Agent Execution

In most current setups, the execution model looks like this:

This approach is convenient, but it creates systemic issues.

First, there is security exposure. The agent can access environment variables, local files, SSH keys, and system-level resources. Even if the agent behaves correctly, the risk surface is too large.

Second, there is environment inconsistency. The agent’s behavior depends on the local machine—Node versions, OS differences, and installed dependencies. The result is a new variation of the classic problem: “it works on my machine,” but now applied to AI workflows.

Third, reproducibility breaks down. When an agent executes tasks in an uncontrolled environment, it becomes difficult to recreate the same conditions elsewhere, particularly in CI.

Finally, debugging becomes complicated because there is no clear boundary between the agent’s actions and the local system state.

Rethinking the Model: Agents Need Environments, Not Access

We need to stop treating AI agents like supercharged IDE plugins and start treating them like untrusted third-party binaries.

That shift leads to a different execution model:

In this model:

The agent does not execute directly on your machine; it interacts with a containerized environment, and all operations happen within a controlled boundary.

The key difference is subtle but critical: "We are no longer giving the agent access. We are giving it an environment."

Where MCP Fits: The Container as the “Jailer”

Earlier, we mentioned MCP (Model Context Protocol). This is where it becomes essential.

In most setups, MCP tools allow agents to:

Read files
Run commands
Inspect repositories

If MCP is connected directly to your host machine, it becomes a gateway to your entire system. Instead, the MCP server should run inside the container.

This changes the architecture:

The agent communicates with the MCP and operates within the container boundary. All file access and command execution are scoped to that environment

Effectively, MCP becomes the interface, and the container becomes the jailer that enforces constraints.

A Practical Example: Fixing a Cypress Test

Let’s walk through a real-world scenario.

A Cypress test fails in CI:

Error: Expected to find element: [data-testid="submit-btn"] But never found it.

An AI agent analyzes:

The failing test
Logs
Possibly a DOM snapshot

It identifies a selector change:

- cy.get('[data-testid="submit-btn"]')
+ cy.get('[data-testid="submit-button"]')

Deterministic Execution and Binary Parity

Here’s where things often go wrong in typical setups. The failure occurred in CI, which likely runs:

Linux
A specific Node version
A specific Cypress binary

But the agent might attempt to validate the fix on:

MacOS
ARM architecture
A different Node version

This mismatch leads to incorrect conclusions or “hallucinated fixes.” To avoid this, the agent executes inside a container that matches the CI environment:

docker run --rm \ -v $(pwd):/app \ -w /app \ cypress/included:13.6.0 \ npx cypress run

This ensures binary parity:

Same OS
Same dependencies
Same runtime

The agent is now debugging the exact environment where the failure occurred.

This workflow ensures:

Validation happens in a controlled environment
The results are reproducible
Fixes are grounded in real execution, not assumptions

The Hybrid Strategy with Docker Compose

To make this practical, you can structure your setup like this:

Service A (Host-facing)
- Vite dev server
- Ports exposed
- Optimized for speed
Service B (Agent Sandbox)
- No exposed ports
- Volume-mounted code
- Runs tests and agent workflows

Example concept:

services:
  app:
    build: .
    command: npm run dev
    ports:
      - "5173:5173"

  agent-sandbox:
    image: cypress/included:13.6.0
    volumes:
      - .:/app
    working_dir: /app
    command: npx cypress run

Trade-offs and Considerations

This architecture introduces additional complexity. Containers need to be configured and maintained. There is some overhead in startup time and resource usage.

However, these costs are offset by:

Improved security boundaries
Deterministic execution
Reproducible debugging
Safer integration of AI agents into workflows

For teams operating at scale, these benefits become essential rather than optional.

Where This Is Heading

As AI agents become more capable, they will move from assisting developers to executing entire workflows. At that point, the key question is no longer:
“What can the agent do?”
It becomes:
“Where is the agent allowed to do it?”
In this context, Docker evolves from a deployment tool into an execution layer for intelligence.

Conclusion

AI agents introduce a powerful new capability into frontend development, but they also require a shift in how we think about execution and trust.

Allowing agents to operate directly on the host machine is convenient, but it is not a sustainable model for teams that prioritize security, consistency, and reproducibility.

By introducing containerized execution, we move from access-based thinking to environment-based thinking. This creates a safer and more predictable foundation for integrating AI into development workflows.

The future of frontend development will not be defined solely by faster tools, but by how effectively we control and constrain the systems that use them.

AI-Assisted Cypress CI: Detecting Selector Drift and Proposing Fixes Automatically

Raju Dandigam — Sun, 15 Mar 2026 05:55:20 +0000

CI failures are frustrating — especially when the fix is obvious.

A very common scenario:

Cypress tests pass locally
CI fails overnight
The screenshot clearly shows that the UI has changed
The test selector is outdated
Someone has to open logs and manually update the test

Example failure:

CypressError: Timed out retrying: Expected to find element: [data-testid="submit-profile-btn"], but never found it.

When you open the screenshot, the button is clearly visible, but now the selector is:

data-testid="save-profile-btn"

This type of issue is selector drift. It happens when the UI changes slightly, but tests still reference the old selector. The fix usually takes seconds, but the debugging process is repetitive. In this article, we will build a small AI-assisted CI workflow that:

Runs Cypress tests in GitHub Actions
Captures failure artifacts
Sends failure context to an LLM
The LLM detects possible selector drift
A PR. comment suggests the patch

This is not autonomous self-healing CI. Instead, it’s a supervised AI workflow that helps developers fix simple test failures faster.

The workflow looks like this:

Cypress test fails
        ↓
GitHub Actions captures failure artifacts
        ↓
DOM snapshot + error message sent to LLM
        ↓
LLM analyzes failure
        ↓
PR comment suggests selector fix

Developers remain in control and review the suggestion.

Demo App:
For this example we use a tiny React component.
src/ProfilePage.jsx

export default function ProfilePage() {
  const handleSave = () => {
    alert("Profile updated")
  }

  return (
    <div>
      <h1>Profile</h1>

      <input data-testid="name-input" placeholder="Name" />

      {/* UI change happened here */}
      <button data-testid="save-profile-btn" onClick={handleSave}>
        Save
      </button>
    </div>
  )
}

Originally, the button used: submit-profile-btn
After a UI update, it became: save-profile-btn

Step 1 — Write the Cypress Test

cypress/e2e/profile.cy.js

describe("Profile page", () => {
  it("updates profile", () => {
    cy.visit("/profile")

    cy.get('[data-testid="name-input"]').type("Test User")

    cy.get('[data-testid="submit-profile-btn"]').click()

    cy.contains("Profile updated")
  })
})

Once the selector changes, the test fails in CI.

Step 2 — Capture Failure Context

We capture useful context when tests fail.

cypress/support/e2e.js

afterEach(function () {
  if (this.currentTest.state !== "failed") return

  cy.document().then((doc) => {
    const html = doc.documentElement.outerHTML

    cy.task("saveFailureContext", {
      testTitle: this.currentTest.title,
      errorMessage: this.currentTest.err.message,
      url: doc.location.href,
      html,
    })
  })
})

cypress.config.js

const fs = require("fs")

module.exports = {
  e2e: {
    setupNodeEvents(on) {
      on("task", {
        saveFailureContext(data) {
          if (!fs.existsSync("artifacts")) {
            fs.mkdirSync("artifacts")
          }

          fs.writeFileSync(
            "artifacts/failure.json",
            JSON.stringify(data, null, 2)
          )

          return null
        },
      })
    },
  },
}

Now when a test fails, we capture:

test title
Cypress error message
page URL
DOM snapshot

Step 3 — Run Cypress in GitHub Actions

.github/workflows/cypress.yml

name: Cypress CI

on: [pull_request]

jobs:
  cypress-run:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm install

      - name: Run Cypress
        uses: cypress-io/github-action@v6
        with:
          start: npm start
          wait-on: 'http://localhost:3000'

      - name: Upload failure artifacts
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: failure-context
          path: artifacts

      - name: Analyze failure
        if: failure()
        run: node scripts/analyze-failure.js
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

      - name: Comment on PR
        if: failure() && github.event_name == 'pull_request'
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs')

            if (!fs.existsSync('artifacts/comment.md')) return

            const body = fs.readFileSync('artifacts/comment.md','utf8')

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            })

Step 4 — Sanitize the DOM Snapshot

Large React apps can produce massive DOM trees. We would need to clean the HTML before sending it to the LLM.

scripts/analyze-failure.js

function sanitizeDOM(html) {
  return html
    .replace(/<svg[\s\S]*?<\/svg>/g, "")
    .replace(/<style[\s\S]*?<\/style>/g, "")
    .replace(/<script[\s\S]*?<\/script>/g, "")
}

This removes large SVG blocks, style tags, and scripts while keeping the useful structure.

Step 5 — Scrub Sensitive Data

Before sending HTML to an LLM, we should remove PII.

function scrubPII(html) {
  return html.replace(
    /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi,
    "[EMAIL]"
  )
}

Then combine both steps:

const cleanedDOM = scrubPII(
  sanitizeDOM(failure.html)
).slice(0, 20000)

Step 6 — Call the LLM

Now we analyze the failure using an LLM.

scripts/analyze-failure.js

import fs from "fs"
import OpenAI from "openai"

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
})

if (!fs.existsSync("artifacts/failure.json")) {
  console.log("No failure data")
  process.exit(0)
}

const failure = JSON.parse(
  fs.readFileSync("artifacts/failure.json")
)

function sanitizeDOM(html) {
  return html
    .replace(/<svg[\s\S]*?<\/svg>/g, "")
    .replace(/<style[\s\S]*?<\/style>/g, "")
    .replace(/<script[\s\S]*?<\/script>/g, "")
}

function scrubPII(html) {
  return html.replace(
    /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi,
    "[EMAIL]"
  )
}

const cleanedDOM = scrubPII(
  sanitizeDOM(failure.html)
).slice(0, 20000)

const prompt = `
You are a senior Cypress reliability engineer.

Classify this test failure.

Possible classifications:

selector-drift
async-loading
logic-error
unknown

Only suggest a selector fix if classification = selector-drift.

Failure message:
${failure.errorMessage}

DOM snapshot:
${cleanedDOM}

Return JSON:

{
"classification":"",
"suggested_selector":"",
"confidence":"",
"reason":""
}
`

const response = await client.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [
    { role: "system", content: "You analyze Cypress failures." },
    { role: "user", content: prompt }
  ]
})

const result = response.choices[0].message.content

fs.writeFileSync("artifacts/analysis.json", result)

const parsed = JSON.parse(result)

if (parsed.classification !== "selector-drift") {
  console.log("No selector drift detected")
  process.exit(0)
}

const comment = `
### AI Test Suggestion

Possible selector drift detected.

Suggested selector:
\`${parsed.suggested_selector}\`

Suggested patch:

\`\`\`diff
- cy.get('[data-testid="submit-profile-btn"]')
+ cy.get('[data-testid="${parsed.suggested_selector}"]')
\`\`\`

Confidence: ${parsed.confidence}

Reason: ${parsed.reason}

Please review before applying.
`

fs.writeFileSync("artifacts/comment.md", comment)

When CI fails, the PR receives something like:

AI Test Suggestion

Possible selector drift detected.

Suggested selector:
save-profile-btn

Suggested patch:

- cy.get('[data-testid="submit-profile-btn"]')
+ cy.get('[data-testid="save-profile-btn"]')

Confidence: 0.91

Then we can quickly review and update the test.

When This Approach Works Best

This AI-assisted workflow works best in projects that follow a few good testing practices. In particular, it performs well when tests use stable selectors such as data-testid or data-cy, UI changes are relatively small, and the application behaves predictably across environments. In these cases, the AI can often detect simple selector drift caused by renamed attributes, minor DOM structure changes, or small UI updates.

At the same time, it’s important to remember that not every Cypress failure is caused by selector drift. Test failures can also occur due to network timing issues, missing test data, authentication problems, loading states, or feature flags. Because of this, the workflow is designed to suggest fixes rather than apply them automatically, ensuring that developers can review the recommendation before updating the test.

Conclusion

Many CI failures require only a small selector update, but developers still spend time investigating logs and screenshots to find the issue. By adding a lightweight AI analyzer to the CI pipeline, teams can automatically detect possible selector drift and surface suggested fixes directly in pull requests.

This approach does not replace developers or fully automate test maintenance. Instead, it reduces repetitive debugging work and shortens the feedback loop when UI changes break tests. With just a few scripts and a GitHub Action, teams can make their Cypress CI pipeline smarter and spend more time focusing on real product improvements.

8 Cypress Plugins Shaping Modern Testing in 2025

Raju Dandigam — Wed, 23 Jul 2025 02:41:47 +0000

Cypress continues to dominate the web testing ecosystem in 2025. Its plugin ecosystem has matured and now plays a vital role in enabling high-quality, scalable, and developer-friendly testing pipelines.

Here are 8 Cypress plugins that have stood out this year—based on adoption, developer feedback, and impact on modern testing workflows.

1. `eslint-plugin-cypress`: Enforcing Cypress Best Practices

Why It Matters

This plugin enforces Cypress-specific linting rules to catch anti-patterns like misuse of async/await, unnecessary waits, and missing assertions.

Installation

npm install --save-dev eslint-plugin-cypress

Setup

// eslint.config.js
import pluginCypress from 'eslint-plugin-cypress';
export default [pluginCypress.configs.recommended];

Prevents flaky tests
Works with ESLint v9+
Cypress core team recommendation

2. `cypress-real-events`: Simulate True User Behavior

Why It Matters

Simulates native browser events like hover, tab, and realClick that synthetic events miss.

Installation

npm install --save-dev cypress-real-events

Usage

import 'cypress-real-events';
cy.get('button').realClick();

Mimics real user actions
Great for UIs involving hover, tab, modals
Chromium-based support

3. `@cypress/code-coverage`: Know What You're Testing

Why It Matters

Helps you visualize what code paths are actually covered by your tests.

Installation

npm install --save-dev @cypress/code-coverage

Setup

import codeCoverageTask from '@cypress/code-coverage/task';

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      codeCoverageTask(on, config);
      return config;
    }
  }
});

Works with component & E2E tests
Istanbul support
LCOV and HTML reports

4. `@testing-library/cypress`: User-Focused Testing

Why It Matters

Provides queries like getByRole, findByText aligned with user interaction patterns.

Installation

npm install --save-dev @testing-library/cypress

Setup

import '@testing-library/cypress/add-commands';

Example

cy.findByRole('button', { name: /submit/i }).click();

Encourages accessible and maintainable tests
Framework-agnostic
Enhances readability

5. `cypress-axe`: Automated Accessibility Checks

Why It Matters

Brings automated WCAG audits into your CI pipeline.

Installation

npm install --save-dev cypress-axe axe-core

Usage

cy.injectAxe();
cy.checkA11y();

Catches a11y issues early
Supports custom axe rules
Works with CI/CD

6. `cypress-vite`: Use Your Vite Config

Why It Matters

Improves alignment and performance for Vite-powered apps.

Installation

npm install -D cypress-vite

Setup

import { defineConfig } from 'cypress';
import { vitePreprocessor } from 'cypress-vite';

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('file:preprocessor', vitePreprocessor());
    },
  },
});

Faster builds
Aligns app and test config
Native Vite support

7. `cypress-mochawesome-reporter`: Better Test Reports

Why It Matters

Creates rich HTML reports with screenshots and logs.

Installation

npm install -D cypress-mochawesome-reporter

Setup

reporter: 'cypress-mochawesome-reporter'
import 'cypress-mochawesome-reporter/register';

Helpful for non-dev stakeholders
Works with CI pipelines
Generates HTML + JSON output

8. `@cypress/grep`: Advanced Filtering With Tags

Why It Matters

Lets you run or skip tests by tags, beyond what --spec allows.

Installation

npm install -D @cypress/grep

Usage

npx cypress run --env grepTags=@smoke

it('works correctly @smoke', () => {...});

Enables modular test runs
Useful for CI workflows
Tag-based control

Final Thoughts

Cypress plugins continue to raise the bar for end-to-end and component testing. These 8 tools can help you:

Improve test coverage
Speed up local + CI runs
Catch accessibility gaps
Write maintainable tests your team loves

Which plugin do you rely on most? Let me know in the comments 👇

Running ML Models Locally with Docker Model Runner

Raju Dandigam — Wed, 02 Jul 2025 02:29:40 +0000

Docker Model Runner is designed to make running AI and ML models locally as easy as running any Docker service. It lets you package trained models as containers with consistent REST APIs—no custom server code required. In this guide, we’ll cover everything you need to know to use Docker Model Runner in real-world development workflows, including how to run models locally, configure Docker Desktop, connect from Node.js apps, use Docker Compose for orchestration, and follow best practices.

What Is Docker Model Runner?

Docker Model Runner lets you package your trained model with metadata that tells Docker how to serve it. When you run the resulting image, you get a standardized REST API automatically, with endpoints like /predict and /health. This eliminates the need to write and maintain your own serving code.

Why Use It?

Traditionally, serving ML models required custom web servers, complex dependency management, and inconsistent APIs across teams. Docker Model Runner solves this by:

Providing consistent APIs across all models.
Simplifying local development.
Making models portable across machines and environments.
Reducing maintenance by removing custom server code.

Supported Frameworks

Docker Model Runner supports a wide range of frameworks:

PyTorch
TensorFlow
Hugging Face Transformers
scikit-learn
XGBoost
LightGBM
spaCy
ONNX

This means you can use the same approach for a huge variety of ML workloads.

How It Works in Practice

Step 1: Train your model.
Step 2: Write a model-runner.yaml describing the framework and location of your model.
Step 3: Build your Docker image with this metadata and your model files.
Step 4: Run the container and get a consistent REST API without writing server code.

Running Models Locally with Docker Model Runner

Below is a real example using the ai/smollm2:latest model running locally. This demonstrates how easy it is to list available models and start a local interactive chat session.

Pull the model:
docker model pull ai/smollm2:latest

View the models available:
docker model list

Run the model:
docker model run ai/smollm2:latest

You’ll get an interactive chat session where you can type questions directly to the model.

Give the prompt:
What is Docker?

Docker Desktop Settings for Local Model Running

Need to update the settings in Docker Desktop. Allow TCP host connections for Model Runner via Docker Desktop settings or using CLI options for advanced networking control.

Docker Desktop makes it even easier to manage these models:

Navigate to the Models tab in Docker Desktop.
Browse and manage available local models.
Launch interactive chat interfaces directly from the UI.
Monitor container resource usage and logs.

You can adjust resource allocation in Settings → Resources, making sure your local environment has enough CPU and memory to handle larger models.

Using Docker Models in a Node.js App

You can use Docker Model Runner locally with any language. Here’s how you’d connect to your local model from a simple Node.js app.

Example Express.js Route:

app.post('/generate', async (req, res) => {
  const prompt = req.body.prompt;
  const response = await fetch('http://localhost:5000/predict', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ prompt })
  });
  const data = await response.json();
  res.send(data);
});

Why this is powerful:

Your app code never changes if you swap models.
You can test locally and later deploy the same model container in production.
Changing models is as simple as changing the running container.

Using Docker Compose for Multi-Model Pipelines

You can chain multiple Model Runner services using Docker Compose to build advanced workflows.

Example Use Case: Content Moderation Pipeline

Toxicity Detection MCP → Check user input.
Language Detection MCP → Identify language.
Translation MCP → Normalize to English.
Summarization MCP → Condense for storage.

docker-compose.yml Example:

version: "3.8"
services:
  toxicity-detector:
    image: myorg/toxicity-mcp
    ports:
      - "5001:80"
  language-detector:
    image: myorg/langdetect-mcp
    ports:
      - "5002:80"
  translator:
    image: myorg/translator-mcp
    ports:
      - "5003:80"
  summarizer:
    image: myorg/summarizer-mcp
    ports:
      - "5004:80"

Run:
docker-compose up

Now your app can call each service in sequence for a complete moderation and summarization pipeline.

CI/CD Integration

Define your model-runner.yaml in the repo.
Build Docker images in CI pipelines.
Tag images with version numbers or commit SHAs.
Run Docker Scout or other scanners for CVEs.
Push images to internal or external registries.
Deploy using Compose, Swarm, or Kubernetes.
Include automated health checks against /health.

This ensures your model deployment is as maintainable and secure as any other Microservice.

Best Practices

Always define clear input/output contracts.
Use private registries for internal or proprietary models.
Tag images with semantic versions.
Scan images regularly for vulnerabilities.
Keep model-runner.yaml under version control.
Automate builds and deployments via CI/CD.
Use resource limits in Docker Desktop settings to avoid overloading local environments.
Document how to call /predict and interpret results for consuming teams.

Conclusion

Docker Model Runner isn't just a convenience tool—it's a shift in how teams can think about model serving. Instead of building and maintaining custom servers for every model, you get standardization, portability, and repeatability. Whether you’re running a small LLM locally for testing, deploying to production Kubernetes clusters, or sharing images across teams, Docker Model Runner makes model serving a first-class, manageable part of your software architecture.

Docker MCP Servers: Standardizing AI/ML Workflows for the Agentic Future

Raju Dandigam — Wed, 02 Jul 2025 00:35:56 +0000

AI and ML are transforming applications across industries, but deploying models at scale is challenging. Docker MCP (Model Context Protocol) solves this by defining a standard way to package, deploy, and manage AI/ML models as secure, discoverable, and portable Docker containers. This ensures consistent APIs, standardized metadata, and seamless integration into microservice architectures.

What is Docker MCP?

Docker MCP is a framework for packaging AI/ML models as Docker images with standardized HTTP APIs and clear metadata. Each MCP server can run anywhere Docker runs—from developer laptops to cloud clusters and edge devices. It offers predictable, versioned endpoints for easy consumption by other services or applications. Metadata includes supported operations, input/output formats, and even sample payloads, enabling seamless discovery and reuse through the Docker Hub MCP Catalog.

This standardization also enables enterprises to manage dependencies cleanly, enforce security policies, and ensure repeatable, consistent deployment workflows across environments.

Example usage:
docker run myorg/sentiment-mcp

Call the service:
curl -X POST localhost:5000/analyze -d '{"text":"I like this!"}'

Response:
{"sentiment":"positive"}

Why MCP Matters

Without MCP, organizations often struggle with inconsistent APIs across teams, fragile integrations, and duplicated effort. Each ML team might build custom wrappers with different formats and dependency requirements. This leads to fragile glue code and slower time to production.

With MCP:

Standard APIs make integration predictable and reduce onboarding time for new services.
Portable images can be deployed on any infrastructure that supports Docker.
Discoverable catalog enables easy reuse of existing services and models.
Security features like image signing and vulnerability scanning with Docker Scout help enforce enterprise policies.
Versioning and tagging ensure traceability and rollback capabilities in CI/CD pipelines.

MCP solves these challenges by making AI services composable, consistent, and secure by default.

Docker MCP Catalog and Toolkit

Catalog:

A rapidly growing library of verified MCP images, including official and community-contributed models.
Metadata that describes the expected endpoints, supported operations, and sample inputs/outputs.
Production-ready examples include Anthropic Claude MCP for advanced text generation, Mistral 7B MCP for local inference, Sentence Transformers MCP for semantic search, and Stable Diffusion MCP for image generation.
Enables teams to easily find and evaluate models for their workflows, reducing duplication and fostering internal standards.

Toolkit:

Docker Desktop extension and CLI that streamlines deployment of MCP servers.
One-click deployment with secure credential handling and OAuth integration.
Resource isolation for CPU, memory, and storage to ensure predictable performance.
Provides gateways for popular development environments such as VS Code or local notebooks.
Simplifies onboarding for data science and engineering teams, encouraging self-service deployment of AI services.

Example Workflow: Support Ticket Agent

Goal: Automate triage of customer support messages by transforming unstructured text into structured, actionable tickets.

Pipeline:

Sentiment MCP – Analyze the emotional tone to determine urgency.
Keywords MCP – Extract product names, locations, or relevant entities.
Summarizer MCP – Condense the customer's message into a clear description.
JIRA Creator MCP – Automatically create a structured ticket in your issue tracker.

Compose Example:

version: "3.8"
services:
  sentiment:
    image: myorg/sentiment-mcp
  keywords:
    image: myorg/keywords-mcp
  summarizer:
    image: myorg/summarizer-mcp
  jira:
    image: myorg/jira-creator-mcp

Teams can prototype this locally using docker-compose up and seamlessly scale the same configuration to production using Swarm or Kubernetes, maintaining consistent behavior across environments.

Building Agentic AI Systems with MCP

Modern AI agents require the ability to plan, retrieve, reason, and act through dynamic workflows. MCP supports these patterns by defining composable, discoverable services with consistent APIs.

Example Agentic Workflow:

NLP MCP → Extract intent from user queries.
Geocoding MCP → Translate locations to coordinates.
OpenWeather MCP → Get forecasts for planning.
Airbnb MCP → Search for lodging options.
LLM MCP → Generate a natural language itinerary.

Such modularity makes it easier for companies to maintain, update, and scale individual components without breaking the entire system.

Advantages and Best Practices

Advantages:

Consistent APIs reduce integration overhead and enable faster onboarding for new teams.
Shareable images facilitate collaboration and standardization across departments.
Image signing and vulnerability scanning with Docker Scout help maintain security compliance.
Portable images work on-premises, in the cloud, or in hybrid environments.
Supports policy enforcement and auditability for highly regulated industries.

Best Practices:

Use Docker Hardened Images to ensure base image security.
Enforce consistent versioning and tagging to maintain traceability.
Automate vulnerability scanning in CI/CD pipelines.
Maintain private registries for proprietary MCP images to secure intellectual property.

Conclusion

Docker MCP transforms the deployment of AI and ML services from a fragile, bespoke process into a secure, standardized, and highly portable approach. By defining clear APIs, offering discoverable metadata, and enabling composable workflows, MCP empowers organizations to build maintainable, production-grade, agentic systems.

With Docker MCP, teams can focus on delivering real business value rather than reinventing deployment and integration for every new model or service.

Modern Docker Made Easy: Real Apps, Volumes, and Live Resource Updates

Raju Dandigam — Sun, 22 Jun 2025 02:34:04 +0000

Docker remains a cornerstone of modern dev and DevOps workflows. With Docker Desktop 4.42, released in June 2025, Docker now offers native IPv6, built-in MCP Toolkit, and expanded Model Runner AI capabilities—features that significantly enhance real-world development environments

In this guide, we will build a containerized app featuring persistent data, runtime tuning, monitoring, security, and more—with commands and concepts oriented toward professional use.

1. The Practical Value of These Docker Concepts

Network parity: IPv6 support eliminates environment discrepancies and future-proofs setups .
AI workflows: With docker model… commands, you can pull and test LLMs locally from the CLI .
Service catalog: The integrated MCP Toolkit gives instant access to 100+ tools—like GitHub, MongoDB—isolated in secure containers
Pro-grade features: This demo includes dynamic resource updates, monitoring, lifecycle control, and cleanups.

2. The Mini-App: Ping Counter

We’ll run a Node.js script that reads and increments a counter in counter.json:

project/
├─ Dockerfile
├─ counter.json  ← initializes as {"value":0}
└─ index.js

const fs = require('fs');
const data = JSON.parse(fs.readFileSync('./counter.json'));
data.value += 1;
fs.writeFileSync('./counter.json', JSON.stringify(data));
console.log(`Count is now ${data.value}`);

This simple script demonstrates containers, images, volumes, monitoring, and dynamic tuning.

3. Build the image

Dockerfile:

FROM node:20-alpine
WORKDIR /app

COPY package.json .
RUN npm install --production
COPY . .

CMD ["node", "index.js"]

Build and inspect:

docker build -t ping-counter:1.0 .
docker images

This highlights Docker’s layered approach and the modern docker image command suite.

4. Initial Run (Stateless)

echo '{"value":0}' > counter.json
docker run --name no-store ping-counter:1.0
# → Count is now 1
docker run --name no-store2 ping-counter:1.0
# → Count resets to 1

Shows that containers default to a fresh state every run.

5. Add Persistence via Volumes

docker run -d \
  --name counter \
  -v counter_data:/app/counter.json \
  ping-counter:1.0
docker logs counter           # → Count is now 1
docker restart counter && docker logs counter  # → Count increments

Volumes allow state persistence beyond container lifecycles—key for real-world apps.

6. Dynamic Runtime Tuning

Modify CPU and memory limits on the fly:

docker update --cpus="0.5" --memory="128m" counter

This live update doesn't require a container restart
Flags like --cpus, --memory, and --cpu-shares manage cgroup constraints

7. Live Monitoring

docker stats counter

Monitors runtime resource consumption. For deeper analytics, integrate Docker Desktop’s Resource Usage or Prometheus/OpenTelemetry .

8. Rebuild & Redeploy

If you change index.js to increment by five instead, do:

docker build -t ping-counter:1.1 .
docker stop counter && docker rm counter
docker run -d \
  --name counter \
  -v counter_data:/app/counter.json \
  ping-counter:1.1
docker logs counter  # → reflects new count

9. Clean-Up & Security

docker ps -a
docker images
docker volume ls

Clean unused:

docker rm no-store no-store2
docker rmi ping-counter:1.0
docker volume prune

Security best practices:

Use curated/hardened base images.
Scan using Docker Scout or Trivy.
Implement SBOM and image signing

10. Advanced Concepts Snapshot

Health checks (HEALTHCHECK) to detect container readiness.
Non-root execution enhances runtime security.
IPv6 toggling within Docker Desktop network settings
AI model experimentation: use docker model pull and docker model run.
MCP Toolkit: run MCP tools via docker mcp or UI

Conclusion

In this guide, we built a real-world Dockerized app from scratch—covering images, containers, persistent volumes, live resource tuning, monitoring, and security best practices. We also touched on modern features like IPv6 support and AI model tooling.

With this foundation, we’re now equipped to apply Docker confidently in professional workflows—and ready to take the next step into orchestration, CI/CD, or advanced container security.

Smarter JavaScript in 2025: 10 TypeScript Features You Can’t Ignore

Raju Dandigam — Wed, 28 May 2025 06:14:35 +0000

JavaScript’s flexibility remains both its strength and Achilles’ heel. In 2025, TypeScript has firmly established itself as the intelligent layer that brings structure, clarity, and safety to modern JavaScript development. This article highlights 10 advanced TypeScript features that can transform how you write, reason about, and maintain your codebase, whether you're building robust frontends or scalable full-stack applications.

1. Type Inference That Feels Like Magic

TypeScript has become incredibly good at figuring out types automatically. You don't need to define everything explicitly—TS understands your intentions through context.

const user = {
  name: "Raju",
  age: 25,
};
// TypeScript infers: { name: string; age: number }

Why it matters:

Reduces boilerplate
Keeps your code clean while staying safe
Accelerates development without sacrificing type safety
Leverages contextual typing and improved tooling support

2. The satisfies Operator

The satisfies keyword ensures that an object conforms to a particular type, while still keeping its narrower literal types intact.

const point = { x: 1, y: 2 } satisfies { x: number; y: number };

Use case: When you want stricter compile-time checks but want to retain type precision for operations.
Bonus: Unlike as, which coerces types, satisfies provides better safety and does not override literal types.

3. Module Augmentation for Third-Party Extensions

With module augmentation, you can extend existing libraries like Express without touching their core types.

declare module 'express' {
  interface Request {
    user?: { id: string; role: string };
  }
}

Why it's useful:

Enhances functionality while keeping types safe
Improves autocompletion and code readability
Ideal for plugin-based or loosely typed packages

4. Template Literal Types

Template literal types allow you to generate string combinations dynamically at the type level.

type Direction = `scroll-${'top' | 'bottom' | 'left' | 'right'}`;
type ButtonVariant = `btn-${'primary' | 'secondary' | 'tertiary'}`;

When to use: Design systems, route names, dynamic event types, or CSS utility libraries.

5. Discriminated Unions

Discriminated unions are powerful for working with complex state logic and conditional flows. They simplify switch/case scenarios and reduce runtime bugs.

type Result = 
  | { type: "success"; data: string }
  | { type: "error"; message: string };

function handle(result: Result) {
  if (result.type === "success") {
    console.log(result.data);
  } else {
    console.error(result.message);
  }
}

Real-world benefits:

Cleaner conditional logic
Safer handling of multiple object shapes
Use never to enforce exhaustive checks in switch-case logic

6. Seamless Integration with Zod for Runtime Type Safety

Tools like Zod complement TypeScript by validating data at runtime, which TS alone doesn't cover.

import { z } from 'zod';
const userSchema = z.object({
  name: z.string(),
  email: z.string().email(),
});
type User = z.infer<typeof userSchema>;

Why it’s effective:

Aligns runtime and compile-time validation
Great for form validation, APIs, and data sanitization
Alternative: io-ts, yup

7. Variadic Tuple Types

Need to type a function that accepts and returns dynamic arguments? Variadic tuple types are designed for that.

function logArgs<T extends unknown[]>(...args: T): T {
  console.log(...args);
  return args;
}

Where it's used: Logging functions, higher-order utilities, middleware wrappers—anywhere flexibility meets type safety.

8. Custom Utility Types

Beyond built-in utilities like Partial, Omit, and Pick, TypeScript allows you to create custom utilities.

type Writable<T> = {
  -readonly [P in keyof T]: T[P];
};

// Chaining example
type MutableAndOptional<T> = {
  -readonly [P in keyof T]?: T[P];
};

Practical usage:

Toggle immutability
Transform libraries' read-only types into editable ones
Create flexible, generic helpers for your codebase

9. Type Guards and Assertion Functions

TypeScript’s support for type assertions using custom guard functions makes runtime validation safer and cleaner.

function isString(value: unknown): value is string {
  return typeof value === 'string';
}

function isUser(value: any): value is User {
  return value && typeof value.name === 'string';
}

Why this is useful:

Makes runtime checks type-aware
Helps the compiler narrow down types automatically

10. Type-Safe Routing in Frameworks like Next.js

Modern frameworks like Next.js deeply integrate TypeScript into their routing, navigation, and data fetching systems.

const path = `/user/${user.id}` as const;
router.push(path);

Benefits:

Prevents broken links and route mismatches
Improves autocompletion and debugging experience
Enforces consistency across the frontend

Conclusion

In 2025, TypeScript has moved far beyond being a superset of JavaScript—it’s a cornerstone for building maintainable, intelligent, and scalable applications. Whether optimizing a legacy system or architecting a greenfield project, TypeScript's advanced type system, tooling integration, and runtime synergy with libraries like Zod allow you to ship faster without sacrificing reliability.
Mastering these 10 features will enhance your developer experience and set you up for success in any modern JavaScript ecosystem.

Template Revolution: Angular’s New Syntax That You Should Be Using Today

Raju Dandigam — Sat, 12 Apr 2025 23:47:18 +0000

Angular 17 introduced a suite of powerful new control flow directives: @if, @for, @switch, and @defer. These features bring a cleaner, more performant, and readable syntax to Angular templates, replacing the traditional structural directives like *ngIf, *ngFor, and ngSwitch. In this blog, we’ll explore each of these new directives in detail, comparing the traditional and modern approaches with examples, and discussing their benefits, performance implications, and industry adoption.

Performance and Optimization Benefits

Angular's new control flow syntax is not just syntactic improvement—it introduces significant performance benefits:

Zoneless Compatibility: These directives are optimized to work without relying on zone.js, reducing unnecessary change detection cycles.
Smaller Bundle Sizes: The new syntax reduces reliance on extra <ng-template> nodes and directives, contributing to a leaner DOM.
Faster Template Evaluation: Directives are compiled down to more efficient instructions, speeding up render time and updates.
Improved Memory Usage: With deferred loading (@defer), components that aren't immediately needed aren't created, reducing memory consumption.

Performance Data

According to Angular team benchmarks, adoption of these new syntaxes in large-scale apps has shown:

Up to 45% reduction in change detection cycles for deferred content.
10–20% improvement in initial rendering times in views utilizing @if and @for.
Reduced template complexity leads to better hydration speed in SSR/Angular Universal applications.

1. `@if` – Conditional Rendering

The @if directive allows developers to conditionally render parts of the template without relying on <ng-template> syntax. It promotes cleaner and more intuitive templates.

Before (with *ngIf):

<div *ngIf="user && user.isLoggedIn; else guest">
  <h2>Welcome, {{ user.name }}!</h2>
  <div *ngIf="user.notifications.length > 0">
    <p>You have {{ user.notifications.length }} new notifications.</p>
  </div>
</div>
<ng-template #guest>
  <h2>Hello, Guest!</h2>
  <button (click)="login()">Login</button>
</ng-template>

After (with @if):

@if (user?.isLoggedIn) {
  <h2>Welcome, {{ user.name }}!</h2>
  @if (user.notifications.length > 0) {
    <p>You have {{ user.notifications.length }} new notifications.</p>
  }
} @else {
  <h2>Hello, Guest!</h2>
  <button (click)="login()">Login</button>
}

Benefits:

Cleaner nested conditional rendering
Avoids template bloating and nesting

2. @for – Enhanced Iteration
The @for directive offers a performance-optimized and more readable way to iterate over collections. It also includes contextual variables like $index, $first, $last, and built-in empty state handling.

Before (with *ngFor):

<div *ngIf="orders.length > 0; else noOrders">
  <div *ngFor="let order of orders; let i = index; trackBy: trackByOrderId">
    <h3>Order #{{ i + 1 }} - {{ order.id }}</h3>
    <p>Status: {{ order.status }}</p>
  </div>
</div>
<ng-template #noOrders>
  <p>No recent orders found.</p>
</ng-template>

After (with @for):

@for (let order of orders; track order.id) {
  <div>
    <h3>Order #{{ $index + 1 }} - {{ order.id }}</h3>
    <p>Status: {{ order.status }}</p>
  </div>
} @empty {
  <p>No recent orders found.</p>
}

Benefits:

Declarative and self-contained rendering logic]
Built-in support for fallback UI with @empty

3. @switch – Declarative Multi-way Branching
This directive replicates JavaScript’s switch-case syntax for templates. It allows rendering different blocks based on a variable's value.

Before (with ngSwitch):

<div [ngSwitch]="device.status">
  <p *ngSwitchCase="'online'">Device is Online</p>
  <p *ngSwitchCase="'offline'">Device is Offline</p>
  <p *ngSwitchCase="'error'">Error connecting to device</p>
  <p *ngSwitchDefault>Unknown status</p>
</div>

After (with @switch):

@switch (device.status) {
  @case ('online') {
    <p>Device is Online</p>
  }
  @case ('offline') {
    <p>Device is Offline</p>
  }
  @case ('error') {
    <p>Error connecting to device</p>
  }
  @default {
    <p>Unknown status</p>
  }
}

Benefits:

Reduces repetitive directive syntax
Easier to maintain conditional UI flows

4. @defer – Lazy Loading Made Simple
The @defer directive enables lazy loading of components or template blocks based on triggers like idle time, interaction, viewport visibility, or custom logic.

Example:

@defer (on viewport; prefetch on idle) {
  <app-dashboard-analytics />
} @placeholder {
  <p>Loading analytics module...</p>
} @loading {
  <spinner />
} @error {
  <p>Failed to load analytics. Please try again.</p>
}

Benefits:

Granular control over when content loads
Improves time-to-interactive (TTI)
Minimizes memory footprint for large apps

Comparison Table

Conclusion
Angular’s new control flow syntax modernizes how developers write template logic. If you’re starting a new project, embracing these directives can greatly simplify your templates and improve maintainability. For existing codebases, a gradual migration strategy could yield both readability and performance gains.

The combination of lazy loading (@defer), cleaner conditional rendering (@if), optimized iteration (@for), and structured branching (@switch) marks a significant evolution in Angular's templating system—making it easier to build performant, scalable web applications.

A Complete Guide to Angular Component Testing with Cypress

Raju Dandigam — Sun, 06 Apr 2025 07:28:23 +0000

Angular's latest versions have introduced exciting features like signals, computed, and enhanced reactivity. Paired with Cypress Component Testing, developers now have a powerful toolkit to write fast, realistic, and robust tests. This post dives deep into Angular component testing using Cypress, including how to test components that use signals, observables, and mock services with confidence.

✨ Why Cypress for Angular Component Testing?

Cypress isn't just for end-to-end tests. With Cypress Component Testing, you can:

Render Angular components in isolation
Interact with them as a user would
Spy on inputs/outputs
Work seamlessly with Angular DI, modules, and modern features like signals

🔧 Setting Up Cypress Component Testing
Install Cypress and initialize component testing:

npm install cypress @cypress/angular --save-dev
npx cypress open --component

Follow the UI wizard to configure your Angular workspace. It will auto-generate a Cypress configuration compatible with Angular.

🛠️ Example Component with Signals & Outputs

Let's test a simple CounterComponent that demonstrates:

Input binding
Output emission
Signals and computed values

// counter.component.ts
import { Component, Input, Output, EventEmitter, signal, computed } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <div>
      <h2>{{ title }}</h2>
      <p>Count: {{ count() }}</p>
      <button (click)="increment()">Increment</button>
      <button (click)="reset()">Reset</button>
      <p>Double: {{ doubleCount() }}</p>
    </div>
  `
})
export class CounterComponent {
  @Input() title = 'Default Counter';
  @Output() onReset = new EventEmitter<void>();

  private _count = signal(0);
  count = this._count.asReadonly();
  doubleCount = computed(() => this._count() * 2);

  increment() {
    this._count.set(this._count() + 1);
  }

  reset() {
    this._count.set(0);
    this.onReset.emit();
  }
}

🔮 Basic Cypress Tests

✅ Rendering with Default and Custom Inputs

// counter.component.cy.ts
import { mount } from 'cypress/angular';
import { CounterComponent } from './counter.component';

describe('CounterComponent', () => {
  it('renders with default title', () => {
    mount(CounterComponent);
    cy.contains('Default Counter');
    cy.contains('Count: 0');
  });

  it('accepts custom title', () => {
    mount(CounterComponent, {
      componentProperties: { title: 'Custom Counter' }
    });
    cy.contains('Custom Counter');
  });
});

⚖️ Testing Signals and Computed Values

it('increments count and updates double', () => {
  mount(CounterComponent);
  cy.get('button').contains('Increment').click().click();
  cy.contains('Count: 2');
  cy.contains('Double: 4');
});

📢 Spying on Output Events

it('emits reset event', () => {
  const resetSpy = cy.spy().as('resetSpy');

  mount(CounterComponent, {
    componentProperties: {
      onReset: { emit: resetSpy } as any
    }
  });

  cy.get('button').contains('Reset').click();
  cy.get('@resetSpy').should('have.been.calledOnce');
});

📃 Testing with Observables

// message.component.ts
@Component({
  selector: 'app-message',
  template: `<p *ngIf="message">{{ message }}</p>`
})
export class MessageComponent {
  private _message = signal('');
  message = this._message.asReadonly();

  @Input()
  set messageInput$(value: Observable<string>) {
    value.subscribe(msg => this._message.set(msg));
  }
}
it('renders observable message', () => {
  const message$ = of('Hello from Observable!');
  mount(MessageComponent, {
    componentProperties: { messageInput$: message$ }
  });
  cy.contains('Hello from Observable!');
});

🔜 Advanced Mocking Techniques

⚙️ Injecting Angular Services

class MockLoggerService {
  log = cy.stub().as('logStub');
}

mount(MyComponent, {
  providers: [
    { provide: LoggerService, useClass: MockLoggerService }
  ]
});

🌐 Mocking HTTP Calls with HttpClientTestingModule

import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';

beforeEach(() => {
  cy.intercept('GET', '/api/data', { fixture: 'data.json' });
});

mount(MyHttpComponent, {
  imports: [HttpClientTestingModule]
});

🚪 Stubbing Child Components

@Component({
  selector: 'app-child',
  template: '' // stubbed template
})
class StubChildComponent {}

mount(ParentComponent, {
  declarations: [StubChildComponent]
});

🚀 Conclusion

Cypress Component Testing is a game-changer for Angular developers. By combining the real browser testing experience with Angular’s new reactivity features like signals and computed, we can create robust, testable, and modern UIs.

Key Takeaways:

Mount Angular components with Cypress easily
Test signals, computed, observables
Use spies and stubs for robust unit isolation
Mock services and HTTP with Angular-friendly tooling

Forem: Raju Dandigam

What Most Beginners Get Wrong About Building AI Apps

It’s not really about AI; it’s about decision-making

A relatable way to think about it

The simplest starting point: fixed decision paths

When the system needs to decide

When complexity grows further

Where most beginners go wrong

A more practical way to build AI systems

A useful mental model

Conclusion

Docker for TypeScript Developers Building AI Agents in 2026

Why This Problem Is Different in 2026

Docker as the Execution Layer for AI Agents

Starting Simple: Containerizing a TypeScript Agent

Moving to Real Systems: Multi-Agent Architecture

When TypeScript Meets Python

Development Experience Without Friction

What Actually Changes After Adopting This

A More Useful Mental Model

Conclusion

Cypress AI Skills: Teaching Your AI Assistant to Write Better Tests

The Real Shift: From Code Generation to Code Alignment

Getting Started

Writing Tests with cypress-author

Reviewing and Improving Tests with cypress-explain

What Actually Changes in a Real Project

Where This Helps the Most

A Note on cy.prompt()

Making This Work for Your Team

What This Is (and What It’s Not)

Conclusion

Docker as the Sandbox for AI Agents: Safe Cypress Workflows for Frontend Teams

Introduction

The Problem with Host-Based Agent Execution

Rethinking the Model: Agents Need Environments, Not Access

Where MCP Fits: The Container as the “Jailer”

A Practical Example: Fixing a Cypress Test

Deterministic Execution and Binary Parity

The Hybrid Strategy with Docker Compose

Trade-offs and Considerations

Where This Is Heading

Conclusion

AI-Assisted Cypress CI: Detecting Selector Drift and Proposing Fixes Automatically

Step 1 — Write the Cypress Test

Step 2 — Capture Failure Context

Step 3 — Run Cypress in GitHub Actions

Step 4 — Sanitize the DOM Snapshot

Step 5 — Scrub Sensitive Data

Step 6 — Call the LLM

When This Approach Works Best

Conclusion

8 Cypress Plugins Shaping Modern Testing in 2025

1. eslint-plugin-cypress: Enforcing Cypress Best Practices

Why It Matters

Installation

Setup

2. cypress-real-events: Simulate True User Behavior

Why It Matters

Installation

Usage

3. @cypress/code-coverage: Know What You're Testing

Why It Matters

Installation

Setup

4. @testing-library/cypress: User-Focused Testing

Why It Matters

Installation

Setup

Example

5. cypress-axe: Automated Accessibility Checks

Why It Matters

Installation

Usage

6. cypress-vite: Use Your Vite Config

Why It Matters

Installation

Setup

7. cypress-mochawesome-reporter: Better Test Reports

Why It Matters

Writing Tests with `cypress-author`

Reviewing and Improving Tests with `cypress-explain`

A Note on `cy.prompt()`

1. `eslint-plugin-cypress`: Enforcing Cypress Best Practices

2. `cypress-real-events`: Simulate True User Behavior

3. `@cypress/code-coverage`: Know What You're Testing

4. `@testing-library/cypress`: User-Focused Testing

5. `cypress-axe`: Automated Accessibility Checks

6. `cypress-vite`: Use Your Vite Config

7. `cypress-mochawesome-reporter`: Better Test Reports

8. `@cypress/grep`: Advanced Filtering With Tags

1. `@if` – Conditional Rendering