DEV Community: Dimitris Kyrkos

Using AI to Code Isn't the Risk. Not Understanding What It Shipped Is

Dimitris Kyrkos — Mon, 17 Aug 2026 07:42:25 +0000

Intro

There's a gap between the way AI-assisted coding gets demoed and the way it actually gets used under a deadline. In the demo, the model writes a function, the developer reads it, understands it, and merges it. Under a deadline, the model writes a function, the developer skims it, it looks plausible, and it merges. Same tool, two completely different outcomes, and the difference isn't visible in the diff.

Call the first one cognitive assistance: the AI removes typing, not thinking. Call the second one cognitive offloading: the AI removes thinking, and the developer just does the typing that's left, mostly pressing "accept." Both look identical in a pull request. They only diverge later, when something breaks and someone has to explain why the system does what it does.

Here's where that gap actually shows up in production. (Illustrative composites drawn from common patterns, not specific incidents.)

The schema nobody actually reasoned about

A developer asks an AI assistant to generate a migration adding a new table with two foreign keys. It looks right, it runs locally, tests pass, it ships. Nobody on the team, including the person who wrote the migration, actually worked through the access pattern the new table would see in production. Three months later, a dashboard query against that table starts timing out under real traffic, because there's no index on the column it's actually filtered by, a detail that would have been obvious to anyone who'd designed the schema by hand instead of approving one.

The stack trace that got forwarded, not read

Someone hits a NullPointerException, pastes the trace into an AI chat, gets back a suggested null check, adds it, ships it. The exception stops. Two sprints later, a related bug shows up somewhere downstream, because the null check treated a symptom, a race condition further up the call stack, not the cause. Nobody connects the two, because nobody who touched the first fix ever understood what was actually racing.

The architecture nobody in the room can defend

In a retro, a tech lead asks why a service makes three synchronous calls to downstream services instead of publishing to a queue. Nobody has an answer, because the pattern was generated during a crunch week, skimmed, and merged. It's not that the pattern is necessarily wrong, it's that no one currently on the team could tell you whether it's wrong, which means no one can safely change it either.

Cognitive offloading isn't really an AI problem. It's a code review discipline problem wearing an AI hat. Teams that had weak review habits before AI tools now get weak review at a much higher volume and velocity, which turns a slow leak into a flood.

A quick gut check, if you want one: before you merge AI-generated code, can you explain it to a teammate without opening the chat history again? Could you have arrived at this approach yourself given more time? Do you know why this pattern and not an obvious alternative? If the honest answer to any of those is no, that's not a blocker, it's just useful information about which side of the line you're currently standing on.

Where do you draw the line between assistance and offloading on your team, is it an explicit rule, part of your review process, or just a gut feeling that kicks in after something's already gone wrong?

Your model doesn't need to pass the bar exam. It needs to parse a log file.

Dimitris Kyrkos — Tue, 04 Aug 2026 11:16:44 +0000

Intro

Every few weeks, another frontier model claims a new benchmark, better reasoning, longer context, higher scores on tests built to measure how humans think. None of that is irrelevant, but it's solving a problem a huge share of enterprise workloads don't actually have. Parsing a structured log line, validating a field against a schema, classifying a support ticket into one of six categories - none of that was ever going to need a model that can debate philosophy or pass the bar exam. It needs a model that's fast, cheap, and right, every time, on a narrow task. That's a different design goal than the one the frontier race is optimizing for, and it points toward small, specialized, locally hosted models instead of the next big release. Below are four places where the gap between "benchmark-optimal" and "production-optimal" actually shows up. (Illustrative composites, not case studies from a specific client.)

Latency budgets don't care how smart the model is

Picture a fraud-detection pipeline calling a hosted frontier model on every transaction. It works fine in testing. Under peak load, p95 latency starts spiking, not because the model reasons badly, but because every call is a network round trip through someone else's queue, competing with every other tenant's traffic on that provider that day. A distilled model of a fraction of the size, running on the same box as the service that calls it, doesn't have a network hop to blame. Latency stays predictable in the low tens of milliseconds because there's no shared queue to wait behind.

Your data boundary is only as strong as your last API call

A team building on patient or financial records sends that data to a third-party endpoint for every inference call. It works, until a compliance review asks a simple question: where does this data physically go, who retains it, and for how long. If the answer is "a provider's infrastructure, under their retention policy," that's a boundary the team doesn't fully control and can't fully audit. A small model running inside their own perimeter turns that into a non-question. There's no external boundary to explain, because the data never left.

A pricing or deprecation decision made by someone else is not a risk you control

A workflow built on top of a hosted model API works well for a year, until the provider raises prices, changes rate limits, or deprecates the exact model version the workflow was tuned against. None of that is a bug in the team's code. It's a business decision made by a company they don't work for, and it forces an unplanned re-engineering effort on someone else's timeline. A locally hosted, version-pinned model doesn't have a roadmap owned by another company deciding when it stops being supported.

A model fine-tuned on your schema beats a generalist prompted around it

Ask a general-purpose frontier model to validate rows against a company's actual database schema, and it will usually get it right, and occasionally hallucinate a plausible-sounding field name that doesn't exist, because it's reasoning from general knowledge about how schemas tend to look, not from the ground truth of this one. A small model fine-tuned on the company's real schema isn't guessing at a pattern, it's seen the exact structure it's being asked to validate against.

Every one of these is really the same story with a different failure mode

A task with a narrow, well-defined shape got handed to a general-purpose tool built to be good at everything, at the cost of being cheap, fast, and predictable at any one specific thing.

Build vs. integrate: when a small local model actually wins

If the task is narrow and repetitive with a stable shape, log parsing, schema validation, ticket classification, a small specialized or fine-tuned model tends to win on latency, cost, and data boundaries. If the task involves genuine ambiguity, novel reasoning, or synthesizing loosely related domains on the fly, a frontier model is still the better tool. A useful test in between: could a domain expert write down the rules for what "correct" looks like on this task? If yes, that's a strong signal a small local model can be trained or fine-tuned to do it more cheaply and predictably than a general model can be prompted to.

Where's the line for you? At what point does reaching for the biggest available model stop being ambition and start being the wrong tool for the job?

The all-purpose agent isn't an architecture. It's a single point of failure with a system prompt.

Dimitris Kyrkos — Fri, 31 Jul 2026 09:06:04 +0000

Intro

In a demo, one agent that "does everything" looks like impressive economy: one prompt, one API call, one mental model. Nobody's testing it against thousands of edge cases a day, and nobody's paying for the tokens burned parsing forty unrelated instructions to answer a two-line question. In production, that same design is where teams spend their first real outage. Below are four failure modes that show up once a monolithic agent hits real traffic. (Illustrative composites, not case studies from a specific client.)

The system prompt that nobody can safely edit

Picture a support agent that started as "answer product questions" and grew, feature request by feature request, into a 4,000-word system prompt covering billing, refunds, technical troubleshooting, and tone guidelines for three different customer segments. Adding a new instruction for edge case #41 quietly changes how the model handles edge case #12, because both are competing for the same attention budget in the same call. Nobody can point to which line caused the regression, because there's no isolation between concerns, only proximity.

Every request pays for capabilities it doesn't use

A single do-everything agent charges the same token bill for a request that just needs a database lookup as it does for one that needs careful reasoning about a refund policy exception. Say a team's simplest, highest-volume intent, "what's my order status," routes through the full monolithic prompt anyway. That's paying premium reasoning costs, on every call, for a task a five-line function could handle for a fraction of the price.

One bad instruction degrades everything downstream

Because a monolithic agent handles routing, task execution, and formatting in a single inference pass, a subtle drift in one part of its behavior, say it starts hedging more on refund questions after an unrelated prompt tweak, has no boundary to stay contained inside. There's no seam where you could catch it before it reaches the user, because the "component" that's misbehaving is the entire agent.

Testing becomes a probability exercise, not an engineering one

With a single-purpose function, you write a test, you know the input, you assert the output. With a 4,000-word do-everything prompt, "testing" often means running the same conversation a dozen times and hoping the failure rate stays under some tolerable threshold. That's not a test suite. That's a weather forecast.

A multi-purpose agent isn't one decision. It's twenty, made by an LLM, at inference time, with nothing watching any of them.

Every one of these failure modes comes from the same root cause: collapsing routing, task execution, and state management into a single non-deterministic call and hoping the model sorts it out consistently, every time, forever. It won't, not because the model is bad, but because that's not what a single inference pass was ever built to guarantee.

Route it, don't merge it

The fix isn't a smarter prompt. It's separating what genuinely benefits from a language model's judgment from what doesn't. A small classifier decides intent. Specialized, single-purpose functions handle each isolated task, several of which may not need an LLM at all. Deterministic code owns routing, state, and final formatting, the parts where you actually want predictability, not creativity. Each piece is small enough to unit test on its own, which is the property the monolith could never give you.

Where's the line for you, at what point does "just add another instruction to the prompt" stop being the pragmatic choice and start being the thing you'll be debugging at 2am?

"Unlimited context" is not a feature. It's technical debt with better marketing.

Dimitris Kyrkos — Mon, 27 Jul 2026 12:08:59 +0000

Intro

Model providers keep shipping bigger context windows: 100k tokens, 200k, over a million in some cases. The marketing pitch is simple: paste in everything, the model will figure out what matters. It's a seductive idea, and it's the wrong default for anything that has to run in production.

Here's the gap. In a tutorial or a demo, "long context" means pasting a document and asking a question once. Nobody times it, nobody pays for the tenth call, and nobody notices what got ignored. In production, the same request runs thousands of times a day, against a system that has to be fast, cheap, and correct every single time. The capacity to accept 100k tokens says nothing about whether stuffing that much into every request is a good idea. Below are four failure modes that show up once the naive approach hits real traffic. (The scenarios are illustrative composites, not case studies from a specific client.)

The latency tax nobody notices until it's live

Say a support tool feeds the model the full history of a customer's last 40 tickets on every single message, "just in case it's relevant." In the demo, that's one call, and it feels instant. In production, every reply now takes 10-12 seconds instead of 2, because the model has to process tens of thousands of tokens before it writes a word. Users don't experience "more context." They experience a slow bot, and slow bots get abandoned mid-conversation.

The margin killer

Token costs compound in a way that's easy to miss in a pilot and brutal at scale. A team billing customers per seat, but paying per token behind the scenes, can end up with COGS that scale with context size, not with usage. If every request carries the same bloated payload regardless of whether that history is relevant, the unit economics quietly break as the customer base grows, well after the pricing model has already been sold.

Lost in the middle

Even when the tokens are technically "in the window," attention isn't uniform across it. Models are demonstrably better at using information near the start and end of a context than information buried in the middle. Picture a compliance assistant given a 100-page policy document, where the one answer relevant to a question sits on page 47. The model can have "read" every token and still miss it, because being in context and being attended to are not the same thing.

Noise that turns into hallucination

Retrieval systems that grab too much, "let's include the top 15 chunks just to be safe," aren't playing it safe. Excess context isn't neutral filler. Loosely related documents give the model more material to blend, misattribute, and confidently combine into an answer that sounds right and isn't. The system doesn't fail loudly. It fails convincingly.

Context management is data engineering wearing an LLM's clothes

Every one of these failure modes is a symptom of the same root cause: treating context as an unlimited bucket instead of a resource with a cost and a decay curve. The fix isn't a bigger window. It's a pipeline: chunking, filtering, ranking, summarizing, retrieving only what the current task actually needs. That's not prompt engineering. It's the same discipline that's underpinned good search and recommendation systems for a decade, applied to a new kind of consumer.

Build it or buy it

If context management is core to your product's differentiation, and it usually is once you're past the demo stage, it's worth owning the retrieval and filtering layer directly rather than treating it as an afterthought bolted onto whichever framework shipped a quickstart. Off-the-shelf vector stores and orchestration libraries are a reasonable starting point for early prototypes, but the ranking logic, the summarization strategy, and the decision about what's relevant to a given task are where the actual product value lives. That's not something you want to be entirely dependent on someone else's defaults for, once you're optimizing for cost and correctness at scale.

What's the worst context-bloat bug you've shipped or debugged? Curious what patterns other people have run into.

Banning ChatGPT Won't Fix Your Shadow AI Problem. It'll Just Hide It.

Dimitris Kyrkos — Thu, 23 Jul 2026 09:32:49 +0000

Intro

Every engineering org has a policy about which AI tools developers are allowed to use. Every engineering org also has a Shadow AI problem, whether leadership has noticed it yet or not.

The gap between the two is predictable. Security approves one internal tool, or none at all. Developers still have deadlines, still get stuck, still need to paste a stack trace somewhere and ask "why is this failing." If the sanctioned option doesn't exist, is slow, or is worse than what's publicly available, developers go find their own. Quietly.

What actually gets pasted into public chat windows

This is where it gets concrete. A developer debugging a failing integration test copies the full stack trace into a public AI chat window to ask what's wrong. The stack trace includes a database connection string. Nobody flagged it because nobody was watching, the tool has no audit log and no data retention policy the company controls.

A different developer is stuck on a tricky business rule and pastes the actual proprietary algorithm, the one the company patented, into a public model to get a "cleaner implementation." That algorithm may now sit inside a public training corpus, permanently, with no way to un-paste it.

A third developer, working through a customer support bug, pastes real customer records, including names, emails, and account details, into a chatbot to understand a data corruption issue. That's a compliance violation the moment it happens, whether or not anyone downstream ever notices.

None of these developers think of themselves as a security risk. They think of themselves as someone trying to ship on time with the tools that actually work.

Why banning the tools doesn't work

The instinct from leadership is usually to block the domains at the network level and call it solved. This doesn't remove the underlying need, it just removes the visibility. Developers switch to personal devices, personal accounts, or a browser extension nobody in IT has heard of. The paste-your-code-into-a-public-model behavior doesn't stop. It just becomes invisible to the company that's supposed to be accountable for it.

That's arguably worse than the original problem. An org with visible Shadow AI usage at least knows it has a problem. An org that's driven the behavior underground has the same exposure with none of the ability to see or measure it.

The actual failure is a tooling gap, not a discipline gap

Developers aren't circumventing policy because they're careless. They're circumventing it because the approved path is slower, worse, or nonexistent, and the unapproved path solves their actual problem in thirty seconds. Every time an organization treats this as a training or discipline problem instead of a tooling problem, it gets the same result: policy on paper, Shadow AI in practice.

The fix isn't a stricter acceptable-use policy. It's giving developers an approved tool that's actually good enough that going around it stops being worth the trouble, one that keeps proprietary code, schemas, and customer data inside a boundary the company actually controls, with the visibility to know it's being used instead of guessing.

Anyone else seeing this play out on their team? Is it a policy problem, a tooling problem, or both?

RAG isn't an AI problem. It's a data engineering problem wearing an AI hat.

Dimitris Kyrkos — Tue, 21 Jul 2026 11:22:54 +0000

The tutorial-to-production gap

Every RAG tutorial follows the same arc. Load some documents. Chunk them. Embed them into a vector database. Wire up a retrieval step before the LLM call. Ask a question, get a grounded answer. Twenty minutes, looks great, feels like the future.

Then you try to run it on real data, with real users, at real scale, and you discover that the AI part of RAG was the easy part. The hard part is everything the tutorial skipped.

The problems that surface after the demo

Document lifecycle management

The tutorial loaded documents once. Production data changes constantly. Documents get updated, versioned, deprecated, deleted. Your vector database now has embeddings for three versions of the same policy document. The model retrieves chunks from the version that was superseded last quarter and confidently presents outdated information as current.

Nobody in the tutorial mentioned that you need a sync pipeline that tracks document state, invalidates stale embeddings, handles partial updates without re-embedding the entire corpus, and deals with the fact that deleting a document from the source doesn't automatically delete its chunks from the vector store.

This isn't an AI problem. This is the same data staleness problem that search engines have solved for decades. If you've never built a search index that handles updates and deletions, your RAG system will serve stale data and nobody will know until a user notices the answer references a policy that changed six months ago.

Chunking that loses context

The default chunking strategy in most tutorials is "split by token count with some overlap." This works on clean, well-structured documents. It fails on real documents in predictable ways.

A table gets split across two chunks. The header is in chunk one, the data is in chunk two. Neither chunk is useful alone. A paragraph references "the conditions listed above" but "above" is in the previous chunk. A legal clause has an exception three paragraphs later that changes the meaning entirely, but the retriever only surfaces the clause, not the exception.

The chunking strategy determines what the model can see. Bad chunking means the model gets fragments that look complete but are missing the context that changes the answer. The model doesn't know it's missing context. It generates a confident response based on incomplete information. The user doesn't know either. Everyone trusts the system until someone manually checks and discovers the answer was based on half a table.

Getting chunking right requires understanding the document structure: section boundaries, table integrity, cross-references, hierarchical relationships between headings and content. This is document engineering, not prompt engineering.

Semantic search isn't enough

Vector similarity search is good at finding conceptually related content. It's bad at finding exact matches. A user asks "what is the maximum liability under contract 2024-0847?" The embedding search returns chunks about liability in general, about similar contracts, about maximum limits in different contexts. The exact contract number might not even surface because embedding similarity doesn't prioritize exact string matches.

Production RAG systems need hybrid retrieval: semantic search for conceptual relevance, keyword/BM25 search for exact matching, and a ranking layer that combines both. Most tutorials only show the semantic path because it's the one that uses embeddings, which is the novel part. The keyword path is "boring traditional search" and gets skipped.

The irony is that the boring traditional search part is what determines whether the system can actually answer specific questions about specific things. Semantic search finds the neighborhood. Keyword search finds the address.

Access control is where it gets really hard

The tutorial assumed everyone can see everything. Production data has access controls. Different users have different permissions. A document that's visible to legal shouldn't surface in retrieval for marketing. Patient records should only be retrievable by authorized clinicians. Financial data has regulatory constraints on who can access it.

This means your retrieval layer needs to enforce the same ACLs as your source systems. At query time. For every request. Without being so slow that the response takes 30 seconds.

Most vector databases weren't designed with fine-grained access control in mind. Bolting ACLs onto a system that doesn't natively support them creates either security gaps (filtering after retrieval, which means unauthorized chunks were still read) or performance problems (filtering before retrieval, which limits the candidate pool and degrades relevance).

Getting this right is a security and access management problem, not an AI problem.

RAG is search infrastructure with an LLM on top

The pattern that keeps emerging: every hard problem in production RAG is a problem that existed before LLMs.

Document lifecycle management is a search indexing problem. Chunking is a document processing problem. Hybrid retrieval is a search relevance problem. Access control is an authorization problem. Monitoring for quality degradation is an observability problem.

The LLM is the last mile. It takes the retrieved chunks and generates a natural language response. That part works remarkably well. Everything upstream of it, the part that determines what chunks the model actually sees, is traditional data engineering and search infrastructure.

If your team doesn't have experience with search indexing, document processing pipelines, and access control at the data layer, the RAG system will struggle. Not because the AI is bad, but because the retrieval is bad, and retrieval is a solved problem in the search world that most AI teams are rediscovering from scratch.

The build vs integrate decision

Before building RAG from scratch, check whether your problem is actually "I need semantic search over my documents" or "I need a search engine." If it's the second one, mature search infrastructure (Elasticsearch, Solr, or even a well-configured database with full-text search) might get you 80% of the way there without the operational complexity of a vector database, embedding pipeline, and chunking strategy.

RAG makes sense when you genuinely need the LLM to synthesize information from multiple sources into a coherent answer. If your users are asking specific questions that have specific answers in specific documents, traditional search with good ranking might be the simpler tool.

Same principle as the last post: start with the friction, not the technology.

What's been the hardest production RAG problem your team has hit? Was it the AI part or the data engineering part?

The fallacy of "AI-first." Start with the friction, not the technology.

Dimitris Kyrkos — Fri, 17 Jul 2026 13:01:56 +0000

The label that gets the sequence backwards

"AI-first" has become a branding exercise. Startups put it in their pitch decks. Enterprise teams put it in their strategy documents. Innovation labs put it on their slide templates.

The problem isn't ambition. The problem is sequence. "AI-first" starts with the technology and goes looking for problems to apply it to. That's backwards, and it leads to a specific, predictable pattern of failure.

What happens when you start with the technology

When the starting question is "how can we use AI here?" the team works backwards from the solution to find a problem worth solving. This sounds productive. In practice, it creates three failure modes that show up consistently.

Over-engineered systems. A team builds an LLM-powered workflow to classify support tickets. The model requires prompt engineering, embedding infrastructure, a vector database, and ongoing fine-tuning. The accuracy settles around 91%. A senior support agent looks at the same problem and says "we could do this with five keyword rules and a regex." The keyword approach would have been 95% accurate, cost nothing to run, and taken a day to build. But nobody asked whether AI was the right tool because the mandate was AI-first.

Expensive fragility. AI systems have operational overhead that traditional software doesn't. They hallucinate. They drift. They require monitoring for quality degradation. They cost real money per inference. When AI is the right tool, that overhead is justified by the value it creates. When AI was forced into a workflow where a simpler solution would have worked, you're paying the operational tax of an AI system for a problem that didn't require one.

Maintenance burden nobody scoped. The prototype works in the demo. The team ships it. Six months later, the model's performance has degraded because the data distribution shifted. The prompt that worked in March produces different results in September. The embedding index needs rebuilding. The vector database needs scaling. None of this was budgeted because the initial estimate was based on getting it working, not on keeping it working.

Start with the friction instead

The teams I've seen build the most effective AI systems don't start with AI. They start with a specific operational friction and then evaluate whether AI is the simplest tool to resolve it.

Where is the operational bottleneck? Not "where could AI add value" but "what is actually slow, expensive, or error-prone right now." The bottleneck is the starting point because it's concrete, measurable, and has a clear before/after.

What is causing the delay in decision-making? Sometimes the delay is that a human needs to process information that arrives faster than they can read it. AI is excellent for that. Sometimes the delay is that two departments use different ticket systems and nobody can see the full picture. AI won't fix that. A shared dashboard will.

Is AI actually the simplest tool for this? This is the question that gets skipped most often. A database query that runs in milliseconds. A rule engine that handles the known cases. A spreadsheet formula that does the calculation. A cron job that sends the reminder. These aren't exciting. They're also not fragile, don't hallucinate, don't require monitoring for drift, and don't cost per inference.

The most impressive engineering is the code you didn't write

There's a cultural problem underneath the "AI-first" label. It implies that using AI is inherently more sophisticated than not using it. That's wrong. Using AI where it's not needed is over-engineering, which is the opposite of sophistication.

The most effective engineering decisions are often the ones where someone looked at a problem and said "we don't need AI for this." Not because they're against AI, but because they evaluated the problem honestly and chose the tool that matched the complexity of the problem, not the complexity of the tool.

AI is powerful when applied to problems that actually require it: ambiguous inputs, unstructured data, pattern recognition across large datasets, natural language understanding, tasks where the decision space is too large for rules. For everything else, the simpler tool is the better tool.

Have you seen "AI-first" mandates lead to over-engineered solutions on your team? What's the best example of a problem where AI was proposed but a simpler solution turned out to be better?

AI frameworks make the first 10% feel like magic. The other 90% is where they break you.

Dimitris Kyrkos — Tue, 14 Jul 2026 12:53:10 +0000

The magic window

Every AI framework ships with a demo that looks incredible. Spin up an agent in five lines. Chain three tools together in ten. Build a chatbot with memory in fifteen minutes. The getting-started experience is deliberately frictionless. And it works. You feel productive immediately.

Then you try to do something real.

Where the abstractions become walls

The problem isn't that these frameworks are badly built. Many of them are impressively engineered. The problem is that they're designed to optimize for the first 10% of development at the cost of the remaining 90%.

That remaining 90% is where you need to manage raw API payloads when the abstraction doesn't expose the field you need. Where you need custom retry logic because the default exponential backoff doesn't account for the rate limit patterns your specific provider uses. Where you need to track token costs per user, per session, per feature, and the framework only gives you aggregate totals. Where an agent chain fails silently at step four and you're debugging through three layers of abstraction to figure out what state was passed between steps.

Heavy abstractions help when everything works. They become walls when something doesn't. And in production, something always doesn't.

The debugging tax

This is the part that hits hardest in practice. When your lightweight wrapper breaks, you read the error, look at your code, and fix it. The call stack is yours. The state is visible. The flow is explicit.

When a framework breaks, you're reading through someone else's abstractions trying to figure out what happened between your input and the error. The state got transformed somewhere inside a chain you didn't write. The retry logic fired but you can't tell how many times because it's handled internally. The error message references an internal class name that doesn't appear in the documentation.

The time you saved in the first 10% gets paid back with interest during debugging. And debugging is where production teams spend most of their time.

The cost tracking problem nobody mentions

This one is specific to AI infrastructure but it matters a lot at scale. Most frameworks treat API calls as an implementation detail that happens behind the scenes. That's fine for a prototype. In production, you need to know exactly how many tokens each feature consumes, per user, per session, broken down by model. You need to set cost ceilings per workflow. You need to alert when a chain enters a retry loop that's burning through your budget.

Frameworks that abstract away the API layer also abstract away the cost visibility. You find out what something costs when the invoice arrives, not when the code runs. By then the budget damage is done and the forensics to figure out which workflow caused it requires instrumenting the framework from the outside, which is harder than building the instrumentation into your own code from the start.

When to build your own

Not always. But more often than the ecosystem wants you to believe.

If your use case is straightforward and matches the framework's happy path, use the framework. If your use case involves custom retry logic, granular cost tracking, complex state management across agent chains, or any production concern that the framework treats as an edge case, you're going to fight the abstractions more than they help you.

A lightweight wrapper around the raw API that you wrote, you understand, and you can debug in five minutes is often faster and safer than inheriting someone else's opinionated framework and spending days working around the opinions that don't fit your use case.

The architecture principle

Keep your architecture simple, explicit, and transparent. Every layer of abstraction you add is a layer you have to debug through when something breaks. Every opinion a framework encodes is an opinion you either agree with or work around. The magic of the first ten minutes is not worth the friction of the next ten months if the abstractions don't match your production reality.

The best AI infrastructure I've seen in production is usually the simplest. Thin wrappers, explicit state, visible costs, debuggable chains. Not impressive to demo. Extremely effective to operate.

How much of your AI stack is framework vs custom? And which part causes more production incidents?

The AI conversation is shifting from "what can it do" to "can we rely on it"

Dimitris Kyrkos — Tue, 07 Jul 2026 10:02:16 +0000

The capability phase is over

For the past two years, the AI conversation has been about capability. What can the model do? How many tokens? How fast? Can it write code, generate tests, build a full feature from a prompt?

That phase answered itself. The models are capable. Nobody seriously doubts that anymore.

The next phase is about a different question entirely, and it's one that most teams are already running into even if they haven't framed it this way: can we rely on it?

Capability vs reliability are different problems

A model that generates brilliant code unpredictably is less useful than a model that generates good code consistently. This sounds obvious written down. In practice, most teams are still optimizing for the first one.

The distinction matters because capability is evaluated in demos and benchmarks. Reliability is evaluated in production over months. A system that works impressively 92% of the time and fails silently 8% of the time is more dangerous than a system that works predictably 100% of the time within a narrower scope, because the 8% failure rate trains the team to distrust the output and manually verify everything, which eliminates the efficiency gains the tool was supposed to provide.

The five questions that actually determine adoption

When teams move past the demo phase and try to use AI in real workflows, these are the questions that determine whether it sticks or gets quietly abandoned.

Can it operate consistently?

Not "does it produce good output sometimes" but "does it produce predictable output under the same conditions." Consistency is what allows teams to build processes around a tool. If the output varies significantly between runs on the same input, every downstream step needs a human checkpoint, and you've just added work instead of removing it.

Can it integrate into existing workflows?

The best model in the world is useless if it doesn't fit into how the team actually works. Integration means connecting to the repo, CI pipeline, review process, and ticketing system. Not as a separate step people have to remember, but as something embedded in the flow they already follow. Every extra click or context switch between the AI tool and the real workflow is friction that erodes adoption.

Can it scale without creating new risks?

A tool that works for one developer on one project is different from a tool that works across twenty teams shipping to production. Scaling introduces new failure modes: inconsistent outputs across teams, security exposure from wider access, dependency on a service that becomes a single point of failure, cost that grows faster than the value. The risk profile at scale is fundamentally different from the risk profile of a pilot.

Can teams trust it under real conditions?

Trust isn't a feeling. It's the result of repeated experience where the tool did what was expected and didn't do what wasn't expected. Trust builds slowly and breaks instantly. One incident where the AI introduced a security vulnerability or silently produced wrong business logic can set adoption back by months, regardless of how well the tool performed the other 99% of the time.

Can it continue delivering value six months after deployment?

This is the one that kills most AI adoption. The initial excitement is high. The first sprint is productive. Then the novelty wears off, the edge cases accumulate, the model drifts, or the codebase evolves past what the tool was configured for, and the team starts working around it instead of with it. Long-term value requires maintenance, recalibration, and ongoing investment. Tools that are deployed and forgotten degrade into noise.

Why this shift matters for developers

The practical implication is that the teams winning with AI in 2026 aren't the ones with the most powerful models. They're the ones that built reliable systems around the models.

Reliable means: outputs are consistent and verifiable. Integration is seamless with existing tools. Scaling doesn't introduce surprise risks. The team trusts it because it earned that trust through months of predictable behavior. And it's still delivering value because someone is actively maintaining the integration.

That's not exciting work. It's not demo-worthy. But it's the work that separates AI that sticks from AI that was tried and abandoned.

A brilliant system that behaves unpredictably will always face resistance. A reliable system becomes part of how the organization works.

Is your team evaluating AI tools on capability or reliability? And which one actually determined whether the tool stuck?

The biggest barrier to enterprise AI adoption isn't the model. It's trust in everything around it.

Dimitris Kyrkos — Fri, 03 Jul 2026 06:23:54 +0000

The trust problem nobody scopes correctly

When companies talk about trust in AI, they almost always mean trust in the model. Is the output accurate? Is it hallucinating? Can we rely on what it says?

Those are valid questions but they're the wrong starting point. The trust that actually determines whether AI gets adopted or quietly abandoned inside an organization isn't about the model. It's about the system surrounding it.

The four questions that determine

Every team evaluating AI in a production workflow eventually runs into the same four questions. Not about model quality. About operational control.

Can we understand the outputs? Not just "does the answer look right" but can someone on the team explain why this output was produced and whether it's appropriate for this specific context. An AI that generates correct-looking code or recommendations that nobody can verify is a system that runs on hope. Hope doesn't survive the first incident.

Can we validate the decisions? When the AI recommends an action or generates an output that feeds into a business process, is there a way to check it against the actual requirement? Or does the team just trust the output because questioning it is harder than accepting it? The second one is more common than anyone admits.

Can we intervene when needed? When something goes wrong, how fast can a human step in? Is there a kill switch? Is there a fallback path? Or does the AI output flow directly into downstream systems with no circuit breaker? The teams that skip this question are the ones that discover the answer during an incident.

Can we trace what happened afterward?When an AI-generated decision produces a bad outcome, can you reconstruct the chain? What input went in, what output came out, what context was available, what wasn't? Without traceability, post-mortems hit a dead end, and the same failure happens again.

Why opaque systems don't survive real operations

There's a tempting argument that opacity is fine as long as the system performs well. Just let it run, measure the outcomes, and intervene when metrics drop.

This works in demos. It doesn't work in production.

Production has auditors who need to understand what happened and why. It has regulators who need traceability. It has on-call engineers who need to debug failures at 3 am without the AI session that produced the output. It has customers who deserve an explanation when something goes wrong that isn't "the AI did it."

Opaque systems scale efficiency. They also scale uncertainty. And uncertainty compounds. Every decision the team can't trace, every output nobody can explain, every intervention that wasn't possible because there was no hook for it, those accumulate into a trust deficit that eventually kills adoption.

The teams that abandon AI tools rarely do so because the model was bad. They do it because the operational uncertainty became intolerable.

What trust actually looks like in practice

The teams I've seen sustain AI adoption long term share a few things.

Outputs are explainable. Not in a theoretical "the model uses attention mechanisms" way. In a practical "here's what it did, here's the input it used, here's why this output makes sense or doesn't" way. Someone on the team can always answer "why did the system do this."

Decisions are checkable. There's a validation layer between the AI output and the action it triggers. Sometimes automated, sometimes human, but never absent. The AI proposes. Something else confirms.

Intervention is possible. There's always a way to override, roll back, or bypass the AI. Not as a theoretical capability but as a tested, documented path that someone has actually used. If the override path only exists in theory, it doesn't exist.

Traceability is built in. Inputs, outputs, context, and decisions are logged in a way that supports after-the-fact reconstruction. When something goes wrong, the investigation has material to work with instead of hitting a wall.

The real adoption blocker

The challenge with enterprise AI is no longer access to models. Everyone has access. The challenge is preserving operational clarity as AI takes on more of the workflow.

Organizations adopt AI faster when the system around it is transparent, checkable, and traceable. Not because they don't trust the model, but because trusting the model isn't enough. They need to trust the whole system. And that trust is earned by design, not by performance metrics.

How does your team handle trust in AI systems? Is it designed in, or is it assumed until something breaks?

Attackers are hijacking exposed AI endpoints to run offensive operations. No exploit needed.

Dimitris Kyrkos — Wed, 01 Jul 2026 11:55:36 +0000

The attack doesn't require a compromise

There's a new attack pattern getting documented that every team running self-hosted AI infrastructure should know about.

Between March and May 2026, researchers at Zenity observed three separate campaigns where attackers used exposed LLM endpoints as compute for their own offensive AI operations. Not by exploiting a vulnerability.Not by compromising credentials. Just by knowing where the endpoint was and sending it requests.

The targets were Ollama and LiteLLM instances, two of the most common tools for self-hosting LLMs. The attack is embarrassingly simple: find an exposed endpoint, point your AI agent at it, and use someone else's infrastructure to power your operations.

Why this works

The root cause is default configurations that prioritize ease of setup over security.

Ollama ships with no built-in authentication on its default port (11434). It defaults to localhost but is commonly reconfigured to listen on all interfaces so other services can reach it. Once it's exposed, anyone who finds it can send inference requests.

LiteLLM's authentication is opt-in. If the operator doesn't set a master key, the proxy is open. There's also a common placeholder key (sk-1234) that attackers actively scan for.

No exploit needed. No credential stuffing. Just an HTTP request to a publicly reachable endpoint that was never meant to be public but ended up that way because the defaults didn't protect it.

What attackers are actually doing with hijacked endpoints

The three campaigns Zenity caught were doing very different things, which shows how versatile this attack vector is.

One operator used a LiteLLM client to send a 140,000-character prompt weaponizing an autonomous penetration testing framework called Strix against a French auction house. The prompt instructed the agent to never ask for permission, run continuously, and never identify itself. The presence of persistent retry commands suggested a live human operator directing the attack in real time.

A second operator pointed a desktop LLM client at an exposed Ollama instance and loaded it with over 150 offensive security tools from a framework called HexStrike AI. No target was identified yet, suggesting this was staging for a future attack.

A third operator pointed an OpenAI Codex agent at a LiteLLM proxy under the persona of a "security auditor" and directed it to do web reverse-engineering work. The persona was specifically built to suppress the model's safety refusals.

In all three cases, the attacker's entire agent configuration, the system prompt, the tool definitions, and the persona rode in the request body. The exposed endpoint was just the compute layer.

Why this matters for every team running AI infrastructure

This isn't a sophisticated attack. It's the AI equivalent of leaving an S3 bucket open. But the consequences are different because an exposed AI endpoint doesn't just leak data. It gives attackers free compute for offensive operations, and those operations get attributed to your infrastructure.

If someone uses your exposed Ollama instance to run a penetration testing agent against a third party, the traffic comes from your IP. Your infrastructure is now part of someone else's attack chain, and explaining to an incident response team that you didn't do it but your misconfigured AI endpoint was used to do it is not a conversation anyone wants to have.

The broader pattern is that AI infrastructure is being deployed by ML engineers and developers who think of it as an internal tool, not a production service that needs the same hardening as anything else exposed to the internet. Default ports, no auth, placeholder keys, listening on all interfaces. These are the same misconfigurations we spent 15 years fixing in databases and cloud storage, and we're repeating every one of them with AI infrastructure.

What to actually do

The fixes are not complicated but they require treating AI infrastructure as a real attack surface.

Don't expose model backends to the internet unless there's a specific reason. If there is, put them behind authentication that isn't a placeholder key. Inspect request bodies from external sources because the agent payload (system prompt, tools, persona) rides in the request, not in a separate config. Monitor traffic to your AI endpoints for patterns like full-agent payloads, requests involving models you don't host, or prompts that include offensive tooling definitions. And treat sk-1234 and similar default keys the same way you'd treat admin/admin: change them immediately or assume they're already compromised.

As Zenity's CTO put it: assume any AI system you put on the internet will be targeted by AI-literate attackers within hours.

Source: Dark Reading

Is your team treating self-hosted AI infrastructure with the same security rigor as your production services? Or is it still in the "internal tool, nobody will find it" category?

5 Even More Advanced Java Tips That Senior Engineers Actually Use

Dimitris Kyrkos — Mon, 29 Jun 2026 10:03:58 +0000

Hey everyone.

Part three of the Java tips series. If you missed the first two: part one covered Virtual Threads, Sealed Classes, Records, MethodHandles, and ScopedValue. Part two covered Structured Concurrency, Record Patterns, Sequenced Collections, Panama, and Gatherers.

Same rules. Production patterns, not textbook examples. Let's go.

1. Unnamed Variables: Stop Naming Things You Don't Care About

Every Java developer has written throwaway variable names in catch blocks, lambda parameters, and pattern matches. var ignored, var _unused, Exception e where you never reference e. It's noise that clutters the code and makes readers wonder if the variable matters.

Unnamed variables (Java 22+) formalize "I intentionally don't care about this" with _.

// Before: reader has to check whether 'e' is used anywhere
try {
    return Integer.parseInt(input);
} catch (NumberFormatException e) {
    return defaultValue;
}

// After: intent is explicit, 'e' is never used and the code says so
try {
    return Integer.parseInt(input);
} catch (NumberFormatException _) {
    return defaultValue;
}

This looks minor until you see it across pattern matching, where the cleanup is significant:

// Before: naming things you'll never use just to satisfy the compiler
switch (event) {
    case Dispatched(var id, var origin) -> handleDispatch(id);
    case InTransit(var id, var location, var carrier) -> trackLocation(id, location);
    case Delivered(var id, var destination, var timestamp) -> confirmDelivery(id);
    case Failed(var id, var reason) -> handleFailure(id, reason);
}

// After: unnamed patterns make the intent clear
switch (event) {
    case Dispatched(var id, _) -> handleDispatch(id);
    case InTransit(var id, var location, _) -> trackLocation(id, location);
    case Delivered(var id, _, _) -> confirmDelivery(id);
    case Failed(var id, var reason) -> handleFailure(id, reason);
}

It composes cleanly with lambdas too:

// Map.forEach where you only care about values
config.forEach((_, value) -> validate(value));

// Stream indexed iteration where the element is irrelevant
IntStream.range(0, slots.size()).forEach(_ -> pool.submit(this::processNext));

// Try-with-resources where the resource is only needed for its lifecycle
try (var _ = ScopedValue.runWhere(TRACE_ID, requestId, () -> {})) {
    processRequest();
}

Why this matters beyond aesthetics: unnamed variables are a signal to future readers (and AI tools working on your code) that the omission is intentional. var _unused leaves ambiguity about whether someone meant to use it later. _ is unambiguous. It's the difference between "I forgot this" and "I don't need this." In large codebases that distinction matters for maintenance and automated refactoring.

2. Switch Expressions with Guards for Complex Dispatch

Pattern matching in switch (part one, tip 2) handles type-based dispatch. But production code rarely branches on type alone. Usually you need type plus a condition: this is a Transaction but only if the amount exceeds a threshold, or this is an HttpResponse but only if the status code is in a specific range.
Before Java 21, this meant nesting if-statements inside case blocks. Guards (when clauses) let you express the condition directly in the case pattern.

// Before: type match, then condition inside the block
String classify(Transaction tx) {
    return switch (tx) {
        case Deposit d -> {
            if (d.amount().compareTo(new BigDecimal("10000")) > 0) {
                yield "high-value deposit — requires AML review";
            } else {
                yield "standard deposit";
            }
        }
        case Withdrawal w -> {
            if (w.amount().compareTo(w.account().dailyLimit()) > 0) {
                yield "withdrawal exceeds daily limit";
            } else if (w.account().frozen()) {
                yield "account frozen — withdrawal blocked";
            } else {
                yield "standard withdrawal";
            }
        }
        case Transfer t -> "transfer";
    };
}

// After: guards flatten the entire dispatch into a single-level switch
String classify(Transaction tx) {
    return switch (tx) {
        case Deposit d
            when d.amount().compareTo(new BigDecimal("10000")) > 0
            -> "high-value deposit — requires AML review";
        case Deposit _ 
            -> "standard deposit";

        case Withdrawal w
            when w.amount().compareTo(w.account().dailyLimit()) > 0
            -> "withdrawal exceeds daily limit";
        case Withdrawal w
            when w.account().frozen()
            -> "account frozen — withdrawal blocked";
        case Withdrawal _
            -> "standard withdrawal";

        case Transfer _ 
            -> "transfer";
    };
}

Guards are evaluated top-to-bottom within the same type. The first matching case wins. The unguarded case at the bottom serves as the default for that type. Combined with sealed types, the compiler still enforces exhaustiveness: add a new Transaction subtype and every switch breaks until you handle it.

Where this transforms real code: authorization logic, event routing, validation dispatch, anywhere you're currently doing type-check-then-conditional. Guards turn nested control flow into flat declarative dispatch. Cognitive complexity drops significantly because every path is visible at one level of indentation instead of buried inside blocks.

// Complex event routing with nested record patterns + guards
String route(NotificationEvent event) {
    return switch (event) {
        case UserEvent(var userId, Alert a)
            when a.severity() == Severity.CRITICAL
            -> pushToOnCall(userId, a);

        case UserEvent(var userId, Alert a)
            when a.severity() == Severity.WARNING && isBusinessHours()
            -> sendSlack(userId, a);

        case UserEvent(_, Alert _)
            -> queueForBatch();

        case SystemEvent(var service, Metric m)
            when m.value() > m.threshold() * 2
            -> escalateImmediately(service, m);

        case SystemEvent(var service, Metric m)
            when m.value() > m.threshold()
            -> logAndMonitor(service, m);

        case SystemEvent(_, _)
            -> acknowledge();
    };
}

Flat, readable, exhaustive, and every routing decision is visible at a glance.

3. `mapMulti` for Allocation-Free Flat Mapping

flatMap is one of the most used stream operations. It's also one of the most wasteful. Every call to flatMap creates an intermediate stream that gets created, iterated once, and thrown away. For hot paths processing millions of elements, that overhead adds up.

mapMulti (Java 16+, but still underused) gives you the same semantics with zero intermediate allocation. Instead of returning a stream, you push elements directly into a downstream consumer.

// flatMap: creates a new Stream<String> for every single order
List<String> allItems = orders.stream()
    .flatMap(order -> order.lineItems().stream())
    .map(LineItem::sku)
    .toList();

// mapMulti: pushes items directly, no intermediate stream created
List<String> allItems = orders.stream()
    .<String>mapMulti((order, downstream) -> {
        for (var item : order.lineItems()) {
            downstream.accept(item.sku());
        }
    })
    .toList();

The difference in a JMH benchmark on 100K orders with 5 items each:

// Typical results (JMH, Java 21, after warmup):
// flatMap:   ~12ms, ~2.4M allocations
// mapMulti:  ~4ms,  ~0 intermediate allocations

3x faster, and the garbage collector has dramatically less work to do.

Where mapMulti really shines is conditional expansion, cases where flatMap would force you to create a stream even for elements that produce nothing:

// flatMap: creates an empty stream for every filtered-out element
users.stream()
    .flatMap(user -> user.isActive() 
        ? user.roles().stream() 
        : Stream.empty())  // still allocates a Stream object
    .toList();

// mapMulti: just don't push anything, zero cost for filtered elements
users.stream()
    .<Role>mapMulti((user, downstream) -> {
        if (user.isActive()) {
            for (var role : user.roles()) {
                downstream.accept(role);
            }
        }
    })
    .toList();

It also simplifies one-to-many transformations where the output type differs from the input:

// Parse a log file: each line produces zero or more structured events
logLines.stream()
    .<AuditEvent>mapMulti((line, downstream) -> {
        var parsed = EventParser.tryParse(line);
        if (parsed.isPresent()) {
            downstream.accept(parsed.get());
            if (parsed.get().severity() == Severity.CRITICAL) {
                downstream.accept(AuditEvent.escalation(parsed.get()));
            }
        }
    })
    .toList();

One element in, zero, one, or two elements out, no intermediate streams, no wrapper collections, no conditionals producing Stream.empty(). Just direct push.

Use flatMap when readability matters more than performance. Use mapMulti on hot paths, large datasets, and anywhere the allocation overhead of flatMap shows up in your profiler. The rule of thumb: if the lambda inside flatMap ever returns Stream.empty() or Stream.of(singleElement), mapMulti is almost certainly better.

4. Detecting and Fixing Virtual Thread Pinning

Virtual Threads (part one, tip 1) are powerful, but there's a production gotcha that catches teams after they migrate: pinning. When a virtual thread executes inside a synchronized block or calls a native method, it pins to its carrier thread and can't unmount. Other virtual threads waiting for that carrier are blocked, and you lose the concurrency advantage you migrated for.

The insidious part is that pinning doesn't throw an error. Your application still works. It just silently degrades to platform-thread-level concurrency for the pinned sections, and you only notice when throughput drops under load.

Detecting pinning

Java provides a system property that logs every pinning event:

# Add to JVM args — logs every time a virtual thread gets pinned
-Djdk.tracePinnedThreads=full

# Shorter output without full stack traces
-Djdk.tracePinnedThreads=short

In your logs you'll see something like:

Thread[#42,VirtualThread[#1001]/runnable@ForkJoinPool-1-worker-3,5,CarrierThreads]
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:183)
    java.base/java.lang.VirtualThread$VThreadContinuation.yield0(VirtualThread.java:206)
    com.yourapp.LegacyDao.fetchRecord(LegacyDao.java:47) <== synchronized method

The three most common pinning sources

// 1. synchronized methods — the most common culprit
public class LegacyDao {
    // This pins virtual threads — every concurrent call blocks a carrier
    public synchronized Record fetchRecord(long id) {
        return db.query("SELECT * FROM records WHERE id = ?", id);
    }
}

// Fix: replace with ReentrantLock
public class LegacyDao {
    private final ReentrantLock lock = new ReentrantLock();

    public Record fetchRecord(long id) {
        lock.lock();
        try {
            return db.query("SELECT * FROM records WHERE id = ?", id);
        } finally {
            lock.unlock();
        }
    }
}

// 2. synchronized blocks guarding shared state
public class ConnectionPool {
    private final List<Connection> available = new ArrayList<>();

    // Pins on every acquire and release
    public synchronized Connection acquire() {
        if (available.isEmpty()) throw new PoolExhaustedException();
        return available.removeLast();
    }

    // Fix: use a concurrent data structure instead of synchronizing
    private final LinkedBlockingDeque<Connection> pool = new LinkedBlockingDeque<>();

    public Connection acquire() throws InterruptedException {
        return pool.takeFirst();  // blocks the virtual thread, not the carrier
    }
}

// 3. Third-party libraries using synchronized internally
// Common in older JDBC drivers, logging frameworks, and HTTP clients.
// You can't fix the library code, but you can isolate it:

private static final ExecutorService LEGACY_IO = Executors.newFixedThreadPool(
    Runtime.getRuntime().availableProcessors() * 2
);

// Run the pinning code on platform threads, await from virtual thread
CompletableFuture<Result> future = CompletableFuture.supplyAsync(
    () -> legacyHttpClient.call(request),
    LEGACY_IO
);
Result result = future.join();  // virtual thread waits without pinning

Monitoring in production

Beyond the trace flag, track pinning metrics with JFR (Java Flight Recorder):

// Enable JFR with virtual thread events
// -XX:StartFlightRecording=filename=recording.jfr,settings=profile

// Then analyze with:
// jfr print --events jdk.VirtualThreadPinned recording.jfr

The migration path for large codebases: enable tracePinnedThreads=short in staging, load-test with realistic concurrency, and fix pinning hotspots from the top of the list down. You don't need to eliminate every pinning event. You need to eliminate the ones that happen on hot paths under concurrent load. A synchronized block in a startup routine that runs once is harmless. A synchronized block in your request handler that runs on every request is a concurrency bottleneck.

5. `List.copyOf()` vs `Collections.unmodifiableList()`: The Defensive Copy Bug That Bites in Production

Every senior Java developer knows you should return unmodifiable collections from public APIs. Fewer know that Collections.unmodifiableList() and List.copyOf() have a critical behavioral difference that causes subtle production bugs.

// Setup: a mutable source list
List<String> mutableSource = new ArrayList<>(List.of("a", "b", "c"));

// Collections.unmodifiableList: wraps the original — does NOT copy
List<String> wrapped = Collections.unmodifiableList(mutableSource);

System.out.println(wrapped); // [a, b, c]

// The caller "can't" modify wrapped... but the owner can modify the source
mutableSource.add("d");

System.out.println(wrapped); // [a, b, c, d] — wrapped changed!

// List.copyOf: creates an independent snapshot — actual defensive copy
List<String> copied = List.copyOf(mutableSource);

System.out.println(copied); // [a, b, c]

mutableSource.add("d");

System.out.println(copied); // [a, b, c] — copied is independent

Collections.unmodifiableList() is a view, not a copy. It prevents the recipient from modifying the list, but the original owner can still mutate the underlying data. Any reference to the "unmodifiable" list sees the mutations.

This causes real production bugs. The pattern looks like this:

// A service that returns "unmodifiable" config
public class FeatureFlagService {
    private final List<String> enabledFlags = new ArrayList<>();

    public void loadFlags() {
        enabledFlags.clear();
        enabledFlags.addAll(fetchFromDatabase());
    }

    // Bug: callers hold a reference that mutates when loadFlags() runs
    public List<String> getEnabledFlags() {
        return Collections.unmodifiableList(enabledFlags);
    }
}

// In production:
List<String> flags = flagService.getEnabledFlags();
// ... time passes, a scheduled job calls loadFlags() ...
// flags reference now points to completely different data
// Any cached decision based on the old flags is silently wrong

// Fix: return an independent snapshot
public List<String> getEnabledFlags() {
    return List.copyOf(enabledFlags);
}
// Now callers hold a stable snapshot regardless of what happens to the source

The same applies to Map.copyOf() vs Collections.unmodifiableMap() and Set.copyOf() vs Collections.unmodifiableSet().

There's one more subtlety. List.copyOf() rejects nulls:

List<String> withNull = Arrays.asList("a", null, "b");

Collections.unmodifiableList(withNull);  // works fine, null stays
List.copyOf(withNull);                    // throws NullPointerException

This is usually what you want because nulls in collections are a common source of downstream NPEs. But if you're migrating old code that legitimately stores nulls in lists, the switch to copyOf will surface those as runtime exceptions. That's a good thing, you want to find them, but be aware it changes behavior.

The rule in production code: use List.copyOf() (and Map.copyOf(), Set.copyOf()) for every public API return and every defensive copy. Use Collections.unmodifiable*() only when you intentionally want a live view of the underlying collection, which is rare and should be documented explicitly when you do.

Final Thought

Across these three posts, the pattern is consistent: modern Java keeps moving control from runtime conventions into compile-time guarantees and language-level safety. Unnamed variables make intent explicit. Guards make dispatch flat and readable. mapMulti eliminates hidden allocations. Pinning detection surfaces concurrency traps before they hit production. Defensive copies protect against mutation bugs that unmodifiableList only pretends to prevent.

The developers getting the most out of modern Java aren't just using new features. They're replacing implicit conventions with explicit language constructs that the compiler and runtime can enforce. That's the trajectory, and it's making Java codebases measurably safer and more maintainable.

DEV Community: Dimitris Kyrkos

Using AI to Code Isn't the Risk. Not Understanding What It Shipped Is

Intro

The schema nobody actually reasoned about

The stack trace that got forwarded, not read

The architecture nobody in the room can defend

Your model doesn't need to pass the bar exam. It needs to parse a log file.

Intro

Latency budgets don't care how smart the model is

Your data boundary is only as strong as your last API call

A pricing or deprecation decision made by someone else is not a risk you control

A model fine-tuned on your schema beats a generalist prompted around it

Every one of these is really the same story with a different failure mode

Build vs. integrate: when a small local model actually wins

The all-purpose agent isn't an architecture. It's a single point of failure with a system prompt.

Intro

The system prompt that nobody can safely edit

Every request pays for capabilities it doesn't use

One bad instruction degrades everything downstream

Testing becomes a probability exercise, not an engineering one

A multi-purpose agent isn't one decision. It's twenty, made by an LLM, at inference time, with nothing watching any of them.

Route it, don't merge it

"Unlimited context" is not a feature. It's technical debt with better marketing.

Intro

The latency tax nobody notices until it's live

The margin killer

Lost in the middle

Noise that turns into hallucination

Context management is data engineering wearing an LLM's clothes

Build it or buy it

Banning ChatGPT Won't Fix Your Shadow AI Problem. It'll Just Hide It.

Intro

What actually gets pasted into public chat windows

Why banning the tools doesn't work

The actual failure is a tooling gap, not a discipline gap

RAG isn't an AI problem. It's a data engineering problem wearing an AI hat.

The tutorial-to-production gap

The problems that surface after the demo

RAG is search infrastructure with an LLM on top

The build vs integrate decision

The fallacy of "AI-first." Start with the friction, not the technology.

The label that gets the sequence backwards

What happens when you start with the technology

Start with the friction instead

The most impressive engineering is the code you didn't write

AI frameworks make the first 10% feel like magic. The other 90% is where they break you.

The magic window

Where the abstractions become walls

The debugging tax

The cost tracking problem nobody mentions

When to build your own

The architecture principle

The AI conversation is shifting from "what can it do" to "can we rely on it"

The capability phase is over

Capability vs reliability are different problems

The five questions that actually determine adoption

Why this shift matters for developers

The biggest barrier to enterprise AI adoption isn't the model. It's trust in everything around it.

The trust problem nobody scopes correctly

The four questions that determine

Why opaque systems don't survive real operations

What trust actually looks like in practice

The real adoption blocker

Attackers are hijacking exposed AI endpoints to run offensive operations. No exploit needed.

The attack doesn't require a compromise

Why this works

What attackers are actually doing with hijacked endpoints

Why this matters for every team running AI infrastructure

What to actually do

5 Even More Advanced Java Tips That Senior Engineers Actually Use

1. Unnamed Variables: Stop Naming Things You Don't Care About

2. Switch Expressions with Guards for Complex Dispatch

3. mapMulti for Allocation-Free Flat Mapping

4. Detecting and Fixing Virtual Thread Pinning

5. List.copyOf() vs Collections.unmodifiableList(): The Defensive Copy Bug That Bites in Production

Final Thought

3. `mapMulti` for Allocation-Free Flat Mapping

5. `List.copyOf()` vs `Collections.unmodifiableList()`: The Defensive Copy Bug That Bites in Production