DEV Community: Dimitris Kyrkos

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.

Functional doesn't mean correct. That's the biggest risk with AI-generated code.

Dimitris Kyrkos — Fri, 26 Jun 2026 06:17:15 +0000

The code runs. That's not the question.

There's a failure mode with AI-generated code that's harder to catch than bugs, security holes, or performance problems. The code works. The interface looks right. The tests pass. And the system quietly solves the wrong problem.

This is different from broken code. Broken code announces itself. It throws errors, fails tests, crashes in production. You find it and fix it. The feedback loop is fast.

Code that's functional but wrong is silent. It runs perfectly while misunderstanding the actual requirement. And because it looks clean and passes every automated check, it can live in production for months before someone notices it's doing the wrong thing confidently.

Why this happens more with AI

When a human writes code, the act of building forces engagement with the requirement. You read the spec, you think about it, you translate it into logic. Sometimes you realize halfway through that the requirement doesn't make sense, or that there's an edge case the spec didn't cover, or that what the client asked for isn't what they actually need. That friction is valuable. It's where misunderstandings surface.

AI skips all of that. You prompt it, it produces output that structurally matches what you described. But "structurally matches the prompt" and "solves the real problem" are very different things. The AI doesn't know your business context. It doesn't know that "calculate the discount" means something different for wholesale customers than retail ones. It doesn't know that "send a notification" shouldn't happen during a maintenance window. It doesn't know that the requirement as written is actually wrong and a human would have flagged it.

The output looks right because the code is well-formed. The output is wrong because the intent behind the code was never verified.

The specific ways this shows up

The requirement gets interpreted literally. You ask for a search function and the AI builds one that matches exact strings. The actual users expect fuzzy matching, typo tolerance, and synonym handling. The code works perfectly. It's just not what anyone needed.

Business rules get flattened. The AI implements the rule as stated in the prompt but misses the exceptions that everyone on the team knows about but nobody wrote down. A pricing function that doesn't account for the grandfather clause on legacy accounts. A permissions check that doesn't know about the temporary elevated access your support team uses during escalations.

Edge cases get the happy path treatment. The AI handles the common case well because that's what the prompt described. The uncommon cases, the ones that cause actual production incidents, get default behavior that technically doesn't crash but produces wrong results silently.

Validation is the actual work

Vibe coding gives you speed. Validation gives you correctness. They're different things and one doesn't substitute for the other.

The teams handling this well do something boring but effective: they verify that the generated code solves the right problem before they verify that it solves it correctly. That means going back to the actual requirement, not the prompt, and asking whether the output matches what the business actually needs. Not what the prompt said. What the business needs. Those are often different.

Then they check the edge cases. Not the ones the AI tested for, the ones it couldn't know about because they live in the team's domain knowledge, not in the codebase.

Then they ask the question that matters most: could this code produce wrong results silently? Not crash, not throw errors, just quietly do the wrong thing and look fine on every dashboard. That's the failure mode that AI makes much more likely, and it's the one that most validation processes don't test for.

The uncomfortable bottom line

LLMs are very good at producing code that looks structurally right. They're also very good at producing code that confidently solves a problem you don't actually have. The gap between those two things is where engineering judgment lives.

AI didn't remove the need for that judgment. It made it the only thing standing between "the code runs" and "the system actually works."

How does your team validate that AI-generated code solves the right problem, not just any problem?

AI isn't a software upgrade. It's an organizational redesign.

Dimitris Kyrkos — Mon, 22 Jun 2026 08:21:20 +0000

The framing most companies get wrong

There's a pattern I keep seeing in how companies talk about adopting AI. They treat it like upgrading a tool. Swap in the new thing, keep everything else the same, move faster.

That framing misses what actually happens.

What changes when AI enters a workflow

Once AI starts generating code, drafting decisions, or automating steps that humans used to own, four things shift simultaneously.

Decision speed changes. AI produces output in seconds. But the review, approval, and validation structures around that output were designed for human-speed delivery. You now have a team that can generate a week's worth of code in a day, running into a review process that was built to handle a week's worth of code in a week. Something has to give, and usually what gives is review quality.

Accountability gets blurry. When a human writes code, you know who made every decision. When AI generates code and a human approves it, accountability lives in a grey zone. Who owns the architectural choice the AI made? Who's responsible when a generated function introduces a security vulnerability? Most orgs haven't answered these questions explicitly, so they get answered implicitly by whoever is on call when something breaks.

Escalation paths break. Traditional escalation assumes a human-made decision that can be explained and traced. AI-generated output often can't be traced the same way. "Why was it built this way?" gets answered with "that's what the AI produced, and it looked right." That's not an escalation path. That's a dead end.

Operational expectations shift faster than operations do. Leadership sees the speed of generation and expects the speed of delivery to match. But delivery includes review, testing, integration, deployment, and monitoring. None of those got faster just because the first step did. The expectation gap creates pressure that compresses everything downstream.

Why this creates tension

The tension isn't about the technology. The technology works. The tension is that AI evolves faster than the organizational structures around it.

Teams adopt AI tools in weeks. Changing how decisions get made, who's accountable for what, how reviews work, and what "done" means takes months. In that gap, you get teams generating more output than their processes can absorb, accountability questions that nobody has answered, and escalation paths that quietly stopped working.

Most of the AI adoption failures I've watched weren't technical failures. They were alignment failures. The tool changed. The org didn't.

The alignment problem nobody talks about

The challenge for most companies is no longer access to AI. Everyone has access. The challenge is alignment.

Aligning the speed of AI output with the capacity of the review process.
Aligning accountability structures to account for AI-generated decisions.
Aligning operational expectations with the reality that generation is only one step in a much longer delivery chain.

The teams that get this right don't just adopt AI tools. They redesign how work flows through the organization to account for what those tools actually change. That's not a software upgrade. That's an organizational redesign.

Has your company actually changed its processes since adopting AI tools, or did the tools change and everything else stayed the same?

AI makes writing code easier. It doesn't make engineering easier.

Dimitris Kyrkos — Fri, 19 Jun 2026 09:58:24 +0000

The narrative is backwards

There's a narrative going around that AI is making software engineering easier. I think it's getting the direction wrong.

AI is making it easier to generate code, build prototypes, and move from idea to output faster than ever. That part is real and significant. But the act of writing code was never the hardest part of software engineering. Understanding the problem was. Defining the right architecture was. Translating what a client actually needs into reliable system behavior was. Testing, validating, maintaining, and scaling software over time was.

None of that got easier because an LLM can produce a function in three seconds.

The gap is widening, not shrinking

If anything, the gap between "code that exists" and "software that works in context" is widening. When generating code was slow and expensive, the generation step forced a certain amount of thinking. You considered trade-offs as you wrote. You questioned assumptions because each line took effort. Now that code appears instantly, all of that deliberation has to happen separately and deliberately. And most teams haven't adjusted their process to account for that.

What the teams doing it well look like

The teams I see succeeding with AI aren't the ones generating the most code. They're the ones asking better questions before they generate anything. They define the problem clearly before they prompt. They evaluate whether the generated output actually fits their architecture instead of just checking whether it runs. They validate edge cases the AI never considered because nobody prompted for them. They invest time in understanding what was generated before it ships.

The role is shifting, not shrinking

The role is moving from "person who writes code" to "person who designs systems that work in context." That's not a demotion. It's actually a higher bar. The writing was the mechanical part. The engineering judgment around it was always where the real value lived.

AI reduces the effort needed to produce software. It increases the importance of everything that surrounds production: problem definition, architectural decisions, validation, and the judgment to know when generated code is good enough and when it's hiding assumptions that will break under real load.

Where the advantage actually lives

The future won't belong to teams that output the most code. It'll belong to teams that validate faster, make better technical decisions, and ask the questions that LLMs can't ask for themselves.

Is your team's process actually different since adopting AI tools? Or did the tools change but the workflow stayed the same?

5 More Advanced Java Tips That Senior Engineers Actually Use

Dimitris Kyrkos — Thu, 18 Jun 2026 11:04:49 +0000

Hey everyone.

Continuing with the series, here's part two: five more patterns from modern Java 21+ that are showing up in production systems and changing how senior engineers write code.

Same rules as before. These are from real codebases, not textbook examples. If you get all five on the first read, you're ahead of most Java developers working today.

1. Use Structured Concurrency Instead of CompletableFuture Fan-Out

Every Java developer has written the CompletableFuture fan-out pattern: fire off multiple async calls, combine the results, handle errors. It works, but it has a structural problem that surfaces under real load. If one task fails, the others keep running. If the parent thread gets cancelled, the child futures don't know about it. You end up leaking work, wasting resources, and writing defensive cleanup code that's hard to test.

Structured Concurrency (preview in Java 21, stable in Java 24) fixes this by treating a group of concurrent tasks as a single unit of work with a defined lifetime.

// The CompletableFuture way: tasks are independent, cleanup is manual
CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(() -> fetchUser(id));
CompletableFuture<List<Order>> ordersFuture = CompletableFuture.supplyAsync(() -> fetchOrders(id));
CompletableFuture<CreditScore> creditFuture = CompletableFuture.supplyAsync(() -> fetchCredit(id));

// If fetchOrders throws, fetchUser and fetchCredit keep running
// If we time out here, all three futures are still in flight somewhere
User user = userFuture.get(5, TimeUnit.SECONDS);
List<Order> orders = ordersFuture.get(5, TimeUnit.SECONDS);
CreditScore credit = creditFuture.get(5, TimeUnit.SECONDS);

// The structured way: all tasks share a lifetime, failure cancels siblings
UserProfile buildProfile(long id) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        Subtask<User> user = scope.fork(() -> fetchUser(id));
        Subtask<List<Order>> orders = scope.fork(() -> fetchOrders(id));
        Subtask<CreditScore> credit = scope.fork(() -> fetchCredit(id));

        scope.joinUntil(Instant.now().plusSeconds(5));
        scope.throwIfFailed();

        return new UserProfile(user.get(), orders.get(), credit.get());
    }
    // When scope closes: all tasks are guaranteed complete or cancelled.
    // If fetchOrders threw: fetchUser and fetchCredit get cancelled immediately.
    // If we hit the 5s deadline: everything cancels, no leaked work.
}

The architectural difference: with CompletableFuture, concurrency is unstructured. Tasks float independently and you're responsible for tracking their lifetimes. With StructuredTaskScope, concurrency is scoped. The parent owns the children, failure propagates, cancellation propagates, and when the try-with-resources block exits, nothing is left running.

There's also ShutdownOnSuccess for race patterns where you want the first successful result and cancel the rest:

// First successful response wins, all others cancel
<T> T firstSuccess(List<Callable<T>> tasks) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnSuccess<T>()) {
        for (var task : tasks) scope.fork(task);
        scope.join();
        return scope.result();
    }
}

// Use case: query three replicas, take the fastest response
var result = firstSuccess(List.of(
    () -> queryReplica("us-east"),
    () -> queryReplica("eu-west"),
    () -> queryReplica("ap-south")
));

2. Use Record Patterns for Nested Destructuring

Tip 2 from the first post covered sealed classes with pattern matching on a single level. Record patterns (Java 21+) take this further by letting you destructure nested records directly inside the switch expression. Instead of matching a type and then pulling out fields, you match the structure itself.

// Domain model: sealed hierarchy with nested records
sealed interface ShippingEvent permits Dispatched, InTransit, Delivered, Failed {}
record Dispatched(OrderId order, Warehouse origin) implements ShippingEvent {}
record InTransit(OrderId order, Location current, Carrier carrier) implements ShippingEvent {}
record Delivered(OrderId order, Location destination, Instant timestamp) implements ShippingEvent {}
record Failed(OrderId order, FailureReason reason) implements ShippingEvent {}

record OrderId(String value) {}
record Location(double lat, double lon) {}
record Warehouse(String code, Location location) {}
record Carrier(String name, String trackingUrl) {}
sealed interface FailureReason permits AddressInvalid, DamagedInTransit, CustomsHold {}
record AddressInvalid(String detail) implements FailureReason {}
record DamagedInTransit(String inspectionId) implements FailureReason {}
record CustomsHold(String referenceNumber) implements FailureReason {}

// Without record patterns: match the type, then extract fields manually
String describe(ShippingEvent event) {
    return switch (event) {
        case Failed f -> {
            if (f.reason() instanceof AddressInvalid a) {
                yield "Order " + f.order().value() + " failed: bad address — " + a.detail();
            } else if (f.reason() instanceof CustomsHold c) {
                yield "Order " + f.order().value() + " held at customs: " + c.referenceNumber();
            } else {
                yield "Order " + f.order().value() + " failed";
            }
        }
        default -> "...";
    };
}

// With record patterns: destructure the entire nested structure in one line
String describe(ShippingEvent event) {
    return switch (event) {
        case Dispatched(var id, Warehouse(var code, _))
            -> "Order " + id.value() + " dispatched from warehouse " + code;

        case InTransit(var id, Location(var lat, var lon), Carrier(var name, var url))
            -> "Order " + id.value() + " in transit at [" + lat + "," + lon + "] via " + name;

        case Delivered(var id, _, var time)
            -> "Order " + id.value() + " delivered at " + time;

        case Failed(var id, AddressInvalid(var detail))
            -> "Order " + id.value() + " failed: bad address — " + detail;

        case Failed(var id, DamagedInTransit(var inspectionId))
            -> "Order " + id.value() + " damaged, inspection: " + inspectionId;

        case Failed(var id, CustomsHold(var ref))
            -> "Order " + id.value() + " customs hold: " + ref;
    };
}

The _ (unnamed pattern, Java 22+) ignores fields you don't need without creating throwaway variables. The nested destructuring is exhaustive: add a new FailureReason subtype and every switch that destructures Failed will become a compile error until you handle it.

This is where sealed types plus records plus record patterns combine into something genuinely new. You're not just switching on types. You're pattern matching against data shapes, like how you'd match in Haskell or Scala, but with full compile-time exhaustiveness checking and zero library dependencies.

3. Sequenced Collections: Stop Guessing How to Get the First and Last Element

Before Java 21, getting the first or last element of a collection was embarrassingly inconsistent. LinkedHashMap had no way to access the last entry without iterating the entire thing. SortedSet had first() and last() but List didn't. Deque had getFirst() and getLast() but those methods didn't exist on List. Getting a reversed view of a Set required conversion to a List.

Java 21 introduced SequencedCollection, SequencedSet, and SequencedMap as new interfaces that unify encounter-order operations across all collection types that have a defined order.

// Before Java 21: inconsistent, type-specific hacks
List<String> list = List.of("a", "b", "c");
String first = list.get(0);
String last = list.get(list.size() - 1);

LinkedHashSet<String> set = new LinkedHashSet<>(List.of("x", "y", "z"));
String firstOfSet = set.iterator().next();  // no better way
// last of set? iterate the whole thing

LinkedHashMap<String, Integer> map = new LinkedHashMap<>();
map.put("alpha", 1); map.put("beta", 2); map.put("gamma", 3);
// first entry? map.entrySet().iterator().next()
// last entry? no clean way without iterating all entries

// Java 21+: uniform interface across List, LinkedHashSet, SortedSet, LinkedHashMap, etc.
SequencedCollection<String> list = List.of("a", "b", "c");
list.getFirst();    // "a"
list.getLast();     // "c"
list.reversed();    // reversed view: ["c", "b", "a"] — no copy, just a view

SequencedSet<String> set = new LinkedHashSet<>(List.of("x", "y", "z"));
set.getFirst();     // "x"
set.getLast();      // "z"
set.reversed();     // reversed view

SequencedMap<String, Integer> map = new LinkedHashMap<>();
map.put("alpha", 1); map.put("beta", 2); map.put("gamma", 3);
map.firstEntry();   // alpha=1
map.lastEntry();    // gamma=3
map.reversed();     // reversed view of the entire map

map.putFirst("zero", 0);   // insert at the beginning
map.putLast("delta", 4);   // insert at the end

Why this matters more than it looks: reversed() returns a view, not a copy. It's O(1) and backed by the original collection. You can pass a reversed view to any method that accepts a SequencedCollection and it reads elements in reverse order without allocating anything. This is especially useful when you're processing event logs, audit trails, or time-ordered data where "newest first" and "oldest first" are both common access patterns on the same dataset.

// Practical example: processing the last N events from an ordered set
SequencedCollection<AuditEvent> events = getAuditLog();

// Five most recent events, no copy, no subList gymnastics
events.reversed().stream()
    .limit(5)
    .forEach(this::processEvent);

The interface hierarchy slots into the existing collections framework cleanly. List implements SequencedCollection. LinkedHashSet and SortedSet implement SequencedSet. LinkedHashMap and SortedMap implement SequencedMap. You don't need to change your collection types to get the new methods.

4. Foreign Function and Memory API: Replace Unsafe and JNI With Something That Actually Works

For decades, Java developers who needed native memory access or native function calls had two bad options. sun.misc.Unsafe gave you raw memory access but was unsupported, undocumented, and could crash the JVM with no safety net. JNI let you call native functions but required writing C boilerplate, compiling platform-specific binaries, and debugging segfaults with zero help from the Java toolchain.

The Foreign Function and Memory API (Project Panama, stable in Java 22+) replaces both with a safe, performant, pure-Java alternative.

// Allocating and using off-heap memory safely
// Use case: building a high-performance buffer for network I/O

try (Arena arena = Arena.ofConfined()) {
    // Allocate 1MB of off-heap memory, automatically freed when arena closes
    MemorySegment buffer = arena.allocate(1_048_576);

    // Write structured data using layout-based access
    MemoryLayout layout = MemoryLayout.structLayout(
        ValueLayout.JAVA_INT.withName("id"),
        ValueLayout.JAVA_LONG.withName("timestamp"),
        ValueLayout.JAVA_DOUBLE.withName("value")
    );

    VarHandle idHandle = layout.varHandle(MemoryLayout.PathElement.groupElement("id"));
    VarHandle tsHandle = layout.varHandle(MemoryLayout.PathElement.groupElement("timestamp"));
    VarHandle valHandle = layout.varHandle(MemoryLayout.PathElement.groupElement("value"));

    idHandle.set(buffer, 0L, 42);
    tsHandle.set(buffer, 0L, System.nanoTime());
    valHandle.set(buffer, 0L, 3.14159);

    int id = (int) idHandle.get(buffer, 0L);          // 42
    double value = (double) valHandle.get(buffer, 0L); // 3.14159
}
// Arena closed: all off-heap memory is freed. No manual deallocation, no leaks.

// Calling a native C function from pure Java — no JNI, no C boilerplate
// Example: calling strlen from libc

Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();

MethodHandle strlen = linker.downcallHandle(
    stdlib.find("strlen").orElseThrow(),
    FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS)
);

try (Arena arena = Arena.ofConfined()) {
    MemorySegment cString = arena.allocateFrom("Hello from Panama!");
    long length = (long) strlen.invoke(cString);  // 18
}

Why this matters for production systems: any Java application that works with large datasets, memory-mapped files, native libraries (OpenSSL, SQLite, SIMD operations), or custom network protocols used to require Unsafe hacks or JNI. Panama gives you the same performance with deterministic deallocation (via Arena), bounds checking (the JVM catches out-of-bounds access on MemorySegments), and no native compilation step. Your entire build stays pure Java.

The Arena model is the key design decision. Confined arenas are single-threaded and automatically freed on close. Shared arenas allow multi-threaded access. Auto arenas use garbage collection. Global arenas live for the process lifetime. You pick the lifetime model that matches your use case and the API enforces it.

5. Build Custom Stream Operations with Gatherers

Java streams have had a gap since they were introduced in Java 8: you can create custom terminal operations (Collectors), but there's no equivalent for custom intermediate operations. If you needed a "sliding window," a "take while distinct," or a "batch into groups of N," you either wrote ugly hacks with reduce and mutable state or dropped out of the stream pipeline entirely.

Gatherers (stable in Java 24) fill that gap. They're the intermediate operation equivalent of Collectors.

// Problem: batch a stream of events into groups of N for bulk processing
// Before Gatherers: ugly, stateful, breaks the stream paradigm

List<Event> events = getEvents();
List<List<Event>> batches = new ArrayList<>();
for (int i = 0; i < events.size(); i += 100) {
    batches.add(events.subList(i, Math.min(i + 100, events.size())));
}
batches.forEach(this::bulkInsert);

// With Gatherers: a clean intermediate operation inside the stream pipeline

events.stream()
    .gather(Gatherers.windowFixed(100))
    .forEach(this::bulkInsert);

Gatherers.windowFixed(n) is one of the built-in gatherers. windowSliding(n) gives you overlapping windows. But the real power is building your own:

// Custom gatherer: deduplicate consecutive elements
// [a, a, b, b, b, c, a, a] → [a, b, c, a]
static <T> Gatherer<T, ?, T> deduplicateConsecutive() {
    return Gatherer.ofSequential(
        // State: the last element seen
        () -> new Object[]{ null, Boolean.FALSE },  // [lastValue, initialized]
        // Integrator: emit only when the value changes
        (state, element, downstream) -> {
            if (!(boolean) state[1] || !Objects.equals(state[0], element)) {
                state[0] = element;
                state[1] = Boolean.TRUE;
                return downstream.push(element);
            }
            return true;
        }
    );
}

// Usage
List.of("a", "a", "b", "b", "b", "c", "a", "a")
    .stream()
    .gather(deduplicateConsecutive())
    .toList();
// Result: [a, b, c, a]

// Custom gatherer: emit a running average over a sliding window
static Gatherer<Double, ?, Double> movingAverage(int windowSize) {
    return Gatherer.ofSequential(
        () -> new ArrayDeque<Double>(windowSize),
        (window, element, downstream) -> {
            window.addLast(element);
            if (window.size() > windowSize) window.removeFirst();
            if (window.size() == windowSize) {
                double avg = window.stream().mapToDouble(Double::doubleValue).average().orElse(0);
                return downstream.push(avg);
            }
            return true;
        }
    );
}

// Usage: smooth noisy sensor data
sensorReadings.stream()
    .gather(movingAverage(10))
    .forEach(this::recordSmoothedReading);

Why this matters: Gatherers complete the stream API's extensibility story. Collectors let you define how a stream ends. Gatherers let you define what happens in the middle. Stateful intermediate operations that used to require dropping out of streams (or writing unmaintainable reduce calls) now compose cleanly inside the pipeline. For data processing, ETL pipelines, event stream processing, and anything involving windowing or batching, this is a significant improvement in both readability and correctness.

Final Thought

These five patterns build on the foundations from part one. Structured Concurrency pairs naturally with Virtual Threads (part one, tip 1) because StructuredTaskScope was designed for virtual-thread-heavy workloads. Record Patterns deepen the Sealed Classes and Pattern Matching story (part one, tip 2) by adding nested destructuring. Panama replaces the exact use cases where developers historically reached for Unsafe or MethodHandles (part one, tip 4) at the native boundary.

Modern Java isn't just adding features. It's building a coherent system where concurrency, domain modeling, data access, and stream processing all fit together. The developers who see these connections across features are the ones writing the most maintainable, performant code in the ecosystem right now.

The Novo Nordisk breach hit patient data and proprietary AI models. The attack surface is expanding.

Dimitris Kyrkos — Tue, 16 Jun 2026 12:29:25 +0000

What happened

Novo Nordisk confirmed a cyberattack this week. The Danish pharmaceutical company behind Ozempic and Wegovy disclosed that attackers accessed internal IT systems and exfiltrated pseudonymized patient data from clinical trials.

The confirmed breach includes patient IDs, sex, year of birth, biomarkers, health data, immunogenicity data, and lifestyle factors like BMI and smoking status. No direct identifiers like names were exposed. Healthcare professional data was also hit, including names, registration numbers, emails, phone numbers, and office locations.

What the attackers are claiming

That's the official disclosure. The interesting part is what goes beyond it.

A group calling itself Dragonfly says it got significantly deeper than patient records. According to screenshots they shared, the stolen data allegedly includes a 16.7 GB trained AI model checkpoint for an internal multimodal model called NovoPert covering text, image, and transcriptomics data. A 407 MB proprietary biological and chemical training dataset. Full source code for the training pipeline. 113 training runs with complete logs. Internal infrastructure maps covering HPC clusters, Slurm configs, and SSH configurations. Over 53 GB of container images. Developer identities, internal hostnames, and a private GitHub repo URL.

Novo Nordisk hasn't confirmed any of the AI-related claims. No ransomware has been identified.

AI assets are now high-value targets

If the Dragonfly claims are accurate, the AI assets are arguably more valuable than the patient data. A proprietary model trained on biological and chemical data in the pharmaceutical space represents months or years of R&D investment. That's worth enormous money to competitors or on the black market. This changes the threat model for any organization developing internal AI systems.

AI development infrastructure is an unaudited attack surface
HPC clusters, Slurm job schedulers, training pipelines, container registries, model artifact stores. These are all systems that most security teams weren't auditing five years ago because they didn't exist in most organizations. Now they hold some of the most valuable intellectual property the company owns and they're often configured by ML engineers and data scientists, not security-focused infrastructure teams.

Leaked container images are architecture blueprints

The container image leak (53 GB+) is potentially devastating beyond the model itself. Container images routinely contain embedded credentials, environment variables, internal network configurations, and dependency chains that reveal the entire stack. A single leaked production container image can give an attacker a blueprint of your internal architecture.

Developer identities enable follow-on attacks

The "developer identities and private GitHub repo URL" part is the quiet detail that enables what comes next. If attackers have developer identities and know where the code lives, supply chain attacks against those specific developers become trivial to plan. Phishing a developer whose name, email, and repo access you already know is a very different proposition from attacking blind.

Why this matters beyond Novo Nordisk

The patient data breach is serious on its own. But if the AI asset claims are real, this is one of the first major breaches where proprietary AI intellectual property was the primary target, not a side effect. That's a shift that every team building internal AI systems should be paying attention to.

Source: cybersecuritynews.com

How is your team thinking about securing AI training infrastructure? Is it part of your threat model yet, or is it still treated as an internal research environment?

5 Advanced Java Tips That Senior Engineers Actually Use

Dimitris Kyrkos — Fri, 12 Jun 2026 08:38:35 +0000

Hey everyone.

Continuing the tip series (previously Python and JavaScript), this time we're going deep on Java.

These are patterns from production systems running on Java 21+. Not textbook examples, not certification prep. If you understand all five on the first read, you're in a very small group.

Let's get into it.

1. Replace Your Thread Pools with Virtual Threads for I/O-Bound Work

Every Java developer has written a thread pool executor to handle concurrent requests. The problem is that platform threads are expensive. Each one costs about 1MB of stack memory and is mapped 1:1 to an OS thread. At 10,000 concurrent connections, you're either burning 10GB of RAM on threads or fighting with pool sizing and backpressure.

Virtual threads (Project Loom, production-ready since Java 21) flip this entirely.

// The old way: manually sized thread pool, blocks under load
ExecutorService pool = Executors.newFixedThreadPool(200);

for (Request req : incomingRequests) {
    pool.submit(() -> {
        var result = callExternalApi(req);  // blocks a platform thread
        writeToDatabase(result);
    });
}

// The virtual thread way: millions of concurrent tasks, negligible memory
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (Request req : incomingRequests) {
        executor.submit(() -> {
            var result = callExternalApi(req);  // blocks a virtual thread, not an OS thread
            writeToDatabase(result);
        });
    }
}

The real impact: virtual threads are heap-allocated, cost a few KB each, and unmount from the carrier thread when they hit a blocking call. You can run 1,000,000 concurrent virtual threads on a machine that would OOM at 5,000 platform threads.

// Proof: try launching a million virtual threads
long start = System.nanoTime();
List<Thread> threads = new ArrayList<>();
for (int i = 0; i < 1_000_000; i++) {
    threads.add(Thread.startVirtualThread(() -> {
        try { Thread.sleep(Duration.ofSeconds(1)); }
        catch (InterruptedException e) { Thread.currentThread().interrupt(); }
    }));
}
for (Thread t : threads) t.join();
long elapsed = (System.nanoTime() - start) / 1_000_000;
System.out.println("1M virtual threads completed in " + elapsed + "ms");
// Typical output: ~1200ms on a standard laptop

The tradeoff you must know: virtual threads are for I/O-bound work. CPU-bound tasks still need platform threads because virtual threads share carrier threads from the ForkJoinPool. If your task never blocks, a virtual thread adds scheduling overhead with zero benefit. Also, synchronized blocks pin the virtual thread to its carrier. Use ReentrantLock instead in virtual-thread-heavy code.

2. Use Sealed Classes with Pattern Matching for Exhaustive Domain Modeling

If you're using abstract classes with instanceof chains, you're writing code the compiler can't verify. Sealed classes (Java 17+) combined with pattern matching in switch (Java 21+) give you algebraic data types with compile-time exhaustiveness checking.

// The old way: open hierarchy, no compiler guarantee you handled all cases
abstract class PaymentResult { }
class Success extends PaymentResult { String transactionId; }
class Declined extends PaymentResult { String reason; }
class Retry extends PaymentResult { Duration backoff; }


// Somewhere in your codebase...
if (result instanceof Success s) {
    log(s.transactionId);
} else if (result instanceof Declined d) {
    notifyUser(d.reason);
}
// Forgot Retry? Compiler says nothing. Runtime says NullPointerException.

// The sealed way: compiler enforces you handle every case
sealed interface PaymentResult permits Success, Declined, Retry { }
record Success(String transactionId) implements PaymentResult { }
record Declined(String reason) implements PaymentResult { }
record Retry(Duration backoff) implements PaymentResult { }

// Exhaustive pattern matching — add a new subtype and this won't compile
// until you handle it
String handle(PaymentResult result) {
    return switch (result) {
        case Success s   -> "Completed: " + s.transactionId();
        case Declined d  -> "Declined: " + d.reason();
        case Retry r     -> "Retry after " + r.backoff().toMillis() + "ms";
    };
}

Why this is architecturally significant: when you add a fourth case (say Timeout), every switch expression in your codebase that touches PaymentResult becomes a compile error until you handle it. This is the same guarantee Rust's enums give you, and it eliminates an entire class of bugs that unit tests typically catch too late.

The combination with records gives you immutable, destructurable data with zero boilerplate. No getters, no equals/hashCode, no builder. The compiler generates all of it.

3. Compact Canonical Constructors in Records for Validated Immutable Data

Most developers know records as "classes without boilerplate." Fewer know about compact canonical constructors, which let you add validation without repeating the parameter list.

// Naive record: no validation, accepts garbage
record PortConfig(int port, int maxConnections, Duration timeout) { }

// This happily creates nonsense:
var config = new PortConfig(-1, 0, Duration.ofMillis(-500));

// Compact constructor: validates without restating the signature
record PortConfig(int port, int maxConnections, Duration timeout) {
    PortConfig {
        // No parameter list — the canonical params are implicit
        if (port < 1 || port > 65535)
            throw new IllegalArgumentException("Port must be 1-65535, got " + port);
        if (maxConnections < 1)
            throw new IllegalArgumentException("maxConnections must be >= 1");
        if (timeout.isNegative())
            throw new IllegalArgumentException("timeout must not be negative");

        // You can also normalize — reassignment is allowed in compact constructors
        timeout = timeout.compareTo(Duration.ofSeconds(300)) > 0
            ? Duration.ofSeconds(300)
            : timeout;
    }
}

var config = new PortConfig(8080, 200, Duration.ofSeconds(30)); // validated + immutable
config.port();         // 8080
config.timeout();      // PT30S
// config.port = 9090; // won't compile — records are final

Why this matters in production: records with compact constructors replace 80% of the builder pattern use cases in configuration objects, DTOs, and event payloads. The object is guaranteed valid at construction time, immutable after, and automatically gets correct equals, hashCode, and toString. When you combine this with sealed interfaces (tip 2), you get validated, exhaustive, immutable domain models with almost no code.

4. Use `MethodHandles` for Reflection-Speed Access Without Reflection's Cost

Standard reflection (Field.get, Method.invoke) is slow because the JVM has to perform access checks, boxing, and method resolution on every call. MethodHandle does all of that once, at lookup time, and then gives you a handle that the JIT can inline.

// The reflection way: access checks on every call, can't be inlined
class MetricsCollector {
    void collectViaReflection(Object target, String fieldName) throws Exception {
        Field f = target.getClass().getDeclaredField(fieldName);
        f.setAccessible(true);
        Object value = f.get(target);  // slow path every time
        record(fieldName, value);
    }
}

// The MethodHandle way: resolve once, call fast forever
class MetricsCollector {
    private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup();
    private final Map<String, MethodHandle> handleCache = new ConcurrentHashMap<>();

    MethodHandle resolveGetter(Class<?> clazz, String fieldName) throws Exception {
        return handleCache.computeIfAbsent(clazz.getName() + "." + fieldName, k -> {
            try {
                Field f = clazz.getDeclaredField(fieldName);
                f.setAccessible(true);
                return LOOKUP.unreflectGetter(f);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        });
    }

    void collectViaHandle(Object target, String fieldName) throws Throwable {
        MethodHandle getter = resolveGetter(target.getClass(), fieldName);
        Object value = getter.invoke(target);  // JIT can inline this
        record(fieldName, value);
    }
}

Benchmarking the difference:

// Typical results (JMH, Java 21, after warmup):
// Reflection:    ~150 ns/op
// MethodHandle:  ~4 ns/op
// Direct access: ~2 ns/op

MethodHandles get within 2x of direct field access. Reflection is 35x slower. In frameworks, serializers, ORM hydration, and any code that dynamically accesses fields in a hot loop, this difference compounds into real latency.

The tradeoff: MethodHandles are harder to read and require careful caching. Use them in framework-level code and hot paths. For one-off reflection calls during startup or configuration, standard reflection is fine.

5. Use `ScopedValue` Instead of `ThreadLocal` in Structured Concurrency

ThreadLocal has been the go-to for per-request context (user ID, trace ID, transaction context) for 20 years. But it has a fundamental flaw in the virtual thread world: thread-local values don't propagate to child threads, they leak when threads are reused from pools, and they're mutable, meaning any code in the call chain can silently overwrite them.

ScopedValue (preview in Java 21, stable in Java 24) fixes all of this.

// The ThreadLocal way: mutable, leaks across requests in pooled threads
private static final ThreadLocal<String> TRACE_ID = new ThreadLocal<>();

void handleRequest(Request req) {
    TRACE_ID.set(req.traceId());
    try {
        process(req);
    } finally {
        TRACE_ID.remove();  // forget this and you leak context to the next request
    }
}

void process(Request req) {
    log("Processing " + TRACE_ID.get());
    // Any code can call TRACE_ID.set("garbage") and corrupt the context
}

// The ScopedValue way: immutable, bounded lifetime, safe with virtual threads
private static final ScopedValue<String> TRACE_ID = ScopedValue.newInstance();

void handleRequest(Request req) {
    ScopedValue.runWhere(TRACE_ID, req.traceId(), () -> {
        process(req);
        // TRACE_ID is automatically unbound when this lambda exits
        // No try/finally, no .remove(), no leak possible
    });
}

void process(Request req) {
    log("Processing " + TRACE_ID.get());
    // TRACE_ID.set() doesn't exist — the value is immutable within this scope
}

Why this matters architecturally: ScopedValue bindings are immutable and automatically scoped to the call. They can't leak, can't be overwritten by downstream code, and they work naturally with StructuredTaskScope for fork/join patterns where child tasks inherit the parent's context. In virtual-thread-heavy services handling millions of concurrent requests, this eliminates an entire category of context-corruption bugs that are nearly impossible to reproduce in testing.

// ScopedValue + StructuredTaskScope: child tasks inherit the trace ID
void handleRequest(Request req) {
    ScopedValue.runWhere(TRACE_ID, req.traceId(), () -> {
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            var userTask = scope.fork(() -> fetchUser(req.userId()));
            var orderTask = scope.fork(() -> fetchOrders(req.userId()));
            // Both forked tasks can read TRACE_ID.get() — it propagates automatically
            scope.join().throwIfFailed();
            respond(userTask.get(), orderTask.get());
        }
    });
}

Final Thought

Modern Java (21+) is a different language from the Java most people learned. Virtual threads, sealed types, records, pattern matching, scoped values, these aren't incremental improvements. They're fundamental shifts in how you model domains, manage concurrency, and structure production systems. The developers who internalize these patterns are writing Java that's as expressive as Kotlin and as safe as Rust, without leaving the ecosystem.

Vibe coding should accelerate development, not bypass validation

Dimitris Kyrkos — Thu, 11 Jun 2026 10:22:20 +0000

There's a gap in the vibe coding conversation that I think needs more attention.

The appeal is obvious. You describe what you want, AI generates code, it works, you ship. For prototypes and quick experiments that's genuinely powerful. The problem starts when teams treat that working prototype as production-ready code and skip everything between "it runs" and "it's ready for real users."

AI-generated code often gives you a strong starting point. But it also hides assumptions that don't surface until later. Outdated dependencies that nobody vetted. Patterns copied from older repos that don't match your architecture. Error handling that covers the happy path and nothing else. Security validation that's either minimal or missing entirely. Non-functional requirements like observability, scalability, and graceful degradation that never got considered because nobody prompted for them.

The thing is, none of this is new. Developers have always had to bridge the gap between "code that works" and "code that's production-ready." What's different now is the speed. When you can generate a full feature in 20 minutes, the temptation to skip the validation step is way higher than when it took you two days to write it by hand. The act of writing used to force a certain amount of thinking. Now that thinking has to be deliberate and separate from the generation.

The teams I've seen handle this well don't avoid AI tools. They just don't let the speed of generation compress the validation step. They still review for architectural consistency. They still check dependencies. They still verify error handling covers the failure modes that matter. They still run security scanning. The generation got faster but the bar for what ships didn't drop.The risk isn't that developers use AI.

The risk is that teams start treating generated code as finished code. Vibe coding is a starting point, not an endpoint.

What does your validation process actually look like for AI-generated code? Is it different from how you review human-written code, or is it treated the same?

AI's real value isn't automation. It's how fast you can act on what you already know.

Dimitris Kyrkos — Tue, 09 Jun 2026 06:40:51 +0000

Something I keep noticing across teams and orgs that are actually getting value from AI versus the ones that aren't.

The difference rarely comes down to the model or the algorithm. Most organizations are already drowning in data. Logs, metrics, alerts, reports, dashboards, tickets. The information exists. The bottleneck is what happens after the data shows up.

How long does it take to interpret what the signal means? Who decides what to prioritize when three things need attention at once? How fast can the right people coordinate a response once a decision is made?

That's where AI actually earns its keep. Not by replacing the human in the loop but by compressing the time between something happening and someone doing something useful about it. Signal to understanding to action. That's the chain that matters.

Think about it in terms you deal with every day. A vulnerability gets disclosed. The CVE exists, the advisory is public, your scanner picked it up. None of that is the bottleneck. The bottleneck is figuring out which of your services are affected, who owns them, how bad the exposure actually is in your specific context, and getting a patch scheduled before someone exploits it. AI that helps you answer those questions in minutes instead of days is genuinely valuable. AI that and adds another dashboard to look at isn't.

This applies across the board. Incident response, infrastructure management, risk assessment, customer systems, operational workflows. The teams getting real value aren't the ones with the fanciest models. They're the ones who figured out where their decision bottlenecks actually are and pointed AI at those specific gaps.

The strategic advantage is rarely in the algorithm. It's in organizational responsiveness. How fast can you go from "something happened" to "we're handling it". The AI is just the thing that compresses that timeline.

Where's the biggest decision bottleneck in your current workflow?

DEV Community: Dimitris Kyrkos

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

Functional doesn't mean correct. That's the biggest risk with AI-generated code.

The code runs. That's not the question.

Why this happens more with AI

The specific ways this shows up

Validation is the actual work

The uncomfortable bottom line

AI isn't a software upgrade. It's an organizational redesign.

The framing most companies get wrong

What changes when AI enters a workflow

Why this creates tension

The alignment problem nobody talks about

AI makes writing code easier. It doesn't make engineering easier.

The narrative is backwards

The gap is widening, not shrinking

What the teams doing it well look like

The role is shifting, not shrinking

Where the advantage actually lives

5 More Advanced Java Tips That Senior Engineers Actually Use

Hey everyone.

1. Use Structured Concurrency Instead of CompletableFuture Fan-Out

2. Use Record Patterns for Nested Destructuring

3. Sequenced Collections: Stop Guessing How to Get the First and Last Element

4. Foreign Function and Memory API: Replace Unsafe and JNI With Something That Actually Works

5. Build Custom Stream Operations with Gatherers

Final Thought

The Novo Nordisk breach hit patient data and proprietary AI models. The attack surface is expanding.

What happened

What the attackers are claiming

AI assets are now high-value targets

Leaked container images are architecture blueprints

Developer identities enable follow-on attacks

Why this matters beyond Novo Nordisk

5 Advanced Java Tips That Senior Engineers Actually Use

1. Replace Your Thread Pools with Virtual Threads for I/O-Bound Work

2. Use Sealed Classes with Pattern Matching for Exhaustive Domain Modeling

3. Compact Canonical Constructors in Records for Validated Immutable Data

4. Use MethodHandles for Reflection-Speed Access Without Reflection's Cost

5. Use ScopedValue Instead of ThreadLocal in Structured Concurrency

Final Thought

Vibe coding should accelerate development, not bypass validation

AI's real value isn't automation. It's how fast you can act on what you already know.

3. `mapMulti` for Allocation-Free Flat Mapping

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

4. Use `MethodHandles` for Reflection-Speed Access Without Reflection's Cost

5. Use `ScopedValue` Instead of `ThreadLocal` in Structured Concurrency