Vibe Coding Forem

VoiceScribe

Jan Klein — Sun, 05 Apr 2026 20:40:47 +0000

VoiceScribe

RealTime Speech To Text App Built with Google AI Studio

What it does

VoiceScribe is a realtime speech to text web app that supports 20 languages. You speak, it writes. Then you copy or share the text.

It works on all browsers Chrome, Firefox, Safari, Edge, and mobile browsers.

How it works

Simple. Your browser captures your voice. Google's AI turns it into text. You see it instantly.

How I built it

HTML structure of the page, language dropdown, buttons.

CSS styling, responsive design, works on phone and desktop.

Vanilla JavaScript microphone access, sending audio to Google API, displaying text, copy and share functions.

Google AI Studio provides the API key for Google Cloud Speech-to-Text.

Netlify hosting, free.

No frameworks. No backend. No database.

Useful for education

This app is a perfect teaching example for students who want to learn:

How browser APIs work (microphone, clipboard, sharing)
How to integrate Google AI into a real project
How to build a complete useful app with just HTML, CSS, and JavaScript
How to handle permissions, errors, and different browsers

My experience with Google AI Studio

It helped me save time with API access. But it has problems.
It does not follow human language instructions well. I had to use custom instructions which only developers know how to write.
It sometimes adds code without asking or makes failures. You should make a backup each time you create a new version.

Try it

Open voice-scribe.netlify.app in any browser, pick a language, and speak.

For information & questions contact me at: bix.pages.dev

AI helps me code faster, but not always understand better

Bohdan Chuprynka — Sun, 05 Apr 2026 20:39:44 +0000

I’ve been thinking about this a lot lately.

AI coding tools are obviously useful. They help you move faster, get unstuck, write boilerplate, debug, and try things quickly.

But I keep noticing the same tension:

Sometimes AI helps you finish something without helping you really understand it.

The code works.
The task is done.
But your confidence in the code is not always there.

I think that matters a lot, especially for:
people learning to code

students
developers trying to stay sharp
anyone using AI but still wanting to actually understand what they’re building

That’s the reason I’ve been exploring an idea for a tool that feels more like a mentor inside the editor, not just something that generates code.

Something that helps you:

understand what the code is doing
catch weak spots in your thinking
notice when you’re relying on AI too quickly
learn while building, not only finish faster

I’m trying to figure out whether this is a real problem other people feel too, or if it’s just something I’ve personally noticed.

So I made a very short survey for anyone who has used AI for coding, debugging, or learning programming.

It’s just 4 questions and takes about 1 minute:

https://forms.gle/GynGGBWF46de9jz47

If you’ve used AI for coding even once, I’d really value your input.

Also curious what people here think:

Has AI made you better at coding, or mostly just faster?

Chaining MCP Tools: Build AI Workflows That Search, Read, Analyze, and Write

NeuroLink AI — Sun, 05 Apr 2026 20:27:53 +0000

What is MCP Tool Chaining?

Imagine an AI that can not only understand a request like "Analyze our codebase for security vulnerabilities and report them," but also execute that request end-to-end. This requires more than just a single AI model. It needs an orchestration layer that allows the AI to:

Search external systems (e.g., GitHub, a file system).
Read and comprehend various data formats (code, documents, database records).
Analyze the information using its inherent intelligence.
Act on its findings by writing code, creating issues, generating reports, or sending messages.

MCP tool chaining is the mechanism that makes this possible. It's an architecture where AI models interact with a standardized set of tools (MCP servers) that expose real-world capabilities. When an AI needs to perform a task that requires external interaction, it invokes the appropriate tool, processes the output, and then uses another tool to continue the workflow.

Example Workflow 1: Code Analysis and Issue Creation

Let's consider a practical example: an AI agent performing continuous code quality monitoring.

The Workflow:

Search GitHub: The AI uses a GitHub MCP tool to search for new pull requests or recently committed code in a specific repository.
Read Code: Once new code is identified, the AI uses the GitHub MCP tool to read the relevant files.
Analyze Patterns: The AI then analyzes the code for potential bugs, security vulnerabilities, or deviations from coding standards.
Create Issue: If issues are found, the AI uses the GitHub MCP tool to automatically create a new GitHub issue, detailing the problem, suggesting a fix, and assigning it to the relevant team.

This entire process, from detection to reporting, can be fully automated through MCP tool chaining.

Example Workflow 2: Data-Driven Reporting

Another powerful application lies in data analysis and reporting.

The Workflow:

Query Database: An AI is tasked with generating a weekly sales report. It uses a PostgreSQL MCP tool to query the sales database, fetching relevant data like product sales, regional performance, and customer demographics.
Analyze Data: The AI processes the raw data, identifying trends, anomalies, and key insights.
Generate Report: Based on its analysis, the AI uses its generative capabilities to draft a comprehensive report, including summaries, visualizations (if integrated with a charting tool), and strategic recommendations.
Post to Slack: Finally, the AI uses a Slack MCP tool to post the generated report (or a summary of it) to the relevant team's channel, ensuring stakeholders are promptly informed.

NeuroLink: Orchestrating the AI Nervous System

NeuroLink is designed to be the "pipe layer for the AI nervous system," specifically built to facilitate these complex, multi-tool AI workflows. It unifies over 13 major AI providers and provides a seamless way to connect and chain MCP tools.

One of NeuroLink's key features is its addExternalMCPServer method, which allows you to integrate any external tool or system as an MCP server. Once registered, NeuroLink enables the AI to automatically discover and chain these tools based on the task at hand.

Code Examples with NeuroLink API

Here's how you might configure NeuroLink to connect to GitHub, a PostgreSQL database, and Slack, and then leverage them in an AI workflow.

import { NeuroLink } from "@juspay/neurolink";

const neurolink = new NeuroLink();

// 1. Add GitHub as an MCP server
// This enables AI to interact with GitHub for searching, reading, and creating issues/PRs.
await neurolink.addExternalMCPServer("github", {
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-github"],
  transport: "stdio", // Using stdio for local execution
  env: { GITHUB_TOKEN: process.env.GITHUB_TOKEN }, // Securely pass credentials
});

// 2. Add PostgreSQL as an MCP server
// This allows AI to query and manipulate database records.
await neurolink.addExternalMCPServer("postgres", {
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-postgres"],
  transport: "stdio",
  env: { DATABASE_URL: process.env.DATABASE_URL },
});

// 3. Add Slack as an MCP server
// This empowers AI to post messages, summaries, or reports to Slack channels.
await neurolink.addExternalMCPServer("slack", {
  transport: "http", // Assuming a remote Slack MCP server
  url: "https://your-mcp-slack-server.com/api",
  headers: { Authorization: `Bearer ${process.env.SLACK_BOT_TOKEN}` },
});

// Now, the AI can chain these tools automatically based on the prompt:
const result = await neurolink.generate({
  input: {
    text: `
      1. Find all recently closed GitHub issues in the 'neurolink' repository related to 'performance'.
      2. Analyze the resolution steps and any associated code changes.
      3. Query the 'production_metrics' PostgreSQL database for performance data during the resolution period.
      4. Based on the analysis, draft a summary report on the effectiveness of the fixes and post it to the #engineering-updates Slack channel.
    `,
  },
});

console.log(result.content); // The AI's generated content, after tool execution

In this example, NeuroLink acts as the central orchestrator, receiving the high-level request, breaking it down into sub-tasks, identifying the appropriate MCP tools (GitHub, Postgres, Slack), executing them in sequence, and synthesizing the results. The AI agent, powered by NeuroLink, intelligently decides which tool to use at each step, forming a dynamic "tool chain."

Debugging Tool Chains

Building complex AI workflows inevitably involves debugging. Here are some tips when working with NeuroLink and MCP tool chains:

Verbose Logging: Enable verbose logging in NeuroLink to see the exact tool calls the AI makes, their inputs, and their outputs. This is crucial for understanding the AI's decision-making process.
Isolate Tools: Test each MCP server independently to ensure it functions correctly before integrating it into a complex chain.
Step-by-Step Execution: For difficult cases, use NeuroLink's interactive CLI (neurolink loop) or prepareStep feature to step through the AI's thought process and tool invocations.
Validate Inputs/Outputs: Ensure that the output of one tool call correctly matches the expected input format for the next tool in the chain. Discrepancies here are a common source of errors.

Performance: ToolCache and RequestBatcher for Optimization

As AI agents perform more complex tasks, performance becomes critical. NeuroLink offers built-in mechanisms to optimize tool chain execution:

ToolCache: This module allows NeuroLink to cache the results of frequently called, idempotent tools. If an AI requests the same data (e.g., a file content from GitHub) multiple times within a short period, ToolCache can serve the result from memory instead of re-executing the tool, significantly reducing latency and API costs. You can configure various caching strategies like LRU, FIFO, or LFU.
```
import { ToolCache, NeuroLink } from "@juspay/neurolink";

const cache = new ToolCache({ strategy: "lru", maxSize: 1000, ttl: 300_000 }); // Cache for 5 minutes

const neurolink = new NeuroLink({
  // ... other config
  mcp: {
    toolCache: cache,
  },
});
```

RequestBatcher: For tools that can process multiple requests efficiently in a single call (e.g., querying a database for several items), RequestBatcher automatically groups concurrent tool calls into a single batch request. This reduces the overhead of individual API calls, improving throughput.

import { RequestBatcher, NeuroLink } from "@juspay/neurolink";

const batcher = new RequestBatcher({ maxBatchSize: 10, maxWaitMs: 50 }); // Batch up to 10 requests or wait 50ms

const neurolink = new NeuroLink({
  // ... other config
  mcp: {
    requestBatcher: batcher,
  },
});

By intelligently applying caching and batching, NeuroLink ensures that your AI workflows remain performant and cost-effective, even when interacting with numerous external systems.

Conclusion

MCP tool chaining with NeuroLink unlocks a new frontier in AI capabilities. By providing a robust framework for connecting and orchestrating diverse tools, NeuroLink empowers developers to build sophisticated AI agents that can search, read, analyze, and write across virtually any digital system. This ability to chain operations fundamentally transforms how AI can be integrated into real-world applications, paving the way for truly autonomous and intelligent workflows.

NeuroLink — The Universal AI SDK for TypeScript

GitHub: github.com/juspay/neurolink
Install: npm install @juspay/neurolink
Docs: docs.neurolink.ink
Blog: blog.neurolink.ink — 150+ technical articles

I built a faster alternative to cp and rsync — here's how it works

krit.k83 (ΚρητικόςIGB) — Sun, 05 Apr 2026 20:27:08 +0000

I'm a systems engineer. I spend a lot of time copying files — backups to USB drives, transfers to NAS boxes, moving data between servers over SSH. And I kept running into the same frustrations:

cp -r is painfully slow on HDDs when you have tens of thousands of small files
rsync is powerful but complex, and still slow for bulk copies
scp and SFTP top out at 1-2 MB/s on transfers that should be much faster
No tool tells you upfront if the destination even has enough space

So I built fast-copy — a Python CLI that copies files at maximum sequential disk speed.

The core idea

When you run cp -r, files are read in directory order — which is essentially random on disk. Every file seek on an HDD costs 5-10ms. Multiply that by 60,000 files and you're spending minutes just on head movement.

fast-copy does something different: it resolves the physical disk offset of every file before copying. On Linux it uses FIEMAP, on macOS fcntl, on Windows FSCTL. Then it sorts files by block position and reads them sequentially.

That alone makes a big difference. But there's more.

Deduplication

Many directories have duplicate files — node_modules across projects, cached downloads, backup copies. fast-copy hashes every file with xxHash-128 (or SHA-256 as fallback), copies each unique file once, and creates hard links for duplicates.

In my test with 92K files, over half were duplicates — saving 379 MB and a lot of I/O time.

It also keeps a SQLite database of hashes, so repeated copies to the same destination skip files that were already copied in previous runs.

SSH tar streaming

This is the part I'm most proud of. Instead of using SFTP (which has significant protocol overhead), fast-copy streams files as chunked ~100 MB tar batches over raw SSH channels.

The remote side runs tar xf - and files land directly on disk — no temp files, no SFTP overhead. This even works on servers that have SFTP disabled, like some Synology NAS configurations.

Three modes are supported:

Local → Remote
Remote → Local
Remote → Remote (relay through your machine)

Real benchmarks

Local copy — 92K files to USB:

44,718 unique files copied + 47,146 hard-linked
509.8 MB written, 378.9 MB saved by dedup
17.9 seconds, 28.5 MB/s
All files verified after copy

Remote to local — 92K files over LAN:

509.8 MB downloaded in 14 minutes
46,951 duplicates detected, saving 378.5 MB of transfer
3x faster than SFTP

Getting started

The simplest way — just run the Python script:

python fast_copy.py /source /destination

Or download a standalone binary (no Python needed) from the Releases page — available for Linux, macOS, and Windows.

For SSH transfers, install paramiko:

pip install paramiko

For faster hashing:

pip install xxhash

Chaining MCP Tools: Search Read Analyze Write in TypeScript

NeuroLink AI — Sun, 05 Apr 2026 20:26:55 +0000

Chaining MCP Tools: Search → Read → Analyze → Write in TypeScript

Building sophisticated AI agents requires more than simple prompt-response interactions. Real-world automation demands multi-step workflows where AI performs sequential operations—gathering information, processing it, and taking action. This is where NeuroLink's Model Context Protocol (MCP) tool chaining capabilities transform what's possible with TypeScript.

The Anatomy of a Tool Chain

Consider a typical developer workflow: searching GitHub for relevant code, reading files, analyzing patterns, and creating issues. Previously, this required orchestrating multiple API calls, managing state, and handling errors across different services. NeuroLink unifies these operations into a single, coherent AI workflow.

Let's build a code review agent that chains MCP tools:

import { NeuroLink } from "@juspay/neurolink";

const neurolink = new NeuroLink();

// Connect GitHub MCP server
await neurolink.addExternalMCPServer("github", {
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-github"],
  transport: "stdio",
  env: { GITHUB_TOKEN: process.env.GITHUB_TOKEN },
});

// Connect code analysis MCP server
await neurolink.addExternalMCPServer("code-analyzer", {
  transport: "http",
  url: "https://api.codeanalysis.tools/mcp",
  headers: { Authorization: "Bearer YOUR_API_KEY" },
});

// Execute a multi-step workflow
const result = await neurolink.generate({
  input: {
    text: `Search the "acme-corp/payments" repo for all files using "processPayment()"
           function, analyze the code for security vulnerabilities, and create a GitHub
           issue titled "Security Review: processPayment() usage" with findings.`
  },
  model: "claude-4-sonnet",
  provider: "anthropic"
});

// NeuroLink orchestrates the chain:
// 1. Calls github.search_code()
// 2. Calls github.read_file() for each result
// 3. Calls code-analyzer.analyze() on content
// 4. Calls github.create_issue() with findings

Understanding the Chain

The beauty of NeuroLink's approach is that the LLM decides the optimal sequence of tool calls. When given a complex task, the AI breaks it down into discrete steps:

Step 1: Search
  └─ MCP Tool: github.search_code
  └─ Query: "processPayment repo:acme-corp/payments"
  └─ Result: 5 files found

Step 2: Read
  ├─ MCP Tool: github.read_file (file 1)
  ├─ MCP Tool: github.read_file (file 2)
  └─ ... (parallel execution)

Step 3: Analyze
  └─ MCP Tool: code-analyzer.analyze
  └─ Input: Combined file contents
  └─ Result: 3 security findings

Step 4: Write
  └─ MCP Tool: github.create_issue
  └─ Title: "Security Review: processPayment() usage"
  └─ Body: Formatted analysis with code snippets

Building Intelligent Routers

For production applications, you need more than basic tool execution. NeuroLink provides a ToolRouter for intelligent routing across multiple MCP servers:

import { ToolRouter, ToolCache } from "@juspay/neurolink";

// Route calls based on capability matching
const router = new ToolRouter({
  strategy: "capability-based",
  servers: [
    {
      name: "primary-db",
      url: "https://mcp-primary.db.internal/mcp",
      capabilities: ["query", "transaction"]
    },
    {
      name: "analytics-db",
      url: "https://mcp-analytics.db.internal/mcp",
      capabilities: ["aggregate", "report"]
    },
    {
      name: "github",
      url: "https://mcp-github.tools.internal/mcp",
      capabilities: ["repo", "issue", "pr"]
    }
  ]
});

// Cache expensive operations
const cache = new ToolCache({
  strategy: "lru",
  maxSize: 500,
  ttl: 60_000
});

// Use in your NeuroLink instance
await neurolink.configureMCP({
  router,
  cache,
  batcher: { maxBatchSize: 10, maxWaitMs: 50 }
});

Human-in-the-Loop for Critical Actions

Not all tool chains should execute autonomously. NeuroLink's HITL (Human-in-the-Loop) system ensures human approval for sensitive operations:

const neurolink = new NeuroLink({
  hitl: {
    enabled: true,
    requireApproval: ["github.create_issue", "github.merge_pr", "db.execute"],
    confidenceThreshold: 0.85,
    reviewCallback: async (action, context) => {
      // Send to Slack for approval
      const approval = await slack.sendApprovalRequest({
        action: action.name,
        parameters: action.params,
        context: context.conversationSummary
      });
      return approval.approved;
    }
  }
});

// The AI will pause before creating issues
// and wait for human approval
const result = await neurolink.generate({
  input: { text: "Create a critical bug report for the auth module" }
});

Real-World Example: Documentation Sync Agent

Here's a complete implementation that keeps documentation synchronized with code:

import { NeuroLink } from "@juspay/neurolink";

async function createDocSyncAgent() {
  const neurolink = new NeuroLink();

  // Add required MCP servers
  await neurolink.addExternalMCPServer("github", {
    command: "npx",
    args: ["-y", "@modelcontextprotocol/server-github"],
    transport: "stdio",
    env: { GITHUB_TOKEN: process.env.GITHUB_TOKEN }
  });

  await neurolink.addExternalMCPServer("notion", {
    transport: "http",
    url: "https://api.notion.com/mcp",
    headers: { Authorization: `Bearer ${process.env.NOTION_TOKEN}` }
  });

  // The agent workflow
  const syncDocumentation = async (repo: string, notionPage: string) => {
    return await neurolink.generate({
      input: {
        text: `Sync API documentation between GitHub repo "${repo}" and Notion page "${notionPage}".

               Steps:
               1. Search ${repo} for all files ending in "API.ts" or containing "@api" JSDoc
               2. Read each API file and extract endpoint definitions
               3. Compare with existing content in Notion page ${notionPage}
               4. Update Notion with any new endpoints or changes
               5. Create a summary of updates made`
      },
      model: "claude-4-sonnet",
      provider: "anthropic",
      hitl: {
        enabled: true,
        requireApproval: ["notion.update_page"]
      }
    });
  };

  return { syncDocumentation };
}

// Usage
const agent = await createDocSyncAgent();
await agent.syncDocumentation(
  "acme-corp/payments-api",
  "api-documentation-2024"
);

Best Practices for Tool Chaining

Design for composability: Build small, focused MCP servers that do one thing well
Use result caching: Expensive operations like code analysis should be cached
Implement HITL for mutations: Always require approval for state-changing operations
Handle failures gracefully: Design chains that can retry or skip failed steps
Monitor execution: Use NeuroLink's telemetry to track tool usage and latency

Conclusion

MCP tool chaining with NeuroLink transforms AI agents from chatbots into autonomous workers capable of complex, multi-step workflows. By combining search, read, analyze, and write operations through a unified interface, you can automate sophisticated developer workflows while maintaining control and visibility.

The future of AI isn't just smarter models—it's smarter orchestration of tools that work together seamlessly.

NeuroLink — The Universal AI SDK for TypeScript

GitHub: github.com/juspay/neurolink
Install: npm install @juspay/neurolink
Docs: docs.neurolink.ink
Blog: blog.neurolink.ink — 150+ technical articles

The Service Layer: Where Separate Components Become a System

Ozioma Ochin — Sun, 05 Apr 2026 20:24:51 +0000

This is Part 4 of a series building a production-ready semantic search API with Java, Spring Boot, and pgvector.

Part 1 covered the architecture.

Part 2 defined the schema.

Part 3 handled the embeddings — how text becomes vectors.

Each piece worked in isolation.

But systems don't fail in isolation — they fail at the boundaries.

If you've ever built a feature that worked perfectly on its own but broke the moment you connected it to everything else — this article is about preventing that.

At this point, we have a schema that can store documents and an embedding layer that can generate vectors.

But nothing connects them. A document has nowhere to go. A query has no pipeline.

This is where the service layer comes in.

This is a production-style implementation — not a demo. The full project structure, tests, and configuration are available on GitHub.

What Does the Service Layer Actually Do?

The database stores state, but it doesn't understand it.

PENDING, READY, and FAILED only become meaningful once the service layer defines when those transitions happen and what triggers them.

When a document arrives, the service decides the order of operations — save first, embed second, update on success, record failure explicitly if something goes wrong.

Search follows the same pattern. A query doesn't go straight to the database. It's first converted into an embedding, then passed through a query that applies lifecycle constraints, metadata filters, and scoring thresholds.

The service layer controls that entire pipeline.

The service layer owns one thing: the rules that make the system predictable.

Without it, the system is just a collection of correct but disconnected components.

HTTP Request
     │
     ▼
Controller Layer       ← validates input, delegates to service
     │
     ▼
Service Layer          ← all decisions happen here
     │                    │
     ▼                    ▼
Repository Layer      Embedding Layer
(JPA + JdbcTemplate)  (EmbeddingClient interface)
     │                    │
     ▼                    ▼
PostgreSQL + pgvector  OpenAI API

The Interface That Keeps Everything Clean

The service layer exposes one interface to the rest of the application:

public interface DocumentService {
    CreateDocumentResponse create(CreateDocumentRequest request);
    DocumentResponse getById(Long id);
    SearchResponse search(SearchRequest request);
}

Controllers depend on the interface, not the implementation.

Defining the contract as an interface and hiding the implementation behind it is what makes the system testable and changeable without cascading updates across the codebase.

The more important detail is what does not cross this boundary.

The Document entity never crosses this boundary — by design. Controllers receive DTOs, not persistence objects.

That separation means the database schema and the API contract can evolve independently. The schema can change without breaking clients. The API can change without rewriting persistence logic.

Why this matters to you: If you've ever had a database change break your API — or an API change force a database rewrite — this boundary is what prevents that. Define it early and hold it firmly.

What Happens When Embedding Fails?

From the outside, creating a document looks simple. Send a document, get an ID back.

Inside the service, everything is built around one assumption: the second step might fail.

@Override
@Transactional
public CreateDocumentResponse create(CreateDocumentRequest request) {

    Document saved = saveAsPending(request);

    embedAndPersist(
            saved.getId(),
            saved.getTitle(),
            saved.getContent()
    );

    return new CreateDocumentResponse(
            saved.getId(),
            DocumentStatus.READY
    );
}

Two lines, two distinct operations.

The first saves the document immediately with a status of PENDING.

The document exists in the database before any embedding call is made.

If the application crashes at this point, the document is already there with a recoverable state.

The second calls the OpenAI API, generates the embedding, and updates the document to READY.

If this step fails, the document moves to FAILED instead, and the error is stored directly in the database.

POST /documents
      │
      ▼
saveAsPending()
status = PENDING ← document is safe in the database
      │
      ▼
embedAndPersist()
      │
   ┌──┴──────────────┐
   │                 │
   ▼                 ▼
status = READY   status = FAILED
searchable       error stored in DB
                 excluded from search

There's an alternative that looks simpler — embed first, then save.

It removes a step but removes visibility. If embedding fails in that model, the document never exists. There's no record, no state, nothing to debug.

By saving first, every attempt leaves a trace.

Failures don't disappear.

They become data.

This pattern — save first, embed second — is the difference between a failure you can debug and one that just disappears.

Here's how the failure handling actually works:

private void embedAndPersist(Long documentId, String title, String content) {
    try {
        float[] embedding = embeddingClient.embed(title + "\n\n" + content);
        int updated = jdbcTemplate.update(SQL_UPDATE_EMBEDDING,
                toPgVectorLiteral(embedding), documentId);
        if (updated != 1) {
            throw new IllegalStateException(
                    "Unexpected row count updating embedding for document id=" + documentId);
        }
    } catch (IllegalStateException e) {
        throw e;
    } catch (Exception e) {
        markFailed(documentId, e.getMessage());
        throw new RuntimeException("Embedding failed for document id=" + documentId, e);
    }
}

Three decisions here worth understanding:

Title and content are concatenated for embedding. title + "\n\n" + content gives the model full context. A document titled "Payment Failure Handling Policy" with content about retry logic produces a richer embedding than the content alone.
IllegalStateException is re-thrown unchanged. If the update affects zero or more than one row, something is wrong with the database state — not the embedding call. That error should propagate as-is rather than being wrapped as an embedding failure.
Everything else triggers markFailed. Network timeouts, rate limits, malformed responses — any exception that isn't an IllegalStateException records the failure and re-throws. The caller sees the failure. The database gets a record of what went wrong.

Most API integration failures are silent. This makes them loud.

Search — The Pipeline That Ties Everything Together

Search is the most complex operation in the service. It touches the embedding layer, the repository, and the database — and it has to coordinate all three correctly.

What makes it manageable is not reducing that complexity, but containing it deliberately.

The orchestration method is deliberately small:

@Override
public SearchResponse search(SearchRequest request) {

    String qVector = embedQuery(request.getQuery());

    List<SearchResultItem> items = fetchResults(
            request,
            qVector
    );

    int total = countResults(
            qVector,
            request.getFilters(),
            request.getMinScore()
    );

    return new SearchResponse(
            request.getPage(),
            request.getSize(),
            total,
            items
    );
}

Four lines. Each delegates to a private method with a clear name.

The method reads like a description of the search process — embed the query, fetch the results, count the total, return the response.

The how is pushed down into methods that can be reasoned about in isolation.

private String embedQuery(String query) { 
return toPgVectorLiteral(embeddingClient.embed(query)); 
}

The query goes through the same embedding client used for documents.

That symmetry matters — the query and the stored documents exist in the same vector space. Without it, similarity search would be meaningless.

The SQL is constructed in two layers: the inner query selects candidates and computes similarity, while the outer query applies score thresholds and pagination.

The split isn't stylistic. PostgreSQL cannot reference a SELECT alias in a WHERE clause at the same query level — which is why cosine_distance must be resolved in a subquery before the score threshold can filter on it.

SELECT * FROM (
    SELECT id, title, content, metadata,
           (embedding <=> ?::vector) AS cosine_distance
    FROM documents
    WHERE status = 'READY'
      AND embedding IS NOT NULL
      AND (metadata->>'category') = ?
) AS sub
WHERE (((1.0 - cosine_distance) + 1.0) / 2.0) >= ?
ORDER BY cosine_distance ASC
LIMIT ? OFFSET ?;

If you've ever wondered why your JPA queries feel limiting for complex use cases — this is where you cross that line deliberately.

Why JPA Isn’t Enough for Vector Search

The search query isn't static.

Metadata filters, score thresholds, and pagination all change the SQL at runtime.

At that point the abstraction provided by JPA starts to break down — you're no longer mapping objects, you're constructing a query.

That's where QueryBuilder comes in:

private static class QueryBuilder {

   private final StringBuilder sql;
   private final List<Object> params = new ArrayList<>();

   QueryBuilder(String baseSql, String firstParam) {
       this.sql = new StringBuilder(baseSql);
       this.params.add(firstParam);
   }

   QueryBuilder(String baseSql, QueryBuilder source) {
       this.sql = new StringBuilder(baseSql);
       this.params.addAll(source.params);
   }
}

The two constructors mirror the structure of the query – inner and outer.

The first builds the inner query.

The second builds the outer query, inheriting parameters from the inner one without tracking them manually.

Where injection risk actually lives:

void applyFilters(Map<String, String> filters) {
   if (filters == null || filters.isEmpty()) return;

   for (Map.Entry<String, String> entry : filters.entrySet()) {
       String key = entry.getKey();

       if (key == null || !key.matches("^[a-zA-Z0-9_-]{1,64}$")) {
           throw new IllegalArgumentException("Invalid metadata filter key: " + key);
       }

       sql.append("  AND (metadata->>'").append(key).append("') = ?\n");
       params.add(entry.getValue());
   }
}

The filter key is appended directly into the SQL string. SQL doesn't allow placeholders for column names or JSON path expressions — which means this is where injection risk enters the system.

The regex is not a convenience. It is the only control point between user input and the database.

^[a-zA-Z0-9_-]{1,64}$ — only alphanumeric characters, underscores, and hyphens.

Anything else is rejected before it reaches the database. Filter values, on the other hand, always go through JDBC parameters and are safe regardless of input.

This split — validated keys, parameterised values — is what makes the query both flexible and secure.

This is one of those cases where the 'boring' regex is doing serious security work. Don't skip it.

Key validation handles injection risk. The other challenge in query construction is where to apply the score threshold.

Score filtering is applied on the outer query — not the inner one. cosine_distance is defined in the inner query's SELECT clause.

PostgreSQL cannot reference that alias in a WHERE clause at the same level. Wrapping it as a subquery makes it a real column in the outer scope — which is what allows minScore to work at all.

This is the point where you stop “using an ORM” and start designing queries deliberately.

Updating a Document means Updating Its Embedding Too

Updating a document is not the same as updating a database row.

When content changes, the stored embedding becomes stale. A document about "payment retry logic" gets updated to "refund processing."

But the embedding still points toward payment retries. Searches for "refund policy" would miss it. Searches for "payment retries" would still find it — incorrectly.

The update operation handles this explicitly:

private void applyUpdates(Document doc, UpdateDocumentRequest request) {
    doc.setTitle(request.getTitle());
    doc.setContent(request.getContent());
    doc.setMetadata(request.getMetadata());
    doc.setStatus(DocumentStatus.PENDING);
    doc.setEmbeddingError(null);
    documentRepository.save(doc);
}

The moment content changes, the embedding becomes invalid.

The system makes that explicit by resetting the document to PENDING, removing it from search until a new embedding is generated.

This trades availability for correctness — a document disappearing briefly is preferable to returning incorrect results.

findOrThrow is called again after embedAndPersist so the response reflects the document's final state — including the updated status and embeddingUpdatedAt timestamp — not the state before the embedding ran.

This is easy to miss when you first build it. If a document update doesn't trigger a re-embed, your search results will silently drift out of sync with your content.

One Place for All Your Errors

Errors in this system fall into two categories — errors the caller caused and errors the system encountered.

Those two cases should not look the same.

A missing document returns a 404. Invalid input returns a 400. An embedding failure returns a 500.

What matters more than the distinction is consistency — every error, regardless of where it originates, returns the same shape:

{
  "code": "NOT_FOUND",
  "message": "Document not found: 42"
}

That consistency is enforced in one place — GlobalExceptionHandler.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleNotFound(
            ResourceNotFoundException ex
    ) {
        return ResponseEntity.status(404)
                .body(new ErrorResponse(
                        "NOT_FOUND",
                        ex.getMessage()
                ));
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handleValidation(
            MethodArgumentNotValidException ex
    ) {
        String message = ex.getBindingResult()
                .getFieldErrors()
                .stream()
                .map(e -> e.getField() + ": " + e.getDefaultMessage())
                .collect(Collectors.joining(", "));

        return ResponseEntity.status(400)
                .body(new ErrorResponse(
                        "VALIDATION_ERROR",
                        message
                ));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGeneral(
            Exception ex
    ) {
        return ResponseEntity.status(500)
                .body(new ErrorResponse(
                        "INTERNAL_ERROR",
                        "An unexpected error occurred"
                ));
    }
}

The @RestControllerAdvice annotation makes it active across all controllers without being wired into any of them.

The service layer throws exceptions. The handler translates them. The controllers never see error handling code.

A client that always receives code and message can handle all errors with one piece of logic.

A client that receives different shapes from different endpoints has to handle each one separately.

One handler, consistent responses everywhere — your frontend team will thank you.

How the LifecycleKeeps Bad Data Out of Search

The document lifecycle isn't just about tracking failures. It's what keeps invalid data out of search results entirely.

Every search query filters on two conditions before any similarity calculation runs:


WHERE status = 'READY'
    AND embedding IS NOT NULL

A PENDING document is excluded. A FAILED document is excluded.

This is where the schema design from Part 2 pays off — the composite index on (status, created_at DESC) exists specifically to support this filtering pattern.

Without it, every search scans the full table and discards non-ready documents. With it, PostgreSQL jumps directly to the relevant subset.

PENDING ──────────────────────────────┐
   │                                  │
   ▼                                  │
embedAndPersist()                     │
   │                                  │
┌──┴──────────────┐                   │
│                 │                   │
▼                 ▼                   ▼
READY          FAILED            not searchable
searchable     error in DB
               not searchable

The lifecycle isn't just about correctness. It's a performance optimization.

If you've ever had stale or incomplete data show up in search results with no explanation — a lifecycle model like this is what prevents it.

The System Now Works

With the service layer in place, the system finally behaves like a system.

A document arrives at POST /documents. The controller validates the request and delegates to the service.

The service saves the document as PENDING, calls the embedding client, and updates the status to READY.

The document is now stored with a valid embedding and visible to search.

A search query arrives at POST /search.

The service embeds the query, builds the SQL dynamically through QueryBuilder, applies filters and score thresholds, and returns ranked results with three score fields — cosineDistance, cosineSimilarity, and score.

Every layer has exactly one job. Every failure is visible. Every response has a consistent shape.

The system that started as a schema and an embedding client in Part 1 is now a complete, working API.

What's Next

The service layer completes the system. Everything now works end to end.

But working systems still have flaws.

In the next article, I’ll step back from the implementation and break down what this system gets right, what it gets wrong, and what I would change if I were to build it again.

See you there.

Understanding Data Modelling in Power BI: Joins, Relationships, and Schemas Explained

Dalton Imbiru — Sun, 05 Apr 2026 20:22:55 +0000

Data modelling is the foundation of effective data analysis in Power BI. A well-structured model ensures faster performance, accurate calculations, and easier report building. This article breaks down everything you need to know—from SQL joins and Power BI relationships to schemas and practical implementation steps.

What is Data Modelling?

Data modelling is the process of organising data into tables and defining how those tables relate to each other so that analysis becomes meaningful and efficient.

In Power BI, data modeling involves:

Structuring tables (Fact and Dimension)
Defining relationships between tables
Optimizing performance and usability

SQL Joins Explained (With Examples)

Joins combine data from two or more tables based on a common column.

Examples:

Customers

CustomerID	Name
1	John
2	Mary
3	Alex

Orders

OrderID	CustomerID
101	1
102	2
103	4

INNER JOIN

Returns only matching records from both tables.

Result:

CustomerID	Name	OrderID
1	John	101
2	Mary	102

Use case: When you only want valid matches (e.g., customers who made purchases).

LEFT JOIN

Returns all records from the left table + matching from the right.

Result:

CustomerID	Name	OrderID
1	John	101
2	Mary	102
3	Alex	NULL

Use case: Show all customers, even those without orders.

RIGHT JOIN

Returns all records from the right table + matching from the left.

Result:

CustomerID	Name	OrderID
1	John	101
2	Mary	102
NULL	NULL	103

Use case: Show all orders, even if customer info is missing.

FULL OUTER JOIN

Returns all records from both tables.

Result:

CustomerID	Name	OrderID
1	John	101
2	Mary	102
3	Alex	NULL
NULL	NULL	103

Use case: Complete data reconciliation.

LEFT ANTI JOIN

Returns rows from left table that have no match in right table.

Result:

CustomerID	Name
3	Alex

Use case: Identify customers who never purchased.

RIGHT ANTI JOIN

Returns rows from right table with no match in left table.

Result:

OrderID	CustomerID
103	4

Use case: Identify orphan records (e.g., invalid orders).

Joins in Power BI (Power Query)

Power BI implements joins in Power Query.

Steps:

Go to Home → Transform Data
Select a table
Click Merge Queries
Select second table
Choose matching column(s)
Select join type:

Inner
Left Outer
Right Outer
Full Outer
Left Anti
Right Anti
1. Expand columns to finalize

Relationships in Power BI

Unlike SQL joins (which combine tables physically), Power BI relationships connect tables logically.

Types of Relationships

1. One-to-Many (1:M)

One record in Table A → Many in Table B
Example: Customers → Orders

Most common relationship

2. Many-to-Many (M:M)

Many records in both tables
Example: Students ↔ Courses

3. One-to-One (1:1)

One record matches exactly one record
Example: Employee ↔ Employee Details

Cardinality

Defines how tables relate:

One-to-Many
Many-to-One
Many-to-Many

Cross-Filter Direction

Controls how filters flow between tables.

Single direction → One way (recommended)
Both directions → Two-way filtering (use carefully)

Active vs Inactive Relationships

Active relationship → Default used in visuals
Inactive relationship → Exists but is not used unless activated via DAX (USERELATIONSHIP)

Example:

Order Date (Active)
Ship Date (Inactive)

Creating Relationships in Power BI

Method 1: Model View

Go to Model View
Drag one column to another
Relationship is created automatically

Method 2: Manage Relationships

Go to Home → Manage Relationships
Click New
Select:

Tables
Columns
Cardinality
Cross-filter direction
1. Click OK

Joins vs Relationships (Key Difference)

Feature	Joins	Relationships
Where used	Power Query	Data Model
Result	Combines tables	Keeps tables separate
Performance	Can increase size	More efficient
Flexibility	Static	Dynamic

Fact vs Dimension Tables

Fact Table

Contains measurable data (numbers)

Examples:

Sales
Revenue
Quantity

Dimension Table

Contains descriptive attributes

Examples:

Customer Name
Product Category
Date

Example Model

FactSales

OrderID
CustomerID
ProductID
SalesAmount

DimCustomer

CustomerID
Name

DimProduct

ProductID
Category

Data Modeling Schemas

Star Schema

One central fact table
Connected to multiple dimension tables

Snowflake Schema

Dimensions are normalized (split into multiple tables)

Example:

Product → Category → Department

Flat Table (Denormalized / DLAT)

All data in one table

Use Cases

Schema	When to Use
Star	Most Power BI reports
Snowflake	Complex hierarchical data
Flat Table	Small datasets or quick analysis

Role-Playing Dimensions

A role-playing dimension is a table used multiple times for different purposes.

Example: Date Table

Order Date
Ship Date
Delivery Date

In Power BI:

Duplicate the Date table
Create separate relationships

Common Data Modeling Issues

Ambiguous relationships
Happens with multiple paths between tables

Many-to-many confusion
Can lead to incorrect aggregations

Circular relationships
Causes errors

Poor performance
Caused by flat tables or too many joins

Solution:

Use star schema
Avoid unnecessary bi-directional filters
Keep relationships simple

Step-by-Step: Building a Model in Power BI

Step 1: Load Data

Home → Get Data

Step 2: Clean Data (Power Query)

Remove duplicates
Handle nulls
Merge tables if needed

Step 3: Create Relationships

Go to Model View
Drag and connect tables

Step 4: Validate Model

Check cardinality
Ensure no ambiguous paths

Step 5: Optimize

Use star schema
Reduce columns
Avoid many-to-many unless necessary

Conclusion

Data modeling in Power BI is not just technical, it’s strategic. Understanding joins helps you prepare data, while relationships allow you to analyze it efficiently. By structuring your data into fact and dimension tables and choosing the right schema (preferably star), you create a model that is both powerful and scalable.

Mastering these concepts transforms Power BI from a simple visualization tool into a robust analytics engine and ultimately changes how you interpret and interact with data.

I passed 13 AWS certifications. Here's what I actually use at work (and what collects dust).

Vaibhav Kaushik — Sun, 05 Apr 2026 20:20:38 +0000

It was a random Tuesday. No warning, no gradual degradation. RDS just... stopped accepting connections. ECS tasks were crashing in a cascade, CloudWatch alarms were firing, and my Slack was lighting up with "is prod down?" messages from three different people simultaneously.

I didn't open a study guide. I opened CloudWatch Logs, pulled up the VPC flow logs, and started working backwards. Five years of late nights debugging security groups, IAM policies that were almost right, and routing tables that made sense on paper but not in practice that's what I was actually reaching for.

That incident got me thinking: I've spent a significant chunk of my career chasing AWS certifications 13 of them, including Professional and Specialty levels. But which ones actually matter when the pressure is on?

Here's my honest breakdown.

I work as an AWS Solutions Architect at Wipro, designing multi-account architectures, building Terraform modules, and managing CI/CD pipelines for enterprise clients. My day-to-day stack is AWS, Terraform, Kubernetes, Docker, Python, and GitLab CI.

The three that actually changed how I work

Solutions Architect – Professional

This one rewired how I think. Not because of the exam content, but because preparing for it forces you to reason about tradeoffs at scale cost vs performance vs reliability vs operational overhead. I now approach every architecture decision with that mental framework, even when no one asks me to.

DevOps Engineer – Professional

If you work with CI/CD, IaC, or anything that touches deployment pipelines, this cert is the closest to real work. CodePipeline, CloudFormation, Systems Manager, Auto Scaling these come up constantly. Studying for this gave me a structured mental model for a domain I was already working in.

Security – Specialty

Enterprise clients don't trust you until they trust your security posture. This cert gave me the vocabulary and depth to have those conversations confidently SCPs, permission boundaries, GuardDuty findings, encryption at rest vs in transit. In my experience, security knowledge is the #1 differentiator between a junior and senior cloud architect.

The honest truth about certification chasing

Certifications are a map. They are not the territory. The territory is production.

I've met engineers with 2 certs who could debug a broken VPC faster than people with 10. I've also met certified professionals who couldn't explain why their Terraform plan was destroying a resource it shouldn't.

Certs gave me:

A structured way to learn services I wouldn't have touched otherwise
Credibility in client conversations and job applications
A forcing function to fill gaps in my knowledge

What certs didn't give me:

The ability to stay calm at 2am when prod is down
Intuition for when not to use a managed service
Experience debugging a Kubernetes pod that won't start because of a misconfigured IAM role for service accounts

My recommendation if you're starting out

Don't do 13. Do these four, in order:

Cloud Practitioner — only if you're new to cloud entirely
Solutions Architect – Associate — your real starting point
DevOps Engineer – Professional — if you work in infra/platform/DevOps
Security – Specialty — regardless of your role, this pays off

Then go build something. Break it. Fix it. That's the cert that matters most.

I'm a Solutions Architect at Wipro and AWS Community Builder based in London. I write about real-world AWS, Terraform, and cloud architecture. Follow along if that's useful to you.

What cert has been most useful in your day-to-day work? Drop it in the comments.

RDLC Without BC: When the Feedback Loop Is Longer Than the Workday

Stack Collider — Sun, 05 Apr 2026 20:18:29 +0000

RDLC Without BC: When the Feedback Loop Is Longer Than the Workday

csharp #dotnet #businesscentral #rdlc #wpf

Nexus Claude: Every time a developer says "let me check how the report looks" — somewhere in an office, Business Central starts deploying.

Context

Developing RDLC reports for Business Central looks straightforward: edit the .rdlc file in Visual Studio, deploy the extension to BC, run the report, see the result.

The problem is in the word "deploy".

Every change — even nudging a field by two pixels — requires a full cycle: build, deploy, launch BC, navigate to the report, enter parameters. Five minutes at best. Multiply by twenty iterations a day and the workday becomes waiting.

The goal is simple:

Open RDLC and XML data → see the result. No BC. No deploy. Now.

Act One: Dead End in Visual Studio

The first thought — Visual Studio Report Designer has a Preview mode. So you can connect XML as a DataSource and view the report right there.

Create a Report Server Project. Open Designer. Try to add a DataSource — Designer won't allow it. Try connecting XML directly through Connection Properties — and get:

The XmlDP query is invalid.
Unexpected end of file has occurred.
The following elements are not closed: Column, Columns, DataItem, DataItems, ReportDataSet.

Open the .rdlc file manually. Inside — a hard lock:

<DataSources>
  <DataSource Name="DataSource">
    <ConnectionProperties>
      <DataProvider>SQL</DataProvider>
      <ConnectString />
    </ConnectionProperties>
  </DataSource>
</DataSources>

DataProvider=SQL. Can't change it through the UI. Designer won't allow it.

Nexus Claude: Microsoft isn't hiding the solution. Microsoft considers this scenario non-existent.

Official dead end. Moving on.

Act Two: Build It Yourself

If the tool doesn't exist — write it.

The architecture is simple: a WPF application takes two files — .rdlc and .xml with BC data — renders a PDF via ReportViewerCore.NETCore and displays the result through WebView2.

<PackageReference Include="ReportViewerCore.NETCore" Version="*" />
<PackageReference Include="Microsoft.Web.WebView2" Version="*" />

The rendering pipeline is transparent: XML is parsed into a DataTable, DataTable is passed to LocalReport, LocalReport renders PDF into a MemoryStream, WebView2 displays the bytes.

The only non-trivial part — column type inference. BC delivers everything as strings, but LocalReport needs proper types — otherwise numeric fields don't calculate, dates don't sort.

The InferColumnType logic walks through all non-empty values in a column:

int → decimal → DateTime → string

Dates deserve special attention. BC uses the dd/MM/yyyy format. Standard DateTime.TryParse with InvariantCulture won't recognize it. Explicit formats are required:

private static readonly string[] DateFormats =
{
    "dd/MM/yyyy", "dd/MM/yyyy HH:mm:ss",
    "yyyy-MM-dd", "yyyy-MM-ddTHH:mm:ss"
};

DateTime.TryParseExact(value, DateFormats,
    CultureInfo.InvariantCulture,
    DateTimeStyles.None, out _)

Without this, 19/02/2026 silently falls through to string — the report works, but date sorting breaks. Silently.

Nexus Claude: A system that stays quiet when something goes wrong isn't more reliable than one that crashes. It's just harder to diagnose.

Act Three: The Installer Is Its Own Story

A tool for yourself is one thing. A tool for the team requires an installer.

The choice is obvious — Inno Setup. Free, proven, no dependencies.

Problem one: the preprocessor

The first version of the script used #define for variables:

#define AppName "RDLC Report Tester"
#define AppVersion "1.01"

Inno Setup Compiler compiles without errors, but the [Setup] section is empty — values weren't substituted. Cause: file encoding. #define directives aren't read when saved as UTF-8 with BOM in certain configurations.

Fix — remove the preprocessor entirely. Hardcode values directly.

Result: ❌ ~20 minutes

Problem two: DownloadTemporaryFile

The installer needs to check for WebView2 Runtime and download it if missing. First version:

if not DownloadTemporaryFile(Url, FileName, '', @DownloadProgress) then
  // error

Compiler: type mismatch. DownloadTemporaryFile returns Int64 (byte count), not Boolean. On error — it throws an exception. Need try/except, not a return value check.

Result: ❌ ~15 minutes

Problem three: PublishSingleFile

The app was built as PublishSingleFile — one .exe, no dependencies alongside. Logical for distribution.

After installing via the installer, launch from Program Files — silence. Event Viewer says:

System.DllNotFoundException: Dll was not found.
at MS.Internal.WindowsBase.NativeMethodsSetLastError.SetWindowLongPtrWndProc
at MS.Win32.HwndSubclass.SubclassWndProc

PublishSingleFile extracts native DLLs into a temp folder next to the exe at runtime. In Program Files — no write permissions. WPF crashes before the window initializes. Silently.

Fix — disable PublishSingleFile in .csproj. The installer packages the entire publish\ folder into one Setup.exe. The end result is the same — one file to download — but native DLLs sit alongside the exe where they belong.

Result: ❌ ~30 minutes

Problem four: WebView2 and permissions

After the DLL fix the app launches, but crashes again — now with a different error code. WebView2 creates a user data folder next to the exe during initialization. In Program Files — no write permissions again.

// Before: WebView2 creates folder next to exe
await webView.EnsureCoreWebView2Async();

// After: explicit path in AppData
var env = await CoreWebView2Environment.CreateAsync(
    null,
    Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
        "RdlcReportTester", "WebView2"));
await webView.EnsureCoreWebView2Async(env);

Result: ✅

Nexus Claude: Two crashes in a row from the same root cause — no write permissions. Both silent. A good reminder: "installing in Program Files" isn't just a path — it's a contract with Windows about access rights.

Result

BC XML DataSource → RdlcRendererWpf → PDF Preview

Open the app, drag and drop .rdlc and .xml, see the report. No deployments, no BC sessions.

A careful reader will spot StackCollider Latvia SIA in the vendor list. An easter egg. Test data deserves character too.

<PackageReference Include="ReportViewerCore.NETCore" Version="*" />
<PackageReference Include="Microsoft.Web.WebView2" Version="*" />

Full source → github.com/stackcollider/rdlc-report-tester

Nexus Claude: A tool that speeds up development is code too. Sometimes it's more important to write it than the next report.

AI Tools Build Fast. Here Is What They Miss

Quality Bridge Consulting — Sun, 05 Apr 2026 20:13:32 +0000

We are not going to tell you AI development tools are overhyped. They are not. We used them on a real client project and an internal tool, and the speed was everything people claim it is.

What nobody talks about is what happens after the first working version appears on your screen.

That is the part worth writing about.

What We Built
The first project was an internal tracking and project management tool for our own delivery work at QualityBridge Consulting. The kind of thing that would sit in a backlog for months waiting for development time. Using an AI-powered builder, we had a working MVP in one to two weeks. That timeline would have been six to eight weeks through traditional development.

The second was a website prototype for a restaurant client. They needed something functional and modern to put in front of stakeholders before committing to a full build. We delivered a clickable, working prototype in days. The client could react to something real rather than read through a specification document.

Both builds were successful. Both also required more rigour than the tools suggest you need.

Where the Tools Earn Their Reputation
The speed on frontend delivery is real. Clean, modern interfaces built on React and Tailwind CSS that would take a developer several days to produce came together in a fraction of that time.

For prototyping specifically, the value is obvious. Stakeholders give better feedback on something they can interact with. Getting to that stage in days rather than weeks changes the entire dynamic of early project conversations.

For internal tools, the case is just as strong. Teams carry backlogs full of tools they need but cannot justify the development cost to build. AI builders change that calculation.

What the Tools Do Not Tell You
This is the part that matters for anyone considering these tools seriously.

You still need to test properly. AI-generated code looks right. In controlled conditions it usually works right. But real users do not use software in controlled conditions. They enter unexpected inputs, navigate in unexpected sequences, and find the edge cases that a visual check will never catch. On both our builds, structured testing found issues before they reached anyone outside our team.

Code review is not optional. These tools generate code fast, but they do not always generate it consistently across a longer build. We found instances where iterating on a feature caused the AI to introduce changes that conflicted with earlier decisions. Without someone reviewing what was being generated at each step, those conflicts accumulate quietly until they become a real problem.

Change tracking requires deliberate effort. Traditional development has version control and pull request reviews built into the process. AI-assisted development moves fast enough that it is easy to lose track of what changed, when, and why. On our internal tool, keeping a clear log of every prompt, every iteration, and every decision was not a nice-to-have. It was the difference between a product we could maintain and a prototype nobody could safely modify.

The Broader Point
AI development tools lower the barrier to building. That is a good thing for lean teams and scaling businesses who cannot justify a full engineering team for every internal tool or early-stage product.
But there is a difference between lowering the barrier to building and lowering the standard of what gets shipped.

The teams that get the most from these tools treat them as a fast starting point, not a finished product. They use the speed to move quickly through early iterations, then apply proper quality practices before anything reaches real users or real data.

Thorough testing. Code review. Tracked changes. Clear acceptance criteria before anything is called done.

The tools have changed how fast a build can start. They have not changed what done actually means.

Our Honest Take
We will keep using these tools. The speed advantage on prototypes and internal builds is too useful to set aside, and the output quality continues to improve with each passing month.

But every build we do with AI assistance gets the same quality treatment as every other build. The same testing standards. The same review process. The same expectation that what ships works correctly and can be maintained by the team inheriting it.

If you are exploring AI-assisted development for your business, the question is not whether the tools are good. They are. The question is whether your delivery process is ready to work alongside them properly.
Most are not. That is where the real work is.

QualityBridge Consulting helps SMEs and scaling teams deliver digital products with structure, transparency, and no surprises. If you are building with AI tools and want to make sure what ships is actually production-ready, we would be glad to talk.

Parsing LLM Responses in DataWeave: 3 Layers of Defense Against Markdown Fences

ThaSha — Sun, 05 Apr 2026 20:12:23 +0000

I connected MuleSoft to GPT-4o last quarter for a support ticket classifier. The prompt builder worked (I covered that in a previous post). The LLM call worked. Then the response came back and my parser crashed.

The LLM was supposed to return clean JSON. Instead it returned: "Here is my analysis:\n

json\n{\"ranking\": [\"TK-101\"]}\n

\nLet me know if you need anything else."

Markdown fences. Preamble text. Trailing conversation. My read() call choked on "Here is my analysis" — not valid JSON.

TL;DR

LLMs wrap JSON responses in markdown fences — your parser must extract the JSON first
try() from dw::Runtime catches parse failures gracefully — without it, one malformed response crashes your flow
Always validate required keys after parsing — LLMs hallucinate extra fields and omit required ones
The regex for fence extraction: raw match /(?s)(?:json)?\s*(\{.*?\})\s*/
Test with 5 response variants: clean JSON, fenced JSON, fenced without language tag, no fences, broken JSON

The Problem: LLMs Don't Return Clean JSON

You ask GPT-4o to return JSON. Sometimes it does:

{"ranking": ["TK-101", "TK-098"], "summary": "Timeout is critical."}

But often it adds commentary:

Here is my analysis:

json
{"ranking": ["TK-101"], "summary": "Timeout is critical."}

Let me know if you need anything else.

plaintext

That's not valid JSON. read(raw, "application/json") throws. Your Mule flow crashes. 50,000 LLM responses per day = 50,000 potential crashes.

The Solution: 3-Layer Defense in DataWeave

%dw 2.0
import try from dw::Runtime
output application/json
var raw = payload.rawResponse
var fenceMatch = raw match /(?s)```

(?:json)?\s*(\{.*?\})\s*

```/
var jsonStr = if (fenceMatch[1]?) fenceMatch[1] else raw
var parsed = try(() -> read(jsonStr, "application/json"))
var keys = if (parsed.success) (parsed.result pluck $$) else []
var missing = payload.requiredKeys filter (k) -> !(keys contains k)
---
{
  parsed: if (parsed.success) parsed.result else null,
  valid: parsed.success and isEmpty(missing),
  missingKeys: missing
}

100 production-ready DataWeave patterns with tests: mulesoft-cookbook on GitHub

Layer 1: Regex Fence Extraction

var fenceMatch = raw match /(?s)```

(?:json)?\s*(\{.*?\})\s*

```/
var jsonStr = if (fenceMatch[1]?) fenceMatch[1] else raw

The regex matches content between markdown fences. (?s) enables dotall mode so . matches newlines. (?:json)? handles both

`json` and bare

``. The captured group({.*?})` extracts just the JSON object.

If no fences found (fenceMatch[1]? is false), fall back to parsing the raw string directly. This handles the case where the LLM returns clean JSON without fences.

Layer 2: try() Wraps the Parse


dataweave
var parsed = try(() -> read(jsonStr, "application/json"))

try() from dw::Runtime is the critical piece. Without it, read() on invalid JSON throws an exception and crashes the flow. With try(), you get:

Success: {success: true, result: {...parsed object...}}
Failure: {success: false, error: {...error details...}}

Your flow continues either way. Log the error, route to a dead-letter queue, retry with a different prompt — your choice. But the flow never crashes.

The trap: If you don't check parsed.success before accessing parsed.result, you get null on failure. Downstream code that expects an object gets null instead. Always check the success flag.

Layer 3: Required Key Validation


dataweave
var keys = if (parsed.success) (parsed.result pluck $$) else []
var missing = payload.requiredKeys filter (k) -> !(keys contains k)

LLMs hallucinate. You asked for ranking and summary. The LLM returned ranking, analysis, and confidence — but not summary. The JSON is valid but missing a required field.

pluck $$ extracts all keys from the parsed object. filter checks each required key against the actual keys. missing tells you exactly which keys the LLM omitted.

The 5 Response Variants to Test

I test every LLM parser against these variants:

Variant	Example	What Breaks
Clean JSON	`{"ranking": [...], "summary": "..."}`	Nothing — baseline
Fenced with language	```

json\n{...}\n

| `read()` without fence extraction | | Fenced without language |

\n{...}\n

``| Regex that requiresjsonafter fence | | No fences, with preamble |Here is my analysis: {"ranking": [...]}| Naiveread()on full string | | Broken JSON |{"ranking": ["TK-101"(truncated) | Any parser withouttry()` |

I hit all 5 in production within the first week. The same model, same prompt, same temperature — 5 different formats across 50,000 responses.

Trap: The Regex Doesn't Handle Nested Objects Well

The regex \{.*?\} uses non-greedy matching. It works for flat JSON objects. But if your LLM returns nested objects:


json
{"analyses": [{"ticketId": "TK-101", "action": "increase pool"}], "summary": "..."}

The non-greedy .*? stops at the first } — inside the nested array. You get a partial JSON parse.

For production, I switched to finding the matching closing brace by counting open/close braces, not regex. But the regex works for 90% of LLM responses where the top-level structure is flat.

Performance

The parser handles 50,000 LLM responses per day. Average parse time: 2ms per response. The regex is the slowest part — try() and read() are fast because they're native DataWeave functions.

Zero flow crashes since deploying the 3-layer approach. Before it, we had 3-5 crashes per day from malformed LLM responses.

What I Do Now

Every LLM integration gets this parser as the first step after the API call
Failed parses go to a dead-letter queue with the raw response for debugging
Missing key reports go to a monitoring dashboard — tracks LLM reliability over time
I test with all 5 variants before any production deployment

100 patterns with MUnit tests: github.com/shakarbisetty/mulesoft-cookbook

60-second video walkthroughs: youtube.com/@SanThaParv

🚀Playwright vs Selenium in 2026: The Ultimate Guide for Modern Test Automation

Ankit Aloni — Sun, 05 Apr 2026 20:11:17 +0000

⚡ Why This Decision Matters More Than You Think

Most engineers don’t struggle with writing tests.

They struggle with trusting them.

❌ Test passes locally → fails in CI

❌ Pipeline fails → rerun → magically passes

❌ Thread.sleep() becomes your best friend

That’s not bad luck.

👉 That’s a tooling mismatch.

In 2026, choosing between Playwright vs Selenium is not just technical.

It’s a decision about:

⚡ Speed
🧠 Reliability
🏗️ Engineering culture

🧭 Two Generations of Testing Philosophy

🧱 Selenium: The Foundation

Born in 2004
W3C WebDriver standard
Enterprise adoption

Built for:

Server-rendered apps
Predictable DOM
Simpler JS

⚡ Playwright: The Modern Approach

Built for:

SPA apps
Async-heavy UI
Dynamic DOM

Key idea:

“Don’t just act on the DOM — understand its state.”

⚡ Core Difference (This Changes Everything)

Selenium	Playwright
Command-based	State-aware
External control	Internal awareness
Manual waits	Auto sync

👉 This is why Playwright feels faster, cleaner, and more reliable.

⚙️ Architecture (Where Tests Actually Break)

Selenium

[Test] → HTTP → WebDriver → Browser

Every action = network call
Slower
More fragile

WebElement btn = driver.findElement(By.id("submit"));
btn.click();

Playwright

[Test] → WebSocket/CDP → Browser

Persistent connection
Event-driven
Faster

await page.locator('#submit').click();

🔍 Why This Matters in Real Life

❌ Selenium Approach

Thread.sleep(2000);

✅ Playwright Approach

await page.locator('#submit').click();

Playwright automatically waits for:

✔️ Visibility
✔️ Stability
✔️ Interactivity

💡 Pro Tip:

If your tests need retries to pass, your architecture is broken.

🧑‍💻 Developer Experience (DX)

⚡ Setup

Playwright → Ready in minutes
Selenium → Setup heavy

🧪 Assertions

// Playwright
await expect(page.locator('.alert')).toHaveText('Success');

// Selenium
WebElement alert = driver.findElement(By.className("alert"));
assertEquals("Success", alert.getText());

👉 Playwright = cleaner + smarter assertions

⏳ Wait Handling

Selenium	Playwright
Explicit waits	Built-in waits
Manual logic	Smart defaults

🐞 Debugging

Playwright

Trace viewer
Video
Network logs

Selenium

Logs
Screenshots

📊 Feature Comparison

Feature	Playwright	Selenium
Auto-waiting	✅ Smart	❌ Manual
Parallel execution	✅ Built-in	⚠️ Grid
Network mocking	✅ Native	❌ Limited
Shadow DOM	✅ Easy	⚠️ Complex
Visual testing	✅ Built-in	❌ External

🔬 Performance Reality

Metric	Playwright	Selenium
Speed	⚡ Fast	🐢 Slower
Flakiness	Low (~3%)	Higher (~15%)
Maintenance	Low	Medium–High

🚀 CI/CD Simplicity

Playwright

- run: npm ci
- run: npx playwright install
- run: npx playwright test

Selenium

services:
  selenium:
    image: selenium/standalone-chrome
- run: mvn test

👉 More infra = more problems

🐞 Debugging Difference

npx playwright test --trace on

👉 Replay entire test (DOM + network + screenshots)

🔁 Real Code Comparison

Playwright

await page.goto('/login');
await page.fill('#user', 'admin');
await page.fill('#pass', '1234');
await page.click('#login');
await expect(page).toHaveURL('/dashboard');

Selenium

driver.get("/login");
driver.findElement(By.id("user")).sendKeys("admin");
driver.findElement(By.id("pass")).sendKeys("1234");
driver.findElement(By.id("login")).click();

new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.urlContains("/dashboard"));

🎯 When to Use What

✅ Choose Playwright if:

New project
Need speed + stability
CI-first setup

✅ Choose Selenium if:

Large existing suite
Java ecosystem
Migration cost is high

🧠 Decision Flow

New project?
 ├── Yes → Playwright
 └── No
      ├── Existing Selenium?
      │     ├── Yes → Stay / gradual migration
      │     └── No → Playwright

🏁 Final Verdict

🚀 Playwright → Modern, fast, reliable
🧱 Selenium → Stable, enterprise-ready

👉 No universal winner — only the right context.

🚀 What You Should Do Today

Install Playwright
Convert 2–3 tests
Compare:
- Speed
- Stability
- Debugging

💬 Final Thought

A test suite is not valuable because it exists.

It’s valuable because you trust it.

If you don’t trust your tests…

you don’t have automation.

You have noise.

Vibe Coding Forem

VoiceScribe

VoiceScribe

RealTime Speech To Text App Built with Google AI Studio

What it does

How it works

How I built it

Useful for education

My experience with Google AI Studio

Try it

AI helps me code faster, but not always understand better

Chaining MCP Tools: Build AI Workflows That Search, Read, Analyze, and Write

What is MCP Tool Chaining?

Example Workflow 1: Code Analysis and Issue Creation

Example Workflow 2: Data-Driven Reporting

NeuroLink: Orchestrating the AI Nervous System

Code Examples with NeuroLink API

Debugging Tool Chains

Performance: ToolCache and RequestBatcher for Optimization

Conclusion

I built a faster alternative to cp and rsync — here's how it works

The core idea

Deduplication

SSH tar streaming

Real benchmarks

Getting started

Links

Chaining MCP Tools: Search Read Analyze Write in TypeScript

Chaining MCP Tools: Search → Read → Analyze → Write in TypeScript

The Anatomy of a Tool Chain

Understanding the Chain

Building Intelligent Routers

Human-in-the-Loop for Critical Actions

Real-World Example: Documentation Sync Agent

Best Practices for Tool Chaining

Conclusion

The Service Layer: Where Separate Components Become a System

What Does the Service Layer Actually Do?

The Interface That Keeps Everything Clean

What Happens When Embedding Fails?

Search — The Pipeline That Ties Everything Together

Why JPA Isn’t Enough for Vector Search

Updating a Document means Updating Its Embedding Too

One Place for All Your Errors

How the LifecycleKeeps Bad Data Out of Search

The System Now Works

What's Next

Understanding Data Modelling in Power BI: Joins, Relationships, and Schemas Explained

What is Data Modelling?

SQL Joins Explained (With Examples)

INNER JOIN

LEFT JOIN

RIGHT JOIN

FULL OUTER JOIN

LEFT ANTI JOIN

RIGHT ANTI JOIN

Joins in Power BI (Power Query)

Steps:

Relationships in Power BI

Types of Relationships

1. One-to-Many (1:M)

2. Many-to-Many (M:M)

3. One-to-One (1:1)

Cardinality

Cross-Filter Direction

Active vs Inactive Relationships

Creating Relationships in Power BI

Method 1: Model View

Method 2: Manage Relationships

Joins vs Relationships (Key Difference)

Fact vs Dimension Tables

Fact Table

Dimension Table

Example Model

Data Modeling Schemas

Star Schema

Snowflake Schema

Flat Table (Denormalized / DLAT)

Use Cases

Role-Playing Dimensions