Design Community

Big Tech firms are accelerating AI investments and integration, while regulators and companies focus on safety and responsible adoption.

Stelixx Insights — Sun, 05 Apr 2026 21:00:48 +0000

The AI landscape is experiencing unprecedented growth and transformation. This post delves into the key developments shaping the future of artificial intelligence, from massive industry investments to critical safety considerations and integration into core development processes.

Key Areas Explored:

Record-Breaking Investments: Major tech firms are committing billions to AI infrastructure, signaling a significant acceleration in the field.
AI in Software Development: We examine how companies are leveraging AI for code generation and the implications for engineering workflows.
Safety and Responsibility: The increasing focus on ethical AI development and protecting vulnerable users, particularly minors.
Market Dynamics: How AI is influencing stock performance, cloud computing strategies, and global market trends.
Global AI Strategies: Companies are adapting AI development for specific regional markets.

This deep dive aims to provide developers, tech leaders, and enthusiasts with a comprehensive overview of the current state and future trajectory of AI.

AI #ArtificialIntelligence #TechTrends #SoftwareEngineering #MachineLearning #CloudComputing #FutureOfTech #AISafety

Accelerating TURN with eBPF: A Non-Invasive Approach

Ivan M — Sun, 05 Apr 2026 21:00:11 +0000

There is much to be said for the merits of eBPF when it comes to the common problems of network filtering, and one cannot help but observe the swift evolution of this splendid technology. However, one must admit that certain undertakings remain decidedly more tiresome than others. While dropping packets comes across as a rather straightforward affair, the pursuit of accelerating a stateful, high-performance userspace relay server presents a most formidable set of challenges.

Notably, TURN (RFC 8656: Traversal Using Relays around NAT) serves as a proverbial specimen of burning CPU cycles owing to an eye-watering amount of kernel-to-user mode switches and vice versa, yet offloading the channel traffic to the eBPF layer demands a most substantial and, one might say, exhaustive quantity of logic to conduct packet processing with surgical precision.

The proposition to accelerate TURN using an eBPF bypass scheme has been mooted for a considerable duration. Notably, there have been feature requests (like this one in the coturn project) and solutions, like the exemplary work of Tamás Lévai et al., entitled "Supercharge WebRTC: Accelerate TURN Services with eBPF/XDP". Although such remediations are thoughtfully designed to handle the protocol with utmost care, they require substantial assistance from the server to do their job. While this approach is certainly commendable, I take a rather different view on what the more beneficial arrangement might be.

When it comes to unencrypted TURN traffic, one may construct a stateful eBPF component that is fully protocol-aware but learns about new TURN channel bindings by "snooping", ensuring the userspace server stands unmodified and blissfully unaware of the offload. In this post, I should like to present a humble prototype of this very approach, an open-source project that is named TURN-BPF.

ivanmtech / turn-bpf

RFC 8656 channel accelerator

TURN-BPF: research into eBPF offloads of RFC 8656 channels

TURN-BPF is a personal development effort aiming to reckon the feasibility
of using XDP programs to bypass the userspace for the TURN channel traffic
without the need to tamper with the code of the TURN implementation itself.

These programs conduct NAT (client <> TURN | relay <> peer), strip/add the
TURN channel tag, update the checksums, rewrite the MAC addresses and send
the resulting packets onto the wire via interfaces chosen based on the FIB.

The tool requires no configuration from the user, except for the interface
name(s) and is supposed to snoop on relay allocations and channel bindings
by capturing the said control packet handshakes at the XDP/TC hooks on the
main network interface. For the sake of keeping the channels active in the
userspace TURN server, the tool employs a 'heartbeat' approach, spilling a
small fraction of data packets

…

View on GitHub

        [ CLIENTS ]                                 [ PEERS ]
          |     |                                       |
   (STUN) |     | (Tagged Data)                  (Untagged Data)
          |     |                                       |
 +--------+-----+--------+                     +--------+--------+
 | Interface for Clients |                     | Relay Interface |
 +--------+-----+--------+                     +--------+--------+
          |     |                                       |
          |     +-----+                                 |
          |           |                                 |
 =========|===========|=================================|=========
 KERNEL   |           |                                 |
          |           |                                 |
 +--------+--------+  |   +-------------------------+   |
 | XDP/TC Snoopers |  +--<|> XDP cli2rem / rem2cli <|>--+
 +--------+--------+      +---+---------------------+   |
   (Maps) |                   |   (Fast Path)           |
          |                   |                         ^
          |           (Heartbeat Spill)                 |
          |                   |                         |
 =========|===================|=========================|=========
 USERLAND |                   |                         |
          |                   +---->+-------------+-->--+
          |                         | TURN Server |
          +------------------------<+>------------+

Architecture: The Snooping Approach

The structural underpinnings of the arrangement include a set of XDP and TC (Traffic Control) programs written in C, some of which snoop on control packets to commit the channels for an offload, while others conduct the offload per se. Depending on the configuration (a single network interface acting as both the client endpoint and the relay versus a separate client-facing interface and one or multiple relays), the eBPF component provides either a separate XDP rem2cli program or a combined XDP section with cli2rem, rem2cli, and the STUN snooper baked in.

One might inquire why the tool employs a TC hook for snooping on the server's responses rather than keeping everything within the XDP layer. The reasoning is as follows: while XDP is unparalleled for raw speed on ingress, the TC egress hook on the client-facing interface allows one to observe the packets after they have been processed by the userspace stack and the kernel's networking subsystem. At this stage, the ChannelBind success response is fully formed and ready to depart. By intercepting it here, one can ensure that a channel is only committed to the fast path once the server has officially sanctioned the allocation.

Under the Hood: FIB Lookups & Heartbeats

Indubitably, the implementation possesses considerably more depth than might initially meet the eye. In particular, the knowledge of which IP addresses map to which MAC addresses and, more crucially, network interfaces, comes from the FIB lookup. The lookup is performed in the control path (in the snoopers), when the channel binding is committed, and relies upon a remarkably helpful and powerful building block from the kernel, the bpf_fib_lookup function.

Furthermore, to ensure the longevity of the session within the userspace daemon, the tool employs a "heartbeat spill" mechanism. By deliberately passing a minute fraction of the data packets up the network stack, we allow the TURN server to perceive the channel as active, thereby preventing the premature expiration of the allocation while the bulk of the throughput enjoys the celerity of the eBPF fast path. Regrettably, there are certain limitations, too. The project, which is merely a proof-of-concept, does not handle encrypted channels and can only support IPv4 traffic.

The tool comes with a loader program written in Rust, which blocks waiting for the Ctrl+C keystroke upon successful activation of the kernel component. This part is a hodgepodge of foundational knowledge from the textbook I have been reading, some AI advice, and my occupational hazards from the ten years of experience in C programming; therefore, one should take the code quality with a grain of salt.

Deployment & Verification

On Debian 13 (kernel 6.12), one may run the tool as follows (which should be done in a separate terminal on the server machine, prior to the launch of TURN):

sudo apt update
sudo apt install --yes cargo clang git libelf-dev pkg-config
git clone https://github.com/ivanmtech/turn-bpf
cd turn-bpf
cargo build
sudo ./target/debug/turn-bpf <main_ifname> [relay_ifnames...]

My poor man's test rig consisted of a pair of laptops connected via a commodity 100 Megabit/s USB Ethernet link. The server-side coturn configuration was:

listening-port=3478
listening-ip=192.168.47.1
relay-ip=192.168.47.1
user=user:password
realm=turn.test

These are my configuration steps on the server-side laptop:

sudo apt update
sudo apt install --yes coturn
sudo service coturn stop
sudo nmcli device set enx0 managed no
sudo ip addr add 192.168.47.1/24 dev enx0
sudo ip link set enx0 up

For the client-side laptop:

sudo nmcli device set enx0 managed no
sudo ip addr add 192.168.47.2/24 dev enx0
sudo ip link set enx0 up

Running coturn on the server-side laptop is as simple as:

sudo turnserver -c ~/test.cfg

While the client-side laptop acts both as a client and a remote peer:

turnutils_peer -L 192.168.47.2
turnutils_uclient -u user password \
 -w p -e 192.168.47.2 -n 100000 -m 50 -g 192.168.47.1

Performance Results

In my case, running pidstat for coturn indicates CPU usage at a negligible level, virtually 0%, which jumps swiftly to 20% when Ctrl+C is pressed in the TURN-BPF terminal. System-wide CPU usage is 0-1% when the offload is active, versus 6-7% in its absence. Again, my test rig was lacking in many ways, so the results presented might not necessarily meet production-grade expectations.

As I continue to explore the frontiers of high-performance networking, I should like to remain open to communication with peers and would be delighted to converse about any other architectural and system design challenges of the modern age.

How to Set Up Qodo AI in VS Code: Installation Guide

Rahul Singh — Sun, 05 Apr 2026 21:00:00 +0000

Why set up Qodo in VS Code

Getting AI-powered code review and test generation directly in your editor eliminates context switching and catches issues before code ever reaches a pull request. Most developers spend their day inside VS Code, and adding Qodo to that workflow means you can generate unit tests, get code suggestions, and review your own code without opening a browser or waiting for a CI pipeline to run.

Qodo - formerly known as CodiumAI - is an AI code quality platform that combines test generation with code review. While many teams know Qodo for its PR review capabilities, the VS Code extension brings those same AI capabilities into your local development environment. You can generate comprehensive unit tests for any function with a single command, get real-time code suggestions, and chat with an AI assistant that understands your codebase context.

The VS Code extension is the fastest way to start using Qodo. Installation takes under five minutes, the free Developer plan gives you 250 credits per month at no cost, and you do not need to configure any CI/CD pipelines or Git integrations to start generating tests and reviewing code locally.

This guide walks through every step - from installing the extension to generating your first tests to configuring advanced settings for your workflow.

Prerequisites

Before you begin, confirm you have the following ready:

Visual Studio Code version 1.80 or later installed on your machine (macOS, Windows, or Linux)
An active internet connection for the initial installation and for AI-powered features that rely on cloud-hosted models
A GitHub, Google, or email account for signing in to Qodo (no enterprise subscription required)
A project with source code open in VS Code to test Qodo's features after installation

No API keys, Docker installations, or terminal commands are needed. The entire setup happens within VS Code's graphical interface. If you have used the older CodiumAI extension before, the rebrand to Qodo means you should update to the latest Qodo-branded extension for continued support and new features.

Step 1 - Install the Qodo extension

The Qodo extension is available directly from the VS Code Marketplace. Here is how to find and install it:

Open VS Code
Press Ctrl+Shift+X on Windows/Linux or Cmd+Shift+X on macOS to open the Extensions view
Type "Qodo" in the search bar at the top of the Extensions panel
Locate the extension published by Qodo (you may also see it listed with the subtitle "formerly CodiumAI")
Click the Install button

The installation is typically complete within 10 to 20 seconds depending on your connection speed. After installation, you will see the Qodo icon appear in the Activity Bar on the left side of VS Code. This icon opens the Qodo panel where you interact with all of the extension's features.

If you previously had the CodiumAI extension installed, VS Code may have already migrated it to the Qodo-branded version through an automatic update. Check your installed extensions list to verify you are running the latest version. If you see both a CodiumAI and a Qodo extension, uninstall the CodiumAI one and keep the Qodo extension.

You can also install the extension from the command line:

code --install-extension Qodo.qodo-vscode

Step 2 - Sign in to your Qodo account

After installation, you need to sign in to activate the extension. Qodo requires authentication to manage your credits and connect your activity to your account.

Click the Qodo icon in the Activity Bar on the left side of VS Code
The Qodo panel opens with a sign-in prompt
Click Sign In and choose your preferred authentication method:
- GitHub - recommended if you plan to use Qodo's PR review features later
- Google - quick sign-in with your Google account
- Email - create a standalone Qodo account with any email address
A browser window opens for authentication - complete the sign-in process
Return to VS Code where the Qodo panel now shows your account information and remaining credits

The free Developer plan activates automatically when you create an account. You get 250 credits per calendar month for IDE and CLI interactions, plus 30 PR reviews per month if you later connect Qodo to your Git repositories. No credit card is required.

After signing in, the Qodo panel displays your current credit balance, the AI model in use, and quick access to the extension's main features: test generation, code chat, and code review.

Step 3 - Generate your first tests

Test generation is Qodo's signature feature and the best way to verify that the extension is working correctly. Here is how to generate your first batch of unit tests:

Open any source file in your project that contains at least one function or method
Place your cursor inside a function you want to test, or select the entire function
Open the Qodo chat panel and type /test, or right-click in the editor and select the Qodo test generation option from the context menu
Qodo analyzes the function's behavior, input types, conditional branches, and error paths
Within a few seconds, Qodo generates a complete set of unit tests

The generated tests include coverage for multiple scenarios:

Happy path - the function works as expected with valid inputs
Edge cases - null values, empty strings, boundary numbers, and empty arrays
Error scenarios - invalid inputs, missing parameters, and exception handling
Type variations - different input types that the function might receive

Qodo detects your project's existing testing framework and generates tests accordingly. If your project uses pytest, you get pytest-style tests. If it uses Jest, you get Jest tests. Supported frameworks include pytest, unittest, Jest, Vitest, Mocha, JUnit 4, JUnit 5, Go's testing package, NUnit, xUnit, and RSpec.

Here is an example of what Qodo might generate for a simple utility function:

# Your source code
def calculate_discount(price, percentage):
    if price < 0:
        raise ValueError("Price cannot be negative")
    if percentage < 0 or percentage > 100:
        raise ValueError("Percentage must be between 0 and 100")
    return price * (1 - percentage / 100)

# Qodo-generated tests

from your_module import calculate_discount

def test_calculate_discount_standard():
    assert calculate_discount(100, 10) == 90.0

def test_calculate_discount_zero_percentage():
    assert calculate_discount(100, 0) == 100.0

def test_calculate_discount_full_percentage():
    assert calculate_discount(100, 100) == 0.0

def test_calculate_discount_negative_price():
    with pytest.raises(ValueError, match="Price cannot be negative"):
        calculate_discount(-10, 10)

def test_calculate_discount_percentage_over_100():
    with pytest.raises(ValueError, match="Percentage must be between 0 and 100"):
        calculate_discount(100, 110)

def test_calculate_discount_negative_percentage():
    with pytest.raises(ValueError, match="Percentage must be between 0 and 100"):
        calculate_discount(100, -5)

Each test generation request consumes 1 credit from your monthly balance. With 250 free credits per month, you can generate tests for roughly 250 functions before needing a paid plan. For more details on how Qodo approaches test generation across different languages and frameworks, see our deep dive on Qodo test generation.

Step 4 - Explore code suggestions

Beyond test generation, Qodo provides an interactive chat interface for code review, explanation, and refactoring. The chat panel in the Qodo sidebar lets you ask questions about your code and get AI-powered responses.

Here are the key commands you can use in the Qodo chat panel:

/test - generate unit tests for the selected function
/review - get a code review of the selected code with suggestions for improvements
/explain - get a detailed explanation of what the selected code does
/improve - get refactoring suggestions for the selected code
/docstring - generate documentation for the selected function

To use any command, select the code you want to analyze in the editor and then type the command in the Qodo chat panel. You can also ask free-form questions about your code by typing natural language queries directly into the chat.

The /review command is particularly useful for self-review before opening a pull request. It analyzes your code for potential bugs, security issues, performance anti-patterns, and readability improvements - similar to what Qodo's PR review does on pull requests, but available locally before you push your code.

Each chat interaction consumes credits based on the AI model you are using. Standard models consume 1 credit per request, while premium models like Claude Opus consume 5 credits per request.

Step 5 - Configure settings

Customizing Qodo's settings lets you tailor the extension to your workflow and preferences. Open VS Code Settings with Ctrl+, (or Cmd+, on macOS) and search for "Qodo" to see all available configuration options.

Key settings to configure

Default AI model - Choose the AI model that powers Qodo's responses. Options include GPT-4o (balanced speed and quality), Claude 3.5 Sonnet (strong reasoning), and DeepSeek-R1. Premium models provide higher-quality output but consume more credits per request. Start with the default model and switch to a premium model only when you need deeper analysis.

Test generation preferences - Configure how Qodo generates tests, including the target testing framework, test file naming conventions, and whether to include docstrings in generated tests. If Qodo is not detecting your testing framework correctly, you can set it explicitly in the settings.

Local LLM support - If your organization requires that code never leaves your machine, enable Local LLM mode through Ollama. This routes all AI processing through a locally hosted model instead of Qodo's cloud API. Set this up by installing Ollama on your machine, downloading a supported model, and pointing Qodo to your local Ollama endpoint in the extension settings.

Telemetry - Control whether the extension sends usage data to Qodo. You can disable telemetry entirely from the settings panel if your organization's policies require it.

Keyboard shortcuts

Set up keyboard shortcuts for the commands you use most frequently. Open the Keyboard Shortcuts editor with Ctrl+K Ctrl+S (or Cmd+K Cmd+S on macOS) and search for "Qodo" to see all available commands. Common shortcuts to configure:

Generate tests for the selected function
Open the Qodo chat panel
Run a code review on the current file

Tips for getting the most out of Qodo in VS Code

Follow these practices to maximize the quality of Qodo's output.

Write clear function signatures. Qodo produces better tests and suggestions when it can understand your function's input types and return values. Use type hints in Python, TypeScript annotations, or JSDoc comments in JavaScript. A function with def process_order(order: Order, discount: float) -> Receipt gives Qodo far more context than def process_order(order, discount).

Keep functions focused. Functions that do one thing well receive higher-quality test generation than monolithic functions with multiple responsibilities. If Qodo's generated tests seem shallow or miss important scenarios, consider breaking the function into smaller, more testable units.

Review generated tests before committing. Qodo's tests are a strong starting point, but they are not a substitute for human judgment. Review each generated test for correctness, especially around mocking complex dependencies, domain-specific assertions, and integration with external services. Treat generated tests as a draft that saves you 20 to 30 minutes of setup work per function.

Use the /review command before opening PRs. Running a local code review catches issues that you can fix immediately, reducing the back-and-forth in pull request reviews. This is especially valuable for catching security issues, missing error handling, and logic errors before they reach your team's review queue.

Switch models based on the task. Use the standard model for quick test generation and simple questions. Switch to a premium model when you need deeper analysis of complex business logic or want more thorough code review feedback.

Troubleshooting

If you encounter issues with the Qodo extension, work through these common problems.

Extension not appearing after installation. Restart VS Code after installing the extension. If the Qodo icon still does not appear in the Activity Bar, check that the extension is enabled in the Extensions view. Some organizations use VS Code policies that restrict extension installations - check with your IT team if the extension appears grayed out or disabled.

Sign-in failing or timing out. Ensure your browser is not blocking popups from Qodo's authentication service. Try signing in with a different authentication method (GitHub instead of Google, or vice versa). If you are behind a corporate proxy or VPN, the proxy may be blocking requests to Qodo's API endpoints - check with your network administrator.

No credits remaining. The free Developer plan provides 250 credits per month, and credits reset every 30 days from the first message you sent, not on a calendar schedule. Check your remaining balance in the Qodo panel. If you consistently run out of credits, the Teams plan at $30/user/month provides 2,500 credits per user per month. See our full Qodo pricing breakdown for a detailed comparison of all plan tiers and what each includes.

Test generation producing low-quality output. Ensure you are selecting a complete function rather than a partial code block. Add type annotations and docstrings to give Qodo more context. Try a premium AI model for more thorough test generation. For complex functions with deep dependency chains, you may need to refine the generated tests manually.

Extension consuming too many resources. If VS Code feels sluggish after installing Qodo, check the extension's memory usage in the VS Code Process Explorer (Help then Process Explorer). Disable features you do not use, such as inline suggestions, to reduce resource consumption. Updating to the latest extension version often resolves performance issues.

Conflict with other extensions. Qodo generally works well alongside other AI extensions including GitHub Copilot. If you experience conflicts, try disabling other AI extensions temporarily to isolate the issue. Qodo and Copilot serve different purposes and should not conflict - Copilot handles inline completions while Qodo handles test generation and code review.

Alternatives to Qodo for VS Code

If Qodo does not fit your workflow, several alternatives provide AI-powered capabilities in VS Code.

CodeAnt AI ($24-40/user/month) combines AI code review with SAST security scanning, secret detection, and DORA metrics in a single platform. It supports 30+ languages and all four major Git platforms. CodeAnt AI focuses on code health at the organizational level rather than individual IDE interactions, making it a strong choice for teams that want PR review, security scanning, and engineering metrics bundled together. See our full Qodo alternatives comparison for a broader landscape.

GitHub Copilot ($10-39/user/month) is the most widely adopted AI coding assistant. It excels at inline code completions and has a chat interface for code explanations and generation. Copilot's test generation is less specialized than Qodo's but covers a wider range of coding tasks. Many developers use both Copilot and Qodo side by side.

Tabnine ($9/user/month and up) offers AI code completions with a strong focus on privacy and self-hosted deployment. It is a good alternative for teams that need code completion without sending code to external servers but does not offer Qodo's depth of test generation.

Sourcery ($10/user/month and up) specializes in Python code quality with automated refactoring suggestions. It is more limited in language support than Qodo but provides highly targeted feedback for Python teams.

For a comprehensive comparison of all available options, see our full guide to Qodo alternatives.

Conclusion

Setting up Qodo in VS Code takes less than five minutes and immediately gives you access to AI-powered test generation and code review inside your editor. The free Developer plan with 250 monthly credits is enough for most individual developers to evaluate whether Qodo's approach to test generation fits their workflow.

The key steps are straightforward: install the extension from the marketplace, sign in with GitHub, Google, or email, and start generating tests with the /test command. From there, explore the /review and /improve commands for code quality feedback, configure your preferred AI model, and set up keyboard shortcuts for the commands you use most.

For teams that want to extend Qodo beyond the IDE into pull request workflows, the natural next step is connecting Qodo to your Git repositories for automated PR review. Our guides on Qodo PR review and Qodo test generation cover those workflows in detail. If you are curious about how Qodo's pricing compares to other tools in the market, our Qodo alternatives breakdown provides current pricing and feature comparisons across ten competing platforms.

Frequently Asked Questions

How do I install Qodo AI in VS Code?

Open VS Code and press Ctrl+Shift+X (or Cmd+Shift+X on macOS) to open the Extensions view. Search for 'Qodo' in the marketplace search bar. Click Install on the Qodo extension published by Qodo (formerly CodiumAI). After installation, the Qodo icon appears in the Activity Bar on the left side of VS Code. Click it to open the Qodo panel and sign in to start using AI-powered code review and test generation.

Is the Qodo VS Code extension free?

Yes. The Qodo VS Code extension is free to install. Qodo offers a free Developer plan that includes 250 credits per calendar month for IDE interactions and 30 PR reviews per month. Most standard operations consume 1 credit each. The free tier is sufficient for individual developers to evaluate test generation and code suggestions. The paid Teams plan at $30/user/month increases credits to 2,500 per user per month.

What is the difference between Qodo and CodiumAI in the VS Code marketplace?

Qodo is the new name for CodiumAI. The company rebranded from CodiumAI to Qodo in 2024. The VS Code extension was updated to reflect the new branding. If you search for CodiumAI in the marketplace, you will find the Qodo extension since the old listing redirects to the new one. There is no separate CodiumAI extension anymore. For more details on the rebrand, see our article on the CodiumAI to Qodo transition.

Does Qodo work with VS Code on macOS, Windows, and Linux?

Yes. The Qodo VS Code extension works on all platforms where VS Code runs, including macOS, Windows, and Linux. The extension itself runs within VS Code and communicates with Qodo's cloud API, so there are no platform-specific dependencies or installation requirements. The experience is identical across all operating systems.

Can I use Qodo in VS Code without an internet connection?

Limited functionality is available offline. The Qodo extension requires an internet connection for AI-powered features like test generation and code suggestions, since these rely on cloud-hosted large language models. However, Qodo supports Local LLM mode through Ollama, which allows you to run models entirely on your machine without sending code to external servers. This is useful for air-gapped environments and teams with strict data privacy requirements.

How do I generate tests with Qodo in VS Code?

Select a function in your editor, then use the /test command in the Qodo chat panel or right-click and choose the Qodo test generation option from the context menu. Qodo analyzes the function's behavior, input types, and conditional branches, then generates complete unit tests covering the happy path, edge cases, and error scenarios. Tests are generated in your project's existing testing framework such as pytest, Jest, JUnit, or Vitest.

What AI models does Qodo support in VS Code?

Qodo supports multiple AI models in its VS Code extension including GPT-4o, Claude 3.5 Sonnet, and DeepSeek-R1. Premium models like Claude Opus consume more credits per request (5 credits) compared to standard models (1 credit). You can switch between models in the Qodo settings panel within VS Code. Local LLM support through Ollama is also available for teams that need to keep all code processing on their own machines.

Why is Qodo not showing suggestions in VS Code?

Check these common causes: you may not be signed in to the Qodo extension, your monthly credit balance may be exhausted, the extension may need an update, or your internet connection may be interrupted. Open the Qodo panel in VS Code and verify your sign-in status and remaining credits. Also check the VS Code Output panel (View then Output then select Qodo from the dropdown) for error messages. Restarting VS Code often resolves temporary connection issues.

Can I use Qodo alongside GitHub Copilot in VS Code?

Yes. Qodo and GitHub Copilot serve different purposes and can coexist in VS Code without conflicts. Copilot provides inline code completions while you type, while Qodo focuses on test generation, code review, and chat-based assistance. Many developers use both extensions simultaneously - Copilot for writing code and Qodo for generating tests and reviewing code quality. There are no known extension conflicts between the two.

How do I update the Qodo extension in VS Code?

VS Code updates extensions automatically by default. To manually check for updates, open the Extensions view (Ctrl+Shift+X or Cmd+Shift+X), click the three-dot menu at the top of the Extensions panel, and select Check for Extension Updates. If an update is available for Qodo, click the Update button. It is recommended to keep the extension updated to access the latest AI models, bug fixes, and feature improvements.

Does Qodo in VS Code support all programming languages?

Qodo supports all major programming languages in VS Code including JavaScript, TypeScript, Python, Java, Go, C++, C#, Ruby, PHP, Kotlin, and Rust. The AI engine uses large language models for semantic understanding, so it can handle virtually any language. Test generation quality is strongest for languages with mature testing ecosystems like Python (pytest), JavaScript (Jest), Java (JUnit), and TypeScript (Vitest).

How do I configure Qodo settings in VS Code?

Open VS Code Settings (Ctrl+Comma or Cmd+Comma on macOS) and search for 'Qodo' to see all available configuration options. You can also access settings through the Qodo panel in the Activity Bar. Key settings include the default AI model, test generation preferences, inline suggestion behavior, and telemetry options. Changes take effect immediately without restarting VS Code.

Originally published at aicodereview.cc

VoiceScribe

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

VoiceScribe

RealTime Speech To Text App Built with Google AI Studio

Live app: voice-scribe.netlify.app

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.

Design Community

Big Tech firms are accelerating AI investments and integration, while regulators and companies focus on safety and responsible adoption.

AI #ArtificialIntelligence #TechTrends #SoftwareEngineering #MachineLearning #CloudComputing #FutureOfTech #AISafety

Accelerating TURN with eBPF: A Non-Invasive Approach

ivanmtech / turn-bpf

RFC 8656 channel accelerator

TURN-BPF: research into eBPF offloads of RFC 8656 channels

Architecture: The Snooping Approach

Under the Hood: FIB Lookups & Heartbeats

Deployment & Verification

Performance Results

How to Set Up Qodo AI in VS Code: Installation Guide

Why set up Qodo in VS Code

Prerequisites

Step 1 - Install the Qodo extension

Step 2 - Sign in to your Qodo account

Step 3 - Generate your first tests

Step 4 - Explore code suggestions

Step 5 - Configure settings

Key settings to configure

Keyboard shortcuts

Tips for getting the most out of Qodo in VS Code

Troubleshooting

Alternatives to Qodo for VS Code

Conclusion

Further Reading

Frequently Asked Questions

How do I install Qodo AI in VS Code?

Is the Qodo VS Code extension free?

What is the difference between Qodo and CodiumAI in the VS Code marketplace?

Does Qodo work with VS Code on macOS, Windows, and Linux?

Can I use Qodo in VS Code without an internet connection?

How do I generate tests with Qodo in VS Code?

What AI models does Qodo support in VS Code?

Why is Qodo not showing suggestions in VS Code?

Can I use Qodo alongside GitHub Copilot in VS Code?

How do I update the Qodo extension in VS Code?

Does Qodo in VS Code support all programming languages?

How do I configure Qodo settings in VS Code?

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