Ai-Engineering on dplabs — Software Engineering & Technology Consultancy

The Security Risks of AI-Enabled Applications

Tue, 21 Apr 2026 00:00:00 +0000

Integrating AI into applications introduces security risks that traditional application security doesn’t address. Most security frameworks were designed for deterministic systems. LLMs are not deterministic — their outputs depend on inputs in ways that are difficult to predict, test, or constrain.

This doesn’t mean AI applications are inherently insecure. It means you need to think about security differently when LLMs are in the loop.

The Core Problem: LLMs Process Text as Instructions

In a conventional application, there’s a clear distinction between code and data. A SQL injection attack tries to blur that boundary — to get user input interpreted as SQL commands. You prevent it by parameterizing queries, by treating user input as data rather than code.

Building AI Features Without Losing Control of Your Architecture

Mon, 06 Apr 2026 00:00:00 +0000

AI features are getting added to production systems quickly — often quickly enough that the usual architectural discipline gets skipped. The integration is direct: OpenAI SDK in the service, API calls scattered through business logic, prompts hardcoded in the calling code.

This works for a proof of concept. At production scale, with real operational requirements, it creates a class of problems that are expensive to fix after the fact.

The Vendor Lock-in Problem

Directly using the OpenAI SDK, the Anthropic SDK, or any provider’s client library throughout your codebase creates tight coupling to that provider’s interface. When you want to:

Building Reliable AI Agents: Beyond the Demo

Mon, 23 Mar 2026 00:00:00 +0000

AI agents are compelling in demos. A language model that can use tools, retrieve information, take actions, and chain multiple steps together appears to solve problems that weren’t solvable before. Then you try to ship one and discover that the demo success rate was 80%, which means 1 in 5 operations fail silently.

Production agents require the same engineering discipline as any other distributed system. The failure modes are different, but the principles — observability, error handling, testing, graceful degradation — are the same ones you apply everywhere else.

AI Engineering Is Software Engineering

Mon, 09 Mar 2026 00:00:00 +0000

There’s a tendency to treat AI features as different from other software. Different enough that normal engineering practices don’t apply, or apply differently, or can be deferred. This tendency produces AI systems that are unreliable, unobservable, expensive to operate, and difficult to improve.

AI systems built with the same engineering discipline as other distributed systems are more reliable, cheaper to operate, and easier to improve. The disciplines aren’t different. The application is.

MCP: The Interface Between AI Models and the Rest of Your Systems

Mon, 23 Feb 2026 00:00:00 +0000

The Model Context Protocol (MCP) is a specification introduced by Anthropic in November 2024 that standardizes how LLM applications connect to external data sources and tools. It has since been adopted broadly — by OpenAI, Google, and major developer tooling vendors — and is becoming the standard interface layer between AI systems and the services they interact with.

Understanding MCP requires understanding the problem it solves, because the protocol itself is not complex.

Multi-Agent Systems: Useful Architecture or Complexity for Its Own Sake?

Mon, 09 Feb 2026 00:00:00 +0000

Multi-agent systems have become a popular architectural pattern in AI applications. The idea is appealing: if one agent is good, multiple agents working together must be better. Specialized agents for different subtasks. Agents reviewing each other’s work. Parallel execution across agents.

The appeal is intuitive. The implementation is often a mess of non-deterministic coordination, cascading hallucinations, and debugging nightmares where a problem in one agent produces a subtly wrong result that propagates through three others before producing a visible failure.

Evaluating LLM Applications: Beyond Vibe Checks

Mon, 26 Jan 2026 00:00:00 +0000

Most teams evaluate their LLM applications by asking them a few questions and deciding whether the answers look right. This is not evaluation — it’s a vibe check. It doesn’t scale, doesn’t catch regressions, and doesn’t provide any basis for measuring improvement over time.

Systematic LLM evaluation is harder than evaluating deterministic software. The outputs are probabilistic, quality is multidimensional, and the correct answer often isn’t a single string. These are difficulties, not reasons to skip evaluation.

RAG vs Fine-Tuning: Choosing the Right Tool for LLM Customization

Mon, 12 Jan 2026 00:00:00 +0000

“Should we use RAG or fine-tuning?” is a question teams ask when they need an LLM to work better for their specific use case. It’s often the wrong question — they’re different tools that solve different problems and can be combined.

Getting this wrong is expensive. Fine-tuning a model to “know” information that should be retrieved leads to a model that’s expensive to update and confidently answers with stale data. Implementing RAG when the problem is actually about model behavior leads to a system that retrieves correctly but still behaves wrong.

RAG Is Not a Database Query

Mon, 21 Oct 2024 00:00:00 +0000

Retrieval-Augmented Generation has become the default answer to “how do we make an LLM answer questions about our data.” The concept is simple enough to explain in one slide: embed your documents, store them in a vector database, retrieve the relevant ones at query time, pass them to the LLM.

The problem is that the one-slide version produces one-slide-quality results. Good RAG systems are significantly harder to build than the demos suggest, and the failures are often subtle — the system produces confident, plausible-sounding answers that are wrong in ways that are hard to detect without systematic evaluation.