Forem: Vinayprasad

From Probabilistic to Repeatable: Using Reflection to Make AI Systems More Reliable

Vinayprasad — Tue, 14 Apr 2026 06:26:46 +0000

In production systems, correctness isn’t enough.

What matters is whether the system behaves the same way every time.

One thing becomes very clear when you start using AI systems in real workflows: the outputs are good, but not always consistent. You can give the same input multiple times and still get slightly different answers. Sometimes they’re correct, sometimes they’re not. This isn’t a flaw in implementation—it’s how these systems are designed. They are fundamentally probabilistic.

In production systems, however, “good answers” are not enough. What we really need is consistent behavior, predictable outcomes, and repeatable fixes. We want deterministic systems. Since LLMs are inherently probabilistic, the goal is to push them as close as possible to deterministic—consistent and repeatable in practice.

Most AI systems today operate in a single-shot manner: input goes in, output comes out, and the process stops there. This approach directly exposes the probabilistic nature of the model. A more practical approach is to introduce iteration. Instead of stopping at the first answer, the system should try a solution, check whether it worked, improve it based on feedback, and repeat if necessary. This simple shift—from single-shot to iterative execution—is where reflection comes in.

Reflection doesn’t eliminate randomness. Instead, it reduces the impact of incorrect outputs by introducing feedback and correction. Each iteration acts as a filter: weak or incorrect solutions are identified and replaced, while better ones move forward. Over time, this process converges toward a more stable and repeatable outcome.

A simple example makes this clearer. Consider a basic multiplication problem like 27 × 14. A single-shot system might produce an incorrect answer like 328 and stop there. A reflection-based system, however, would re-check the calculation, identify the mistake, and correct it to 378. The improvement here doesn’t come from a better model—it comes from verification and iteration.

There’s a subtle difference in how people use AI. A vibe coder typically prompts the model, takes the answer, and moves on. A software developer approaches it differently—they run the output, test it, question it, and improve it. The model is the same, but the outcome is not. One treats AI as a final answer, while the other treats it as a starting point. Reflection brings that second approach into the system itself, allowing it to continue until the result actually works.

This becomes even more relevant in real systems. Imagine an alert where API latency suddenly spikes. A first attempt might be to restart the service. If the issue persists, the system observes the logs and notices database timeouts. At that point, it becomes clear that restarting the service didn’t address the root cause. A second attempt focuses on fixing the database connection, after which the system stabilizes. The key difference here is that the system didn’t stop at the first action—it adapted based on feedback.

Under the hood, a reflection-based system introduces a loop around the model. Instead of a simple input-to-output flow, it follows a cycle: generate a solution, execute it, observe the results, reflect on what happened, and improve the next attempt. This loop is what transforms the system from a one-shot generator into something that can iteratively move toward correctness.

In practice, this can be implemented with a simple control loop. The system generates a solution, executes it, checks whether it succeeded, and if not, incorporates feedback into the next attempt. Each iteration reduces error and increases confidence in the final outcome.

for attempt in range(3):
    solution = generate(problem)
    result = execute(solution)

    if result["status"] == "success":
        break

    feedback = analyze(result)
    problem = enrich(problem, feedback)

What makes this approach effective is the presence of strong feedback signals. Logs, metrics, test results, and system states provide a clear indication of whether a solution worked or failed. The stronger and more objective these signals are, the more reliable the reflection process becomes. Without them, the system is essentially guessing.

Of course, this approach comes with trade-offs. Iteration adds latency, increases compute usage, and introduces additional system complexity. But in most real-world scenarios, especially in production systems, reliability matters more than speed. A slightly slower system that consistently arrives at the correct outcome is far more valuable than a fast system that is unreliable.

Reflection works best in scenarios where outcomes can be clearly validated—debugging, incident remediation, code execution, and data pipeline recovery are good examples. It is less useful in tasks where correctness is subjective or where immediate responses are required.

Ultimately, AI systems don’t become reliable just by generating better answers. They become reliable when they can evaluate their own outputs and improve them. Not by eliminating randomness, but by correcting it until the outcome stabilizes.

That shift—from generating answers to iteratively improving them—is what moves us closer to building systems that are not just intelligent, but dependable.

Because in the end, it’s not about getting the right answer once—it’s about getting it right, every time it matters.

Where Should AI Actually Sit in Your System?

Vinayprasad — Mon, 06 Apr 2026 05:04:37 +0000

AI is becoming a key part of modern system design. Many teams are exploring how to integrate it across different layers of their architecture. While this opens many possibilities, it also creates a design challenge: finding where AI adds real value versus where simpler approaches might work better. Getting this balance right determines if a system remains reliable and maintainable as it grows.
Start by Breaking the System, Not Choosing the Tool
Before deciding to use AI, rules, or any database strategy, it’s helpful to break the system into logical layers. Most backend systems, whether in fintech, DevOps, or internal tools, tend to fall into three parts: the input layer, the decision layer, and the execution layer.
The input layer handles how data enters the system, such as APIs, UI interactions, or external triggers. The decision layer includes business logic, orchestration, and state transitions. The execution layer is where actual changes occur, like database writes, API calls, or infrastructure actions.
When you view systems this way, the placement of AI becomes clearer.
Where AI Fits Well
AI works best at the edges of the system, especially when dealing with unstructured or human-generated input. For instance, if a user types “restart the failed job for order 123,” AI can turn that into a structured format like { action: restart_job, order_id: 123 }. This is a strong example because the input is unclear and needs interpretation.
AI can also help with decision support by ranking options, classifying inputs, or suggesting actions. Even in these cases, AI should assist rather than take control.
Where AI Becomes Risky
Problems arise when AI moves deeper into the system, especially in decision-making or execution. If a large language model (LLM) directly decides what actions to take and executes them, the system effectively becomes a black box. It becomes difficult to understand why something happened, reproduce issues, or enforce constraints.
What looks simple in a demo—“user → AI → action”—can become hard to manage in production. Small changes in prompts, model versions, or inputs can lead to different outcomes, making debugging significantly more complex.
Think in Terms of Control and Execution
A better way to design systems is to separate control from execution. AI can help interpret input or suggest intent, but execution should remain deterministic. This means any action that changes system state—like updating a database, triggering workflows, or calling external services—should go through validation layers supported by rules and structured data.
This separation ensures that if AI makes a mistake in interpretation, the system can catch it before anything irreversible occurs.
Understanding Your System’s Tolerance for Uncertainty
Every system has a certain tolerance for uncertainty. In areas like payments, infrastructure automation, or order processing, even small mistakes can have serious consequences. These systems need strong guarantees, predictable behavior, and clear audit trails.
On the other hand, systems like chat interfaces, search, or recommendations can handle some level of approximation. In these cases, AI can be used more freely.
The goal is not to eliminate AI, but to control where uncertainty is allowed.
Why Structured Databases Still Matter
As AI adoption rises, there’s a tendency to rely heavily on vector databases for storing and retrieving knowledge. While these databases are powerful, they solve a very specific problem: semantic similarity.
Structured databases provide something different and essential: guarantees.
They enforce constraints like uniqueness and valid relationships. They support transactions, ensuring that operations either complete fully or not at all. Most importantly, they provide predictable and repeatable results. If you query a structured database with a specific key, you will always get the same answer.
In systems where correctness matters—like mapping an error code to a resolution or validating a state transition—this certainty is crucial.
Where Vector Databases Fit
Vector databases are useful when you need to find “something similar” rather than “something exact.” They are effective for searching through unstructured data such as documents, logs, or knowledge bases. They use approximate nearest neighbor algorithms, which trade perfect accuracy for speed.
This approach works well for cases like document retrieval or context enrichment. However, in systems where even a small error could lead to incorrect actions, this approximation becomes a risk.
State Machines vs Generative Decisions
Most backend systems are basically state machines. They progress through well-defined states—created, processing, completed, failed—with clear rules for transitions. Rule-based systems handle this well by enforcing valid transitions and rejecting invalid ones.
AI, however, does not understand or enforce these constraints inherently. It generates outputs based on patterns rather than strict rules, making it less suitable for controlling state transitions directly.
Execution Safety and Reliability
When systems perform actions, they need to be safe to retry, resistant to duplication, and easy to observe. Rule-based systems can enforce conditions like “only retry if the current state is failed,” ensuring predictable behavior.
If AI is used directly for execution decisions without validation, it can lead to unintended actions—duplicate retries, skipped steps, or incorrect operations. Over time, this introduces instability into the system.
Observability and Debugging
Deterministic systems are easier to debug because the path from input to output is clear. You can track what rule was applied and why a decision was made. AI systems require additional layers of observability—tracking prompts, model versions, and retrieved context—and even then, reproducing an issue may not be easy.
This difference becomes significant in production environments where quick diagnosis and resolution are essential.
Cost Beyond Tokens
While AI systems are often evaluated based on token cost, the real cost comes from latency, retries, infrastructure scaling, and operational overhead. Systems that rely heavily on AI may be faster to build at first but can be more expensive to maintain.
In contrast, structured and rule-based systems typically require more upfront design but are generally more predictable and cost-effective over time.
A Practical Architecture That Works
A practical approach that works well is to let AI handle interpretation while keeping execution deterministic. In this model, user input flows through an AI layer that extracts intent, which is then validated using rules and structured data before any action is taken. The response can optionally be formatted using AI again.
Vector databases can be included if needed to retrieve contextual information, but they should be optional and not replace core system logic.
A Simple Way to Decide
When designing a system, a few questions can help guide the decision:
• Do you have a clear identifier or key? Use a structured database.
• Can the logic be expressed as rules or state transitions? Use a rule engine.
• Is the input unstructured or ambiguous? Use AI.
• What happens if the system makes a mistake? If the impact is high, avoid using AI in execution paths.
Final Thought
Strong systems don’t try to replace deterministic logic with AI. Instead, they use AI where it makes sense—at the boundaries where interpretation is needed—while keeping the core of the system grounded in structured data and clear rules.
AI is most effective when it is limited, not when it is given full control.

How Large Systems Rethink Communication

Vinayprasad — Fri, 16 Jan 2026 14:37:33 +0000

Have you ever noticed how systems that worked perfectly fine suddenly start behaving differently as they grow? It’s not because the early decisions were wrong — it’s just that scale introduces new challenges, and some assumptions that felt safe initially start getting stretched. One of the first things teams revisit in this process is how different parts of the system communicate.
Most systems start with synchronous APIs. And why not? They’re easy to reason about, simple to debug, and make the flow of requests and responses clear. One service calls another, gets an answer, and moves on. For a long time, this works beautifully. Latency is predictable, dependencies are few, feedback is immediate, and issues are easy to spot. Teams can move fast, and the system behaves exactly as expected.
But then the system grows. Suddenly, traffic patterns are uneven, some requests spike, and others take longer than anticipated. New consumers join the system, old ones evolve, and processing capacity doesn’t always keep up with the incoming load. Coordinating when work happens across services becomes harder, and timeouts, retries, and monitoring start appearing everywhere. This isn’t a failure. The system is still doing what it was designed to do. It’s just working under new conditions.
At this stage, the question subtly changes. Instead of asking, “Can this service respond right now?” teams start asking, “Can we make sure this work happens reliably, even if it takes time?” That’s where messaging often enters the picture. Messaging allows one part of the system to record intent and another to act on it when it can. Temporary backlogs are expected, and slower components don’t immediately block faster ones.
Messaging doesn’t replace APIs — it complements them. Most modern systems end up using both. APIs remain for interactions that need immediacy, while messaging handles workloads that can tolerate flexible timing.
Enterprise messaging systems like TIBCO EMS have been around for a long time to address these needs. EMS works very well in environments where delivery guarantees matter, consumers are stable, message flows are predictable, and processing happens close to event creation. Many large organisations still rely on EMS for core integrations. But as systems become more distributed and dynamic, additional needs arise — particularly around retaining data longer and allowing multiple consumers to act independently.
This is where Kafka comes in. By treating events as a durable, ordered log, Kafka allows consumers to replay data when needed, multiple teams to read the same events independently, and processing to happen without tight coordination. Recovery becomes more predictable, and the system can handle growing complexity without changing the API-based interactions that already work. Kafka isn’t replacing earlier messaging systems — it’s expanding the architectural toolbox for modern needs, where history matters as much as delivery.
As systems mature, communication choices become more deliberate. Some interactions need agreement on time, some on state, and some on both. There’s no single right way to design it. The best architectures recognise which guarantees each part of the system actually needs and pick the right pattern accordingly.

So when systems rethink communication, it’s not because something went wrong. It’s because teams now understand the trade-offs better. Synchronous APIs feel natural early on, messaging helps reduce tight coordination later, and durable event streams make complex recovery and replay possible. Large systems evolve because experience teaches the teams what works under different constraints. That evolution is a sign of maturity — not a technical debt.

Reducing Architectural Drift When Using AI for Small Changes

Vinayprasad — Mon, 05 Jan 2026 08:00:02 +0000

In my earlier blog, I wrote about architectural drift and how AI, while accelerating delivery, can quietly push systems away from their original intent. This post is not meant to counter that argument or claim a fix. Instead, it tries to answer a more grounded question: if drift is inevitable, how do we reduce it when using AI for small, everyday change requests?
This is written from observation, not authority. Most of what follows comes from noticing patterns—what tends to go wrong, what helps a little, and what at least makes the damage visible sooner.
Architecture, in both the earlier blog and this one, does not mean diagrams or heavyweight documentation. It’s not about how neat the boxes look. Architecture here means the decisions that make change safe: where boundaries exist, who owns what responsibility, how data flows, and which assumptions the system quietly depends on to behave predictably. When those decisions are not preserved, AI doesn’t break the system immediately—it just optimizes locally until the global shape no longer makes sense.
One important shift in mindset helped me personally. Instead of treating AI as a faster way to generate code, I started treating it as something that needs to be constrained before it can be helpful. Most AI-assisted changes in real systems are small. But even small changes, when repeated without architectural awareness, compound into drift. So the goal stopped being “get the correct output” and became “preserve the shape while making the change.”
This is where non-negotiables start to matter. These are not suggestions or preferences. They are constraints that must hold true regardless of the change being requested. Things like not introducing new service boundaries, not duplicating business logic, not altering data contracts, or not crossing architectural layers. When these are left implicit, AI fills in the gaps with assumptions that feel reasonable in isolation but are harmful in aggregate.
Another lesson was where these constraints belong. They cannot be an afterthought. The architectural intent has to be part of the original prompt, not something clarified later. Each change request should start with the same foundation, explain the impact first, and only then move toward implementation. Once a change is applied on shaky intent, fixing it later almost always costs more.
Code duplication deserves special mention because it’s a subtle failure mode. AI is very good at re-implementing logic in slightly cleaner ways. Without explicit instructions, it will create parallel paths that look fine but slowly fragment behavior. If reuse matters—and it usually does—it needs to be said clearly. “Reuse existing logic.” “Do not create parallel implementations.” “Extend, don’t replicate.” These aren’t things the model reliably infers on its own.
Context windows add another layer of complexity. The AI can only reason over what it currently sees. Feeding it large files or entire repositories often backfires, because constraints pushed earlier in the conversation can silently drop out of scope. A more realistic approach is to assume the model only has visibility into a small set of files and to name them explicitly. Architecture then becomes a compact working context, not a document dump.
A simple prompt structure helped more than expected. Something along the lines of stating the non-negotiables first, defining the assumed scope, and asking the model to explain architectural impact before writing code. Not because it makes the AI smarter, but because it forces a pause before execution. That pause alone reduces accidental drift.
It’s important to be honest about the limits of this approach. None of this is a cure. Architectural drift is a natural property of evolving systems. The goal here isn’t to prevent change, but to ensure change happens deliberately rather than by inference. These practices don’t eliminate risk; they just make it visible earlier, while correction is still possible.
AI is exceptionally good at moving systems forward. Architecture exists to make sure we don’t move forward blindly. If architectural intent isn’t carried explicitly into our prompts, the system will still evolve—just not in a direction we consciously chose.
This isn’t about control.
It’s about preserving shape while allowing change.

Example Architecturally Constrained Change Request Prompt

You are implementing a small, incremental change to an existing system.
The following architectural constraints are non-negotiable and must be preserved:
The system follows a layered architecture.
Business logic resides exclusively in the domain layer.
Adapters are responsible only for data translation, not decision-making.
Existing service boundaries and data contracts must remain unchanged.
No new abstractions, services, or parallel implementations may be introduced.
Assume your effective context is limited to the following files:
OrderService.py, OrderValidator.py, OrderRepository.py.
Do not infer, recreate, or duplicate logic that may exist outside this scope.
Change request:
Add validation for a new optional field in the order payload.
Reuse existing validation mechanisms wherever applicable.
Avoid duplication and ensure behavior remains centralized.
Before implementing the change, explicitly state:
the architectural layer where the change belongs
whether the change risks violating any constraint listed above
If a violation is identified, stop and explain the risk.
If no violation exists, implement the minimal code change required, ensuring the system’s architectural shape remains intact.

Are We Building Software or Letting It Drift?

Vinayprasad — Thu, 01 Jan 2026 08:54:57 +0000

Imagine shipping features at a pace that felt impossible just a few years ago—prompt an AI, generate clean code, run the tests, deploy—everything flows smoothly, progress feels unstoppable. Until, months later, a seemingly minor change triggers a cascade of unexpected behavior that no one can fully explain.
Over the last few years, I’ve been watching a pattern repeat across teams and projects. It shows up in legacy-to-cloud migrations, but it doesn’t stop there. I see it just as often in brand-new systems built almost entirely with AI assistance — fast, confident, and delivered at a pace that would have been unthinkable a few years ago.
The development landscape has changed dramatically. The underlying risk hasn’t.
AI has made it easy to write a lot of code very quickly. Whether we’re migrating old systems or “vibe coding” new ones, the feedback loop feels great. You describe what you want, the AI produces something plausible, tests pass, and the system appears to work. Delivery feels smooth. Progress feels real.
And that’s exactly where things start to drift.
The issue isn’t that AI writes bad code. Often, it writes code that looks cleaner and more structured than what humans would have produced under pressure. The problem is that AI doesn’t just implement designs — it infers them. And every time we clarify, rephrase, or repeat a prompt, we give it another opportunity to reinterpret what the system should be.
Over time, the system quietly becomes something no one explicitly designed.
This is easiest to see during migrations. A system is supposed to be moved, not changed. But AI reorganizes modules for clarity, introduces abstractions that weren’t there before, and removes logic that appears redundant. Each change makes sense locally. Collectively, they reshape the architecture.
What’s more concerning is that the same thing happens in new projects — often faster. When a system is built incrementally through prompts and follow-up corrections, architecture emerges implicitly. There’s rarely a single moment where someone says, “This is the shape of the system.” Instead, the shape is the sum of many small interpretations made by an agent optimizing for the last instruction it received.
Repeated prompting makes this worse, not better. Each clarification nudges the model toward a slightly different understanding of intent. Boundaries blur. Responsibilities shift. What began as a clean mental model slowly fragments across files and layers.
One of the most visible symptoms of this drift is redundant and dead code. AI is remarkably good at adding logic to handle edge cases it’s no longer sure are covered. It duplicates behavior across components because it no longer sees the full picture within its context window. Over time, you end up with multiple versions of “the same thing,” none of which can be safely removed because no one is fully confident what depends on what anymore.
The code still works. That’s the trap.
Understanding it becomes harder with every iteration. Reading it no longer explains why the system behaves the way it does — only how it happens to behave right now.
Accidental refactoring is another quiet failure mode. You ask for a small change. The AI rewrites more than you expected because, from its perspective, consistency is improvement. Execution order shifts. Error handling changes shape. Responsibilities move just enough to matter later, but not enough to break tests today.
Nothing is obviously wrong, so it ships.
These problems don’t announce themselves immediately. Architectural drift rarely causes instant failures. What it does is erode the system’s ability to evolve safely. Months later, when performance degrades, or partial failures cascade, or a seemingly minor change triggers an incident, teams find themselves debugging behavior that no longer maps cleanly to any original design.
At that point, it doesn’t matter whether the system was migrated or greenfield. The problem is the same: the architecture exists only as an emergent property of code generated over time, not as an intentional, shared understanding.
Some teams try to address this with better prompts. Clearer instructions. Tighter constraints. That helps, but it’s not a solution. Large systems don’t fit into a single context window. AI fills gaps by inference. Redundancy creeps in. Dead code accumulates. Drift continues — just more quietly.
The uncomfortable truth is that AI doesn’t cause architectural drift on its own. Drift happens when intent isn’t made explicit and maintained over time. AI simply accelerates the consequences of that omission.
Used carelessly, AI makes it easy to move fast without realizing what’s being changed. Used thoughtfully, it can surface uncertainty and force conversations we’ve been postponing for years. But it cannot hold architectural intent on our behalf.
That responsibility doesn’t go away just because code is easier to produce.
If we treat AI-assisted development as a shortcut to delivery rather than an architectural event, we shouldn’t be surprised when systems become harder to reason about, harder to change, and more fragile over time.
The code will compile.
The tests will pass.
The problems will wait.
Architectural drift doesn’t break systems immediately. It just ensures that when they do break, no one knows what the system was meant to be or which assumptions still hold. Every change becomes risky not due to lack of skill, but because intent was never held steady while everything else accelerated.