DEV Community: Dimitris Kyrkos

Your AI feature isn't a feature. It's a dependency you don't control.

Dimitris Kyrkos — Thu, 01 Oct 2026 06:34:06 +0000

In the tutorial, the AI call always works. You import the SDK, paste in an API key, await a completion, and render the result. Ship it.

In production, that same line of code is a network call to someone else's infrastructure, running someone else's capacity planning, under someone else's incident response. Sometimes it's slow. Sometimes it rate-limits you. Sometimes it's just down.

The question isn't whether your AI provider will have an outage. It's what your users see when it does. If the answer is "a frozen screen" or "Something went wrong," the problem isn't the provider. It's the architecture.

Here are the failure modes I see most often, and what graceful degradation looks like for each.

Failure mode 1: the whole page waits on the model

Illustrative scenario: a project management app adds an AI-generated summary at the top of every ticket. The summary is fetched server-side before the page renders. One afternoon the provider's latency jumps from 2 seconds to 40. Now every ticket page takes 40 seconds to load, including for users who never read the summary.

The AI part was optional. The architecture made it mandatory.

Fix: never put a model call on the critical rendering path. Load the core page first, fetch AI output asynchronously, and give it a hard timeout. If it doesn't arrive, the slot stays empty or shows a quiet "summary unavailable." The ticket still opens.

Failure mode 2: one provider, hardcoded

If your code calls one vendor's SDK directly in twenty places, you have twenty single points of failure and no switch to flip.

Put a thin routing layer between your app and the providers, and make fallback a first-class behavior rather than a try/catch afterthought:

const chain = [
  { name: "primary", call: callPrimaryModel, timeoutMs: 8000 },
  { name: "secondary", call: callSecondaryProvider, timeoutMs: 8000 },
  { name: "local", call: callLocalModel, timeoutMs: 4000 },
];

async function complete(task: Task): Promise<Result | null> {
  for (const step of chain) {
    if (breaker.isOpen(step.name)) continue;
    try {
      const out = await withTimeout(step.call(task), step.timeoutMs);
      breaker.recordSuccess(step.name);
      return { ...out, servedBy: step.name };
    } catch (err) {
      breaker.recordFailure(step.name);
    }
  }
  return null; // caller must handle "no AI available"
}

Two details matter more than the loop itself. The circuit breaker stops you from hammering a provider that's clearly down (and paying the full timeout on every request). And null is a legitimate return value, which forces every caller to decide what happens without AI.

Failure mode 3: the fallback model gets the same job

A small local model (served through something like Ollama or llama.cpp) is a great last line of defense, but it isn't a drop-in replacement for a frontier model. Prompts tuned for one often produce garbage on the other.

Decide in advance which tasks are essential enough to fall back locally: classification, short extraction, simple rewrites. Give those their own prompts and test them. Everything else should degrade to "not available right now" rather than to a confidently worse answer.

Failure mode 4: the core features depend on the AI path

This is the one that turns a provider outage into your outage. Search that only works through embeddings. A form that can't be submitted until the AI validator responds. An onboarding flow that stalls because the welcome message is generated.

Every AI feature should have a non-AI path that still lets the user finish their job: keyword search behind semantic search, rule-based validation behind AI validation, a static template behind the generated one.

Resilience is a day-one decision

Graceful degradation is really just treating your AI provider like any other external dependency: timeouts, fallbacks, circuit breakers, and a clear answer for "what if it's gone?" The teams that struggle are the ones who treated the model as part of their own code instead of as a service they rent.

Retrofitting this later means touching every call site. Designing it in from the start means one routing layer and a few decisions.

What does your app actually do today when your AI provider goes down? Have you tested it, or are you assuming?

Half the AI agents in production are if-statements with a GPU bill

Dimitris Kyrkos — Mon, 28 Sep 2026 07:45:38 +0000

There's a new kind of technical debt, and it doesn't come from cutting corners. It comes from reaching for the most impressive tool in the room.

Call it resume-driven AI engineering: picking an agent framework, a vector database, or a multi-model orchestration layer because it looks great on a CV, not because the problem needs it. The result works in the demo. It's also slower, more expensive, harder to debug, and nondeterministic in places where it didn't need to be.

The demo vs. the pager

In a tutorial, complexity is free. You spin up an agent, wire in a vector store, and watch it do something clever with ten sample documents.

In production, every moving part has a cost: latency, token spend, a new failure mode, a new thing someone has to understand at 3 a.m. The question isn't "can an LLM do this?" (it usually can). It's "is an LLM the simplest thing that does this reliably?"

Here are three places where the answer is often no. The scenarios are illustrative, but if you've been around AI projects for a while, they'll look familiar.

Failure mode 1: a model call where a regex would do

A team needs to pull invoice numbers out of incoming emails. Invoice numbers follow a fixed format: INV- plus eight digits. They send every email to an LLM with a prompt asking it to extract the number.

It works 98% of the time. The other 2%, the model "helpfully" reformats the number, or picks up a purchase order number instead. Each call costs money and adds a few hundred milliseconds.

import re

INVOICE_RE = re.compile(r"\bINV-\d{8}\b")

def extract_invoice_ids(text: str) -> list[str]:
    return INVOICE_RE.findall(text)

Deterministic, testable, effectively free, and it runs in microseconds. Keep the model for the messy cases the pattern can't handle, and route to it only when the regex finds nothing.

Failure mode 2: vector search where SQL would do

"Show me all orders from customer 4417 in the last 30 days that are still unpaid."

That's not a semantic question. It's a filter. Yet it's common to see this kind of query embedded, pushed through a vector store, and answered by an LLM summarizing the top-k chunks, which may or may not include every matching order.

SELECT id, total, created_at
FROM orders
WHERE customer_id = 4417
  AND status = 'unpaid'
  AND created_at >= NOW() - INTERVAL '30 days';

Exact, complete, indexed, auditable. Vector search is great when you're matching meaning ("tickets similar to this complaint"). It's the wrong tool when you're matching facts.

Failure mode 3: an autonomous agent where a decision tree would do

A support workflow: if the customer is on the enterprise plan and the issue is billing, route to account management; if it's a bug, open a ticket; otherwise, send the FAQ link.

That's four branches. Someone builds it as an autonomous agent with tool access, a planning loop, and a memory store. Now the routing is probabilistic, occasionally loops, and nobody can explain why ticket #8812 went to the wrong team.

def route(customer, issue):
    if customer.plan == "enterprise" and issue.type == "billing":
        return "account_management"
    if issue.type == "bug":
        return "open_ticket"
    return "send_faq"

If you can draw the logic on a whiteboard, you probably don't need an agent to rediscover it every request.

The reframe

A lot of "AI systems" are really ordinary software with an LLM bolted onto a step that didn't need one. The model isn't the problem. Using it as the default instead of the exception is.

A practical decision checklist

Before adding a framework, a model call, or an agent, ask:

Is the input structured or the output fixed-format? Start with parsing, regex, or schema validation.
Is the question about facts or about meaning? Facts go to SQL. Meaning can go to embeddings.
Can the logic be enumerated? If yes, write the branches. Agents are for open-ended tasks where you genuinely can't.
What happens when it's wrong? If the answer is "silent bad data," you want determinism.
Who maintains this in a year? Every framework is a dependency someone has to upgrade, understand, and debug.

None of this means "never use AI." Use it where ambiguity actually lives: unstructured text, fuzzy matching, generation. Just make it the tool you reach for on purpose, not by reflex.

The best engineers aren't the ones with the most complex stack. They're the ones whose systems are still simple enough to understand when something breaks.

What's the most over-engineered AI setup you've seen (or built) that could've been replaced with something boring?

Your model doesn't need more training. It needs a better search index.

Dimitris Kyrkos — Thu, 24 Sep 2026 09:40:25 +0000

Intro

Every team that plugs an LLM into its business hits the same moment. Someone asks the model about an internal pricing rule, a product SKU, or a clause in the standard contract, and it answers confidently and wrongly.

The reflex that follows is almost universal: "The model doesn't know our business. Let's fine-tune it."

So the team spends weeks exporting tickets and docs, cleaning them, formatting them into JSONL, and paying for training runs. The new model sounds more like the company. It uses the right jargon. And it still makes things up.

That's not bad luck. It's a category error.

What fine-tuning is actually good at

Fine-tuning adjusts a model's weights so it behaves differently. That's powerful when the thing you want to change is behavior:

A specific tone or writing style (support replies that sound like your brand, not like a chatbot)
A strict output format (always return this JSON schema, always produce this report layout)
A narrow, repetitive task where a smaller tuned model can replace a bigger general one

Notice what all of those have in common. They're about how the model answers, not what facts it knows.

When the goal is "the model should know our refund policy, our product catalog, and last quarter's changes," you're asking weights to act like a database. They're a bad one.

Failure mode 1: it still hallucinates, just in your accent

A fine-tuned model doesn't gain a reliable sense of what it knows and what it doesn't. Training on your documents shifts probabilities toward your vocabulary, but when a question lands in a gap, the model does what it always does: it produces the most plausible-sounding continuation.

Illustrative scenario: a support assistant tuned on two years of tickets is asked about a warranty extension introduced last month. It has never seen it. It answers anyway, in perfect company voice, with the terms of the old warranty. The answer is more convincing than a generic model's would have been, which makes it more dangerous, not less.

Fluency in your domain is not the same as accuracy about your domain.

Failure mode 2: every fact change is a training run

Business knowledge isn't static. Prices change, policies get revised, products get deprecated, a regulation lands and three documents get rewritten.

If that knowledge lives in the weights, every update means rebuilding the dataset, retraining, re-evaluating, and redeploying. In practice, teams don't do that weekly. So the model drifts out of date, quietly, and nobody knows exactly which facts are stale.

Compare that with a retrieval setup: a document changes, you re-index it, and the next query sees the new version. The update cycle is minutes, not a project.

Failure mode 3: you can't show your work

When an answer comes from retrieval, you can point to the exact chunk of the exact document it was grounded in. You can show it to the user. You can log it. When someone disputes an answer, you can check whether the source was wrong or the model misread it.

When an answer comes from fine-tuned weights, there is no source. The knowledge is smeared across billions of parameters. You can't cite it, you can't audit it, and you can't tell a compliance team where a claim came from.

For anything customer-facing, regulated, or contractual, that alone should end the discussion.

What to build first instead

Before training custom weights, invest in the boring part: retrieval.

user question
   -> query rewriting / expansion
   -> hybrid search (keyword + embeddings) over a clean, deduplicated index
   -> reranking
   -> top-k chunks + source metadata into the prompt
   -> answer with citations

Most of the quality comes from things that have nothing to do with the model:

Clean source documents (no three conflicting versions of the same policy)
Sensible chunking that keeps related context together
Metadata (dates, owners, product, region) you can filter on
Hybrid search, because embeddings alone miss exact identifiers like SKUs and error codes
An evaluation set of real questions with known correct answers, so you can measure whether changes help

None of this is glamorous. All of it pays off more than a training run for knowledge-heavy use cases.

When fine-tuning does make sense

This isn't "never fine-tune." It's "fine-tune for the right reason, and usually later":

Retrieval is solid, answers are grounded, but the output format or tone keeps drifting. Tune for behavior.
You need a smaller, cheaper model to handle a narrow, high-volume task a big model already does well. Tune for cost.
The model struggles to use retrieved context well in your domain (for example, dense technical or legal text). Tune on examples of reading and citing context, not on the facts themselves.

In all three cases, facts still come from the index. The weights handle behavior.

The reframe

Fine-tuning teaches a model how to talk. Retrieval tells it what's true right now. Most "the model doesn't understand our business" problems are the second kind wearing the costume of the first.

What pushed your team toward fine-tuning (or away from it), and did it actually fix the knowledge problem you were trying to solve?

Your LLM has no memory. Your application had better have one.

Dimitris Kyrkos — Mon, 21 Sep 2026 10:05:47 +0000

Intro

Every LLM tutorial has the same shape. You send a list of messages, you get a reply, you append the reply, you send the list again. It works, it demos well, and it quietly teaches you the wrong mental model.

That loop is not state management. It is the absence of it, dressed up as a feature.

The APIs behind LLM platforms are stateless. Each request is independent of the last one. The model does not "remember" your conversation, it re-reads whatever you hand it, every single time. Meanwhile the thing you are building, a support flow, a code migration, an approval process, a multi-step agent, is stateful by nature. Somebody started it, it is halfway done, and it has to survive interruptions, retries and crashes.

That gap between a stateless processor and a stateful process is where production systems break. Here are the three places I see it break first.

1. "Just send the history" stops scaling

The tutorial answer to "how does the model know what happened earlier?" is to resend the whole transcript. It is fine for ten turns. At a hundred turns you are paying for the same tokens over and over, latency creeps up, and you start hitting context limits at the worst possible moment.

The usual patch is summarization: compress old turns into a paragraph and carry on. That helps with size but introduces a subtler problem. The summary is now the model's opinion of what mattered, and nothing in your system can verify it.

Imagine a multi-step refund workflow (illustrative scenario, not a real case). At turn 4 the user confirms the order ID. At turn 30 the summary says "user wants a refund for a recent order." The ID got compressed away, and the model now confidently picks the wrong one.

The fix is to stop treating the transcript as the state. Facts that the process depends on belong in a structured object your code owns:

@dataclass
class RefundState:
    order_id: str | None = None
    reason: str | None = None
    amount_confirmed: bool = False
    step: str = "collect_order"   # explicit position in the workflow

def build_prompt(state: RefundState, recent_turns: list[Message]) -> list[Message]:
    # The model gets the current state as input, plus only the turns it needs.
    return [system_prompt(), state_message(state), *recent_turns[-6:]]

Now the context you send is small, deterministic and reviewable. The model reads state, it does not store it.

2. The user interrupts halfway through

Real users do not wait politely for a long-running process to finish. They close the tab, change their mind, or send "actually, cancel that" while three tool calls are still in flight.

If the only record of progress is "whatever the model said last," you cannot answer basic questions. Which steps already ran? Which are safe to abandon? Does the half-finished action need to be rolled back?

A workflow that can be interrupted needs explicit steps with explicit statuses, persisted outside the model:

class Step(Enum):
    PENDING = "pending"
    RUNNING = "running"
    DONE = "done"
    CANCELLED = "cancelled"

# Persisted per run, updated by your code, never inferred from model output.
run.steps["reserve_inventory"] = Step.DONE
run.steps["charge_card"] = Step.RUNNING

When the interrupt arrives, your code reads the run record, decides what a cancellation means at this point, and tells the model the outcome. The model is not asked to work out where it was.

3. The API call fails in the middle of a transaction

Retries are where stateless design bites hardest. If a request times out after your tool executed but before you saw the response, resending it can execute the tool twice. Charge the card twice. Send the email twice. Open two tickets.

This is an old distributed systems problem, and the old answers apply: idempotency keys, an append-only event log, and recovery by replay.

def execute_tool(run_id: str, step_id: str, call: ToolCall):
    key = f"{run_id}:{step_id}"
    if (result := store.get_result(key)) is not None:
        return result                      # already ran, do not run again
    result = tools[call.name](**call.args, idempotency_key=key)
    store.save_result(key, result)
    return result

Notice that none of this depends on the model behaving well. That is the point. A model can be asked to "remember not to repeat itself," and it will still eventually repeat itself.

The pattern underneath

All three failures come from the same mistake: letting the conversation double as the system of record. Once you separate the two, the design gets much less mysterious.

State lives in your application: structured, persisted, versioned, recoverable.
The model is a stateless processor. It receives the relevant state, produces a proposed next action, and your code validates and applies it.
The transcript is a log for humans and for debugging, not the source of truth.

An LLM workflow is really a state machine with a language model on top of it.

Build it or lean on the platform?

Some providers now offer conversation or thread objects that manage history for you. They are convenient for prototypes and for simple chat. Before relying on them for a business process, ask a few questions:

Can you inspect and export the state in a form your own code can reason about?
Can you resume, replay or roll back a run after a failure?
Can you move to another model or provider without losing the process?
Who is accountable when the stored history and reality disagree?

If the answers are "not really," keep the state in your own store and treat the platform's memory as a cache at best. Managed history is fine as an optimization. It should not be where correctness lives.

Closing thought

If you rely on the model to remember the state of the conversation, your system will eventually break, and it will break in the least reproducible way available. Keep your application code as the source of truth and let the model do what it is good at: processing what you hand it, one request at a time.

Where does your team keep workflow state for multi-step LLM interactions: your own database, an event log, or the provider's thread objects? And what made you pick it?

Two-second latency isn't an AI problem. It's an architecture problem your stack was never built to hide.

Dimitris Kyrkos — Fri, 18 Sep 2026 06:25:25 +0000

Intro

There's a gap between the demo and the deployment that nobody puts in the tutorial.

In the demo, you call the model, you get a response, you render it. Done. In production, that same call sits in your request path for one, two, sometimes four seconds, and your users are staring at whatever you left on screen while they wait.

We spend weeks shaving milliseconds off database queries and tuning cache layers to get a page from 180ms to 90ms. Then we bolt an LLM call onto the same request/response cycle and it takes two full seconds to resolve. Nobody notices the discrepancy until users start bouncing.

Here's the actual gap: traditional backend work happens in a latency band humans don't perceive. LLM inference happens in a band they very much do. Same request/response pattern, completely different experience on the other end of it. If you don't change how you architect for it, users feel the friction immediately, no matter how good the model's output is.

Failure mode 1: the silent request

Picture a support-ticket triage feature. User submits a ticket, the backend calls an LLM to classify and route it, and the endpoint doesn't return until the model finishes. On a slow model day, that's a three-second white screen with no feedback. The user assumes the button didn't register and clicks again. Now you've got two calls in flight for the same ticket. This is a made-up example, but if you've shipped an LLM feature behind a synchronous POST, you've lived some version of it.

The fix isn't a faster model, it's not treating the call as instant in the first place.

Failure mode 2: streaming as an afterthought

Streaming gets treated as a nice-to-have polish pass instead of the default. Teams ship the blocking version first, get it working end to end, and plan to "add streaming later." Later rarely comes, because by then the blocking version is load-bearing and touching it means retesting the whole flow. Token-by-token streaming isn't a UX nicety here, it's the difference between "the interface feels instant" and "the interface feels broken."

Failure mode 3: heavy work still living in the request path

Some LLM work genuinely doesn't need to block the response at all: summarizing a document after upload, generating suggested tags, running a background analysis pass. These still get built as synchronous calls because that's the default pattern every other endpoint in the codebase already uses. Moving that work to an async job with a webhook or polling endpoint is often a bigger UX win than any amount of prompt optimization, because the user was never meant to wait on it.

Failure mode 4: no optimistic path forward

Even with streaming and async jobs in place, there's often no way for the user to keep moving while the model works. Optimistic UI, showing the next step as available, prefilling a draft state, letting the user act on a provisional result, keeps people in the workflow instead of parked on a spinner watching a progress indicator that means nothing to them.

The reframe

None of this is really an "AI latency" problem. It's a request/response architecture problem that AI just made visible, because AI is the first thing in most stacks slow enough that users notice the assumption baked into synchronous request handling. The fix isn't specific to LLMs: stream what you can, push what doesn't need to block into the background, and give the user something to do while they wait.

When you're deciding which technique to reach for: if the output needs to be seen as it's produced, stream it. If it doesn't need to block the next user action at all, take it out of the request path entirely. If it has to block but you can predict the shape of the result, use optimistic UI to bridge the gap.

We hit this directly while building the analysis pipeline behind Cyclopt: the moment an LLM call entered the loop, the whole interaction model around it had to change, not just the backend call itself.

How is your team handling this? Streaming everything by default, pushing more to background jobs, or still treating the LLM call like any other backend request?

Your LLM Isn't Bad At Math. It Was Never Doing Math In The First Place.

Dimitris Kyrkos — Tue, 15 Sep 2026 06:31:43 +0000

Your LLM Isn't Bad At Math. It Was Never Doing Math In The First Place.

In a tutorial, an LLM call looks like a function: pass in text, get back an answer, move on. It's easy to start treating the model like it's evaluating your business logic the same way a function would, deterministically, the same input always producing the same output.

In production, that assumption breaks in a specific, predictable way, and it's worth naming precisely why.

Traditional software runs on deterministic logic: if input A meets condition B, output C happens, every time, with a proof you could write on a whiteboard. An LLM runs on statistical probability: it predicts the most likely next token given the patterns in its training data. Those are two different kinds of "correct." The friction shows up exactly where a team asks the second kind to do the first kind's job.

Below are the places that friction actually shows up in a live system. These are illustrative scenarios based on the shape this failure takes, not one specific incident.

Asking a model to do arithmetic is asking it to guess what arithmetic usually looks like

Say a pipeline extracts line items from a batch of invoices, then asks the same model call to also compute the subtotal, apply tax, and return a total. On short, simple invoices, it's right almost every time, because short simple math is heavily represented in training data and easy to pattern-match. On a 40-line invoice with mixed tax rates and a rounding rule, it starts being right most of the time, which is a different and much worse thing than right. Nothing throws an error. The number is just plausible instead of correct, and "plausible instead of correct" is invisible until someone reconciles the books.

A statistically-applied business rule is not the same rule as a logically-applied one

Say the business rule is "refunds are allowed within 30 days of purchase." Put that rule in a prompt and ask the model to decide eligibility case by case, and it will get the easy cases right: a purchase from six months ago, obviously no; a purchase from yesterday, obviously yes. Where it gets interesting is the boundary: day 29, day 30, day 31, across time zones, with a purchase timestamp in one format and today's date passed in another. A deterministic date comparison gets this right every single time by construction. A model is producing its best guess at what "a refund decision near the boundary" looks like, based on how those decisions were phrased in its training data, and that's a meaningfully different operation even when it happens to output the correct answer nine times out of ten.

The output still looks like a normal response, which is exactly the problem

This is what makes the failure mode dangerous rather than just annoying: a wrong statistical answer doesn't look different from a right one. It's the same JSON shape, the same confident tone, the same absence of an exception. There's no signal in the response itself that tells you this was a guess rather than a computation. You find out later, from a customer service escalation or a finance reconciliation, not from anything in your logs.

Where the line actually goes

None of this means don't use the model near your business logic. It means be precise about which half of the job you're handing it.

What the model is good at: turning unstructured input, an email, a contract clause, a support ticket, a scanned form, into structured data. That's genuinely ambiguous work: language is fuzzy, humans phrase the same request ten different ways, and a statistical model that's seen millions of phrasings is the right tool for mapping "hey can I send this back, it's been like a month" into structured fields like intent and stated days since purchase.

What the model should never be the last word on: the validation, the calculation, and the rule enforcement that runs on that structured data once you have it. That's deterministic code's job, on purpose, with a strict schema at the boundary so a malformed or out-of-range extraction fails loudly instead of quietly flowing downstream as a confident-looking guess.

We lean on this split in how Cyclopt's automated checks work: the model interprets unstructured signals in a codebase or a pull request, but the actual rule enforcement, the pass or fail line, runs through deterministic logic against a defined schema, not through the model re-deciding the rule each time. The interpretation layer changes. The rule layer doesn't get to.

The reframe

Statistical vs. logical correctness isn't a model-quality problem that gets solved by a better model. It's an architecture decision, and better models make it easier to ignore, not less necessary to make. Let the model handle the ambiguity. Let your code handle the rules.

Where do you actually draw that line in a system you've shipped? What's the one thing you learned the hard way should never have been the model's call to make?

AI Model Upgrades Aren't Patches. They're Silent Breaking Changes Wearing a Version Bump.

Dimitris Kyrkos — Fri, 11 Sep 2026 06:15:02 +0000

Intro

AI Model Upgrades Aren't Patches. They're Silent Breaking Changes Wearing a Version Bump.

In a tutorial, calling an LLM API looks simple: send a prompt, get a response, parse it, move on. The model is treated like any other stable dependency, something that behaves today the way it behaved last week.

In production, that assumption quietly stops being true, and nothing in your stack tells you when it happens.

When a database vendor ships a patch, your queries keep returning the same shape of data they always did. Compatibility is the whole point of a patch. When an AI provider updates a model, even a version bump billed as a minor optimization can change how that model interprets the exact same system prompt it handled fine yesterday. Nobody signs off on that change on your end. Nobody flags it in your changelog. It just starts behaving differently, silently, the next time your endpoint routes to the new weights.

Below are the places that drift actually shows up. These are illustrative scenarios based on the shape this class of failure takes, not one specific incident.

Structured output schemas quietly reshape themselves

Say a pipeline asks a model to return JSON with keys like status, confidence, and flagged_reason. That's worked reliably for months against a pinned prompt. Then the underlying model gets swapped for a newer checkpoint behind the same generic endpoint, and it starts returning reason_flagged instead of flagged_reason on a subset of edge-case inputs, close enough to pass a casual glance, different enough to break every downstream consumer expecting the old key. No exception gets thrown. The field is just missing, and whatever reads it either crashes on a null or, worse, silently treats the absence as "nothing flagged."

Guardrails degrade exactly where you can't see them

Validation logic built around a model's known quirks, how it phrases refusals, how it handles ambiguous instructions, where it tends to hedge, is built against a specific behavioral fingerprint. Swap the model and that fingerprint shifts. A regex or classifier tuned to catch a model's old refusal pattern stops catching the new one. The guardrail doesn't fail loudly. It just quietly stops doing its job on the exact edge cases it existed to catch, the ones rare enough that nobody's manually reviewing that output anymore.

"It still returns 200" is why nobody notices

This is the core of why these failures are dangerous: nothing about them looks like an error. The API call succeeds. The response is well-formed enough to pass a basic type check. The status code is fine. The only thing wrong is that the content is subtly different from what every downstream system was built to expect, and that difference doesn't surface as a stack trace. It surfaces three weeks later as a support ticket about corrupted records, or a data quality review that turns up a cluster of malformed rows nobody can explain.

Auto-updating endpoints turn every deploy into an uncontrolled experiment

Pointing at a generic, "always latest" model endpoint feels convenient right up until the provider ships an update on its own schedule instead of yours. At that point every request your system sends is effectively running against a dependency you never tested, on a timeline you don't control, with no diff to review before it goes live. Nobody would deploy a database migration that way. Plenty of teams are doing the equivalent with their model layer without noticing.

The reframe

This isn't really an AI reliability problem. It's a dependency management problem that happens to involve a model, and it deserves the same discipline any other production dependency gets: pin the version, test before you upgrade, and monitor for drift instead of waiting for it to show up as bad data.

We ended up building a version of this discipline into how Cyclopt's automated checks handle LLM-based analysis, mostly because the alternative is finding out about drift from a bug report instead of a test run.

Concretely, that means:

Pin exact model versions. Point at a specific checkpoint, not a generic "latest" alias, so an upgrade is something you opt into instead of something that arrives unannounced.
Build regression tests that run before any model version change. Treat a model swap the same way you'd treat a major dependency bump: a known set of inputs, known expected shapes, run before the new version touches production traffic.
Monitor output schemas in real time. Track the actual shape of what's coming back, not just whether the call succeeded, so schema drift shows up as an alert instead of a data quality incident.

Stability in the AI ecosystem isn't something you get by default. It's something you have to actively engineer, the same way you'd engineer it for any other dependency you don't control the release schedule of.

Has a silent model upgrade ever broken something in your pipeline before you knew what was happening? What caught it: a test, a monitor, or a support ticket?

AI Didn't Kill the Need for System Design. It Just Made Bad System Design Easier to Ship.

Dimitris Kyrkos — Tue, 08 Sep 2026 09:10:19 +0000

Intro

AI Didn't Kill the Need for System Design. It Just Made Bad System Design Easier to Ship.

Every "no-code AI" pitch makes the same promise: describe what you want, and the AI builds it. No engineers required.

Here's the gap nobody puts in the demo video: getting a working prototype out of a prompt and getting a production system that survives real users are two completely different problems. The first is a syntax problem. AI is genuinely good at that part. The second is a system design problem, and system design doesn't get easier just because a model is writing the implementation. If anything, it gets more dangerous, because the code now looks finished before anyone has checked whether the underlying architecture is sound.

Below are four places where that gap shows up hardest. The scenarios are illustrative, not real incidents, but they're the shape of thing that happens constantly once a "no-code" app leaves the demo and meets actual users.

Data normalization is invisible until it corrupts something

Picture a no-code AI tool asked to "build a customer database with orders and shipping addresses." It'll happily generate tables. What it won't do on its own is ask whether an address belongs to a customer or to an order, whether a customer can have multiple addresses, or what happens when someone updates an address mid-order. Get that wrong and you don't get an error message, you get silently wrong data: an order ships to an address the customer changed three weeks ago, and nobody notices until support tickets pile up. Schema design is a series of judgment calls about what the business actually means by its own data, and an AI has no way to know that unless someone tells it, explicitly, up front.

State persistence across sessions is where "it works in the demo" quietly stops being true

A prompt-generated checkout flow will work perfectly in a five-minute demo where one person clicks through it once. Put it in front of real traffic and now you've got a user who adds an item to their cart on their phone, closes the tab, comes back on their laptop an hour later, and expects the cart to still be there. Or two tabs open at once, both trying to update the same session state. None of that is a coding problem in the "write more code" sense. It's a decision about where state lives, how it's synchronized, and what "the same session" even means across devices and time, decisions that have to be made before a single line gets written, not discovered after the fact.

API rate limits and error handling are a design decision wearing a bug report's clothes

When a no-code AI app calls a third-party payment or shipping API, what happens when that API returns a 429, or times out, or comes back with a response the app didn't expect? An AI generating happy-path code by default will wire up the success case and leave the rest as an unhandled exception. That's not a bug you patch later, it's an architectural gap: does the system retry, queue, degrade gracefully, or fail loudly? Every one of those is a different design, and none of them are implied by "connect to the payment API."

Security boundaries don't announce themselves in a prompt

"Let users manage their own profile" sounds simple enough to generate. Whether that same code accidentally lets user A read or edit user B's profile by changing an ID in a request is an access control question, and access control is exactly the kind of thing that looks correct in a demo (because the demo only ever has one user) and falls apart the moment two accounts exist. This is architecture, not implementation detail, and it's usually the last thing anyone checks because it's the thing that's hardest to notice is missing.

The reframe

No-code AI isn't really removing the need for engineering. It's removing the friction of writing syntax and quietly reassigning the hard part, the architectural judgment, to whoever is willing to notice it's still required. The teams that get burned aren't the ones who used AI to generate code. They're the ones who mistook "the AI wrote it and it ran" for "the AI designed it and it's sound."

We've run into a version of this while building Cyclopt's Companion: code generated by an AI assistant will often pass a lint check and even a basic security scan while the schema or state model underneath it is quietly wrong. Catching that isn't a code-generation problem, it's a "does someone with architectural judgment ever look at this" problem, and that's a different tool and a different habit than "prompt better."

So here's the actual decision teams need to make: use AI to generate implementation once the architecture is already decided by someone who understands the domain, or let AI-generated architecture ship and find out what broke in production. Those are very different bets.

Where has this bitten you, or your team, hardest? Data model drift, session bugs, or something in access control that only showed up after the fact?

Your AI-generated tests aren't testing your code. They're testing the AI's blind spots.

Dimitris Kyrkos — Fri, 04 Sep 2026 06:54:42 +0000

Intro

There's a pitch behind every "AI writes your tests too" workflow: more coverage, less manual toil, a safety net that used to take a sprint now takes minutes.

The pitch skips over what that safety net is actually made of. When the same model writes the implementation and the test suite, you haven't added a second, independent check. You've asked one reviewer to grade its own homework and handed you the green checkmark as if someone else had signed off.

The blind spot loop

A model reasons about a function once, forms an implicit set of assumptions (input shapes, timezone handling, what counts as "empty"), and writes the implementation against those assumptions. Ask the same model to write tests for that function, and it doesn't re-derive correct behavior from scratch. It writes tests against the same assumptions it just used to write the code. If it assumed dates always arrive as ISO strings in UTC, the implementation assumes that, and the tests assume it too. The suite goes green. The assumption is still wrong.

Tests that pass for the wrong reason

(Illustrative, not a specific case, but recognizable to anyone who's shipped an AI-generated suite.) Picture a discount-calculation function where the model assumes quantities are always positive integers. The implementation skips a negative-quantity check. The generated tests exercise 1, 5, and 100, because those are the "normal" values a model reaching for plausible test data will reach for. Nothing ever asks what happens at -1 or 0, because neither pass, the code or the tests, ever considered them worth asking about. Coverage tooling reports 100% on this function. The bug ships anyway.

Coverage becomes a false signal

High line or branch coverage from an AI-authored suite tells you the code paths were exercised, not that the right inputs exercised them. A suite can hit every line of a function and still never send it a null, an empty array, a duplicate key, or a value at a type boundary, if the author, human or model, never imagined those as possibilities in the first place. Coverage percentage was never built to detect a shared blind spot. It just counts what got tried.

What to keep human, and what to hand to AI

The fix isn't "stop using AI for tests." It's separating the two jobs testing actually does:

Defining correct behavior (the assertions) should come from a human who understands the spec or the business rule the function is supposed to honor, decided independently of however the implementation happens to work.
Generating volume and variety (mock data, randomized inputs, edge-case permutations) is exactly what AI is good at, and doing it well doesn't require the model to have written the implementation.
Human review time is best spent on boundary conditions specifically: zero, negative, empty, duplicate, malformed, concurrent, because that's statistically where both human and AI implementations tend to fail first.

This isn't really a testing problem. It's a correlated-error problem wearing a green checkmark. Two independent reviewers catch different mistakes because they're independent. One reviewer checking its own work twice catches the same mistakes it already missed, twice.

Where's your line? Do you let AI touch your test assertions at all, or only the scaffolding, mocks, fixtures, input generation, around them?

Semantic caching isn't a cost-saving hack. It's an admission that most "AI features" are FAQ bots in disguise.

Dimitris Kyrkos — Tue, 01 Sep 2026 09:10:45 +0000

Intro

There's a pitch behind every new AI-powered feature: it understands anything a user throws at it. Open-ended, flexible, genuinely intelligent.

The pitch is half true. What it leaves out is that in most production systems, "anything a user throws at it" collapses into the same twenty questions asked twenty different ways. A support bot doesn't get asked infinite variations of physics, it gets asked "what's your return policy," "how do I get a refund," and "can I send this back" on a loop, forever.

That gap, between the imagined variety of user queries and the actual repetition underneath it, is where the token bill lives.

The naive approach: every request hits the model

Say a team ships a support assistant. Every user message goes straight to a frontier model: embed the question, retrieve context, generate an answer, return it. It works. It's also expensive in a very specific way, identical intent, paid for from scratch, every single time.

(Illustrative, not a specific case, but recognizable to anyone who's watched an LLM API bill by day one versus day thirty.)

Exact-match caching almost works, then doesn't

The obvious fix is a cache: hash the incoming query, check for a hit, skip the model call if found. This works exactly once, for the exact same string. "How do I reset my password" and "forgot my password, help" are the same question and two different cache keys. Exact-match caching is a solution for a problem language doesn't actually have, users asking things identically.

Embeddings turn paraphrase into a solvable problem

Semantic caching replaces the hash with a vector. Embed the incoming query, run a nearest-neighbor search against previously answered queries, and if the closest match clears a similarity threshold, serve the cached response instead of calling the model at all. Below the threshold, call the model as normal and add the new query/response pair to the cache for next time.

This is the actual mechanism at work: not "the AI understood the question was similar," but a distance calculation in vector space with a cutoff you chose.

A stale cache is worse than no cache

Here's the failure mode nobody budgets for. A support answer gets cached in March. The return policy changes in April. The cache doesn't know that, it just has a vector close enough to keep matching, and it will confidently serve outdated information for as long as the entry lives. A cache without an expiration policy isn't a cost optimization, it's a bug that pays for itself to keep running.

Threshold tuning is the whole game

Set the similarity threshold too loose and you'll serve March's return policy answer to an April refund question, because the two "look" adjacent in vector space even though the real answer changed. Set it too tight and you get single-digit hit rates, because no two users phrase anything identically. There's no universal number here, only a number you have to measure against your own traffic.

Build it yourself, or don't

If you're at the scale where cache hit rate is a line item on your infra bill, and your domain has stable, well-defined intents (support, FAQ, internal tooling), rolling your own semantic cache with something like pgvector or Redis is a weekend project, not a research problem. If your queries are genuinely open-ended and low-repeat (creative generation, one-off analysis), you're optimizing for a hit rate that doesn't exist, and the caching layer is wasted engineering effort.

Semantic caching isn't really an AI technique. It's ordinary distributed-systems caching (TTLs, invalidation, cache keys) with an embedding standing in for the key. The AI part was never the hard part.

We ran into a version of this question building Cyclopt Companion's analyzers: a one-line diff shouldn't necessarily trigger a full re-analysis from scratch, and figuring out what counts as "close enough to skip" turned out to be the actual engineering problem, not the analysis itself.

What's your current cache hit rate on user-facing LLM calls, and have you actually measured it, or is it a guess?

AI autocomplete isn't a productivity tool. It's a judgment test you take every few seconds.

Dimitris Kyrkos — Fri, 28 Aug 2026 06:52:03 +0000

Intro

There's a pitch behind every AI coding assistant: it makes you faster. Fewer keystrokes, less boilerplate, more shipped features per sprint.

The pitch is half true. What it leaves out is the gap between a tutorial demo and a real codebase under real pressure. In a demo, every suggestion is correct because the demo was built to make the suggestion look correct. In production, the assistant doesn't know your architecture, your team's conventions, or the ticket you're actually trying to close. It just knows what tends to come next in code that looks like yours.

That gap is where the noise lives.

The instant-accept trap

Say a developer is mid-flow, wiring up a new endpoint. The assistant suggests a validation helper that looks reasonable, so they hit tab. It compiles, tests pass, they move on.

Three weeks later a teammate finds two nearly identical validation helpers in the codebase: one written by a human eight months ago, one autocompleted last sprint. Nobody meant to duplicate logic. The suggestion was locally correct and globally redundant, and nothing about "correct code that compiles" caught that.

(This is an illustrative scenario, not a specific incident, but most teams running Copilot or similar tools for more than a few months will recognize the shape of it.)

Architecture creep, one suggestion at a time

No single autocompleted line breaks your architecture. That's exactly the problem. An assistant trained on generic patterns will happily suggest a new abstraction, a new dependency, a new way of doing something you already do three other ways elsewhere in the codebase, because it has no visibility into "elsewhere." Accept enough of these one at a time and the codebase drifts into a dozen small dialects of the same idea, none of them wrong in isolation.

The review tax

The real cost isn't the code that's obviously bad, that gets caught. It's the code that's plausible enough to pass a quick glance and wrong enough to need real review time later. If you accept every suggestion without evaluating it against the code you already have, you're not saving time, you're deferring the thinking to code review, or worse, to whoever debugs it in production. Teams that measure this honestly often find they're spending more time reviewing and pruning generated code than they would have spent writing the smaller, more deliberate version themselves.

It's not an AI problem, it's a taste problem

Strip away the tooling and this isn't new. Junior engineers have always generated more code than senior engineers, because judgment about what not to write is a skill that takes time to build. AI assistants didn't invent that gap, they just made it faster to fall into, because the suggestion arrives before you've had time to ask whether you need it.

Autocomplete on, or on-demand only?

There's no universal right answer here, but there is a decision worth making deliberately instead of by default:

Always-on autocomplete works if you already have strong instincts for when to reject a suggestion, and you treat every accepted line as your own code, not the tool's.
On-demand AI for specific tasks (boilerplate, tests, migrations) forces a moment of intent before you invoke it, which some teams find keeps architecture decisions in human hands.
Research and planning only keeps AI out of the diff entirely and uses it to think faster, not to type faster. (We lean on this mode a lot while building Cyclopt Companion, mostly to keep the assistant out of the actual diff until a human has decided the shape of the change.)

None of these are wrong. They're trade-offs between speed and friction, and the right one depends on how much you trust your own review discipline in the moment.

So: do you keep autocomplete on at all times, use AI only on-demand for specific tasks, or limit it to research and planning? And has your answer changed since you started using these tools?

AI-Generated Code Doesn't Have a Readability Problem. It Has a Style-Enforcement Problem Wearing an AI Hat.

Dimitris Kyrkos — Tue, 25 Aug 2026 13:18:22 +0000

Intro

Ask an AI assistant to "handle the checkout flow" and it will hand you a working function in about four seconds. Validate the cart, call three different APIs, format a receipt, log the analytics event, catch whatever errors show up, all in one block, three levels of nesting deep. It runs. It passes the one test anyone bothered to write. And it is, structurally, a small readability crisis waiting for whoever opens that file next.

That gap, between code that works and code a human can actually follow six months later, is where most of the real cost of AI-assisted development quietly accumulates. Here's where it actually shows up. (Illustrative composites drawn from common patterns, not specific incidents.)

The function that does six things because nobody told it not to

A generated function rarely sets out to do too much. It just keeps absorbing responsibility one prompt at a time: first it validates input, then someone asks it to also handle a retry, then to also log the outcome, then to also format the response for the frontend. Each addition looks reasonable in isolation. Read top to bottom six weeks later, it's a single function holding four unrelated jobs, and splitting it back apart means first reverse-engineering which lines belong to which job.

Names that describe the prompt, not the domain

Generated code tends to name things after the immediate task rather than the concept it represents: data2, tempResult, processedItems, handleStuff. None of these are wrong in the sense of breaking anything. They're wrong in the sense that a teammate reading the code six months from now has to run it mentally just to figure out what tempResult actually holds, instead of the name just telling them.

A slightly different helper function, invented every time

Ask a model to format a date in one file and it writes formatDate. Ask it again in another file, in the same session even, and it might write toDateString, doing almost the same thing with a slightly different edge case handled. Nothing is technically duplicated, so no linter flags it, but the codebase slowly fills with near-identical helpers that all do roughly the same job slightly differently, because each generation has no memory of what already exists two files over.

Style that resets at every file boundary

File A uses early-return guard clauses. File B nests every conditional three deep because that's what was statistically nearby in training for that particular pattern. Neither is "wrong" on its own, a reviewer skimming one file at a time won't necessarily flag it, but navigating the codebase starts to mean re-learning the local dialect every time you open a new file, because there isn't one.

None of this is a code-quality problem in the traditional sense, where someone wrote something sloppy and a linter catches it. It's a missing style contract problem: nothing external is constraining the model toward the conventions your team already agreed on, so by default it reaches for whatever's statistically common across its training data, which is rarely what's locally correct for your codebase.

So what do you actually do about it? One option is writing an exhaustive style guide and hoping every prompt includes enough of it, which doesn't scale past a few files and quietly rots the moment someone forgets to paste it. The other is treating readability as something enforced at the commit gate, the same way you'd enforce tests passing, independent of whether a human or a model wrote the line. Prompts don't have memory. Commits do. That's really the whole argument for moving readability enforcement from "hope the prompt was good" to "verify the commit is."

How is your team actually enforcing readability on AI-generated code right now, a style guide baked into the prompt, a linter, code review, or honestly, nothing yet?