DEV Community: Dimitris Kyrkos

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?

2026's breach list is out and the pattern is depressingly familiar

Dimitris Kyrkos — Mon, 08 Jun 2026 08:56:33 +0000

TechCrunch just published their midyear roundup of the worst hacks and breaches of 2026, and if you read through it, the thing that stands out isn't how sophisticated the attacks were. It's how many of them came down to basics that weren't handled.

Passport scans and driver's licenses are sitting exposed on the open web because of simple misconfigurations. Over two million identity documents were leaked across hotel check-in systems, money transfer apps, and visa services. Not zero-days, not nation-state toolkits, just stuff left unsecured that shouldn't have been.

Open source supply chain attacks hit some major names this year, including security tools themselves. Backdoored packages made it into pipelines, auto-updates pulled down malware, and stolen credentials from compromised developer machines spread downstream into companies like OpenAI and Vercel. The pattern is always the same: compromise one trusted dependency, and you get access to everyone who consumes it.

The ShinyHunters crew didn't even need anything technical for most of their hits. Voice phishing. Calling up companies pretending to be IT support or a locked-out employee. That's how they got into Instructure and stole data on 30 million students. When the company didn't pay, they broke in again and defaced login pages during finals week.

And then there's the critical infrastructure side. Water treatment plants, power grids, and dams are all getting targeted across Europe and now the US. These aren't theoretical risks anymore; one attack in Norway caused a dam to physically spill water.

As developers, we tend to think of security as something the security team handles. But half of these breaches touch code we write, dependencies we pull in, infrastructure we configure, and pipelines we build. The supply chain attacks, especially, are a developer problem first and a security problem second.

The full list is worth reading: https://techcrunch.com/2026/06/07/the-worst-hacks-and-breaches-of-2026-so-far/

What's your team actually doing differently this year? Or is the answer honestly "not much"?

Vibe coding gets you the prototype. Then what?

Dimitris Kyrkos — Thu, 04 Jun 2026 07:02:36 +0000

There's a pattern I keep watching play out, and it almost always goes the same way.

Someone spins up a project using an LLM. The first few iterations are magic. Features land fast, the code runs, the demo looks great. Everyone's excited.

Then you hit iteration 15. Or 25. And things start getting weird.

A change in the auth module quietly breaks something in the payment flow. A refactor of the LLM suggested works perfectly for the file it touched, but creates a naming convention that conflicts with everything else in the project. Tests pass because they were generated against the same assumptions the code was, so they're both wrong in the same direction.

The core issue is that LLMs optimize for the immediate problem. They're incredible at taking a focused prompt and producing code that solves it. But they don't carry a mental model of your full codebase architecture. They don't know that the helper function they just created duplicates one that already exists three folders away. They don't remember that you made a deliberate decision two weeks ago about how the state is managed, and the code they just wrote violates that decision.

This isn't really an AI problem. It's the same problem that happens with any approach that prioritizes speed over structure. The difference is that AI makes it possible to accumulate tech debt at a rate that used to be physically impossible. You can generate a thousand lines a day, and every single one of them can be locally correct while the overall system slowly becomes unmaintainable.

What I've seen work is pretty boring, honestly. Treat LLM output the same way you'd treat code from a new contractor who's talented but has never seen your codebase. Review it in context, not in isolation. Keep architectural decisions documented somewhere that the human team references regularly. Run static analysis and complexity checks on every commit, not just linting but actual maintainability metrics, so you catch the structural rot before it compounds.

The teams that stay productive with AI long term aren't the ones generating the most code. They're the ones who figured out that the generation is the easy part and the integration is the actual work.

How are you keeping your codebase healthy as AI-generated code becomes a bigger percentage of what ships?

AI projects don't fail because the model is bad. They fail because nobody planned for the mess around it.

Dimitris Kyrkos — Wed, 03 Jun 2026 06:28:35 +0000

Something I keep seeing play out the same way across teams.
The model works great in testing. Accuracy looks good, latency is acceptable, and everyone's excited. Then it hits production, and everything slows to a crawl, not because the model broke but because the organization around it wasn't ready.

The real blockers are rarely technical in the way people expect. It's stuff like the data pipeline that feeds the model, pulling from three systems that format timestamps differently. Or the security team needing four weeks to approve an API endpoint nobody told them about. Or two teams, both thinking the other one owns monitoring for the inference service. Or a compliance review that nobody scoped into the timeline because "it's just an internal tool."

At enterprise scale, the implementation discipline ends up mattering as much as model quality. The teams I've seen actually get AI into production and keep it running treat the rollout more like an infrastructure project than an experiment. They map out the data dependencies, approval chains, ownership boundaries, and security constraints before writing the first line of integration code. Not because they love the process, but because skipping it means discovering it all in week six, when everything is on fire.

The pattern that works: treat AI deployment as organizational engineering, not just model engineering. The model is maybe 30% of the problem. The other 70% is making it work inside a real environment with real systems, real people, and real constraints.

What's been the biggest non-technical blocker you've hit trying to get something AI-related into production?

LLMs Generate Code, But They Can't Absorb Accountability

Dimitris Kyrkos — Fri, 29 May 2026 08:42:08 +0000

The accountability gap nobody wants to talk about

LLMs can help teams move faster than ever. That part is real. But there's a distinction that keeps getting blurred in the rush to ship AI-assisted code, and it matters more than the productivity gains: LLMs cannot absorb accountability.

A prototype generated with Claude or Copilot may look complete. It may run. It may even pass your basic tests. But the moment it reaches production, responsibility shifts back to the team that approved it. Not the model. Not the prompt. Not the tool that generated it.

The real question isn't who wrote it

The question that gets asked too often is "Did the LLM generate this code?" That's the wrong question. The questions that actually matter are:

Was it reviewed before release? Not skimmed. Not glanced at. Actually read, line by line, by someone who understands what each part does.

Was it tested? Not just the happy path. The edge cases. The failure modes. The scenarios the AI didn't think about because nobody prompted it to.

Was it validated against requirements? Code that works isn't the same as code that does what you actually need it to do in your specific business context.

Was it understood? This is the one that gets skipped most often. Understanding the code isn't optional. If nobody on your team can explain why it works, you can't maintain it, debug it, or extend it safely.

When things break, accountability becomes very real

The accountability gap only stays hidden as long as everything works. The moment something goes wrong in production, the questions get specific and uncomfortable:

Who checked the output before it shipped?
Who approved the architectural decisions?
Who verified the edge cases?
Who owns the legal and operational risk for what was deployed?

"The AI wrote it" is not an answer to any of those questions. Your customers don't care that the code was AI-generated when their data leaks. Your auditors don't care when they're reviewing your security controls. Your legal team definitely doesn't care when they're handling the fallout.

The team that approved the code is accountable for the code. That's true whether a human wrote every line or an AI generated 90% of it.

The discipline problem

Here's the uncomfortable reality: AI-assisted development doesn't reduce engineering responsibility. It increases it.

When you write code manually, the act of writing forces a certain level of understanding. You think about edge cases as you write the conditionals. You consider error handling as you set up the try/catch blocks. You make architectural decisions deliberately because each line takes effort.

When AI generates the code, all of that thinking can be skipped. The code appears, it looks reasonable, your tests pass, and you move on. The cognitive work once embedded in the act of writing is now optional, and most teams are quietly opting out.

That's the discipline problem. The faster you can generate software, the more deliberate you need to be about reviewing, validating, and understanding what was generated. The natural human tendency is the opposite: when something is easy to produce, we produce more of it without examining each piece as carefully.

What disciplined AI-assisted development actually looks like

The teams that are getting this right share a few patterns:

They treat AI output as a first draft, not a final answer. Generation is step one. Review, validation, and refinement are equally important steps that don't get skipped.

They have explicit review standards for AI-generated code. Not "review it like any other code" because in practice that ends up being lighter than necessary. Specific checklists that focus on the failure modes AI is known to exhibit: hallucinated APIs, missing edge cases, security anti-patterns, unvetted dependencies, and inconsistent patterns with the rest of the codebase.

They invest in automated validation. Because human review can't catch everything in the volume of code being generated, they layer in SAST scanners, dependency checkers, secret detection, and code quality monitoring tools that run on every commit. These don't replace review; they augment it.

They maintain understanding as a non-negotiable. Before code ships, someone has to be able to explain why it works and what it does. If nobody can, the code doesn't ship until someone can. This often means going back to the AI and asking it to explain, then verifying the explanation makes sense.

They make accountability explicit. Whose name is on the PR? Who approved it? Who's responsible if something breaks? None of that changes because AI was involved. The same humans are accountable.

The productivity trap

There's a trap that catches a lot of teams: AI generates code so quickly that maintaining the same review and validation rigor feels like it negates the productivity gains. So review gets faster. Standards get looser. The thinking step gets compressed.

This works fine until it doesn't. The first time a hallucinated API takes down production, or a security vulnerability gets shipped because nobody read the AI-generated auth code carefully, the cost of skipping the discipline becomes very concrete.

The teams that sustain real productivity gains from AI aren't the ones who skip review. They're the ones who use the time AI saves them to do better reviews. The generation got faster. The validation needs to get more thorough, not less.

The bottom line

LLMs are powerful tools. They can accelerate development significantly. But they exist within a system of human accountability that doesn't change just because the code came from a model instead of a keyboard.

If you're shipping AI-generated code to production, you own that code. Your team owns the review process that approved it. Your organization owns the consequences when something goes wrong.

That's not a reason to avoid AI tools. It's a reason to use them with the discipline they require.

How is your team handling accountability for AI-generated code? Are there explicit review standards, or is it being treated like any other code?

185,000 Affected in 7-Eleven Breach: Why Salesforce Is the New Soft Target for ShinyHunters

Dimitris Kyrkos — Thu, 28 May 2026 10:14:09 +0000

What happened

7-Eleven has confirmed a data breach that occurred on April 8, with breach notification site HaveIBeenPwned analyzing the leaked dataset and reporting that approximately 185,000 individuals are likely affected. The stolen data includes names, addresses, email addresses, and dates of birth, with additional fields compromised for a smaller subset.

The extortion group ShinyHunters claimed responsibility, listing 7-Eleven on their leak site in mid-April and demanding ransom payment by April 21. When that demand wasn't met, they offered the 600,000 Salesforce records for sale on a Russian hacking forum, and the data was eventually published online.

The pattern nobody can ignore anymore

This isn't an isolated incident. Over the past year, ShinyHunters has been systematically targeting Salesforce instances at major organizations including Instructure, Vimeo, Wynn Resorts, Vercel, and Medtronic. Mandiant put out a formal alert in February specifically about escalating ShinyHunters activity, and the pace has only accelerated since.

The attack vector pattern is consistent: phishing campaigns, third-party integrations, and misconfigurations. None of these are sophisticated zero-day exploits. They're the same fundamental security gaps that have been exploited for years, just applied systematically to a specific platform.

Why Salesforce is becoming the soft target

Salesforce holds an enormous amount of customer data across virtually every industry. CRM records, contact details, sales pipelines, support tickets, and increasingly, integrations with other internal systems that store even more sensitive information. For an attacker focused on scale, getting into a Salesforce instance is potentially worth more than getting into any single internal database.

What makes it especially vulnerable in practice is the gap between Salesforce's security capabilities and how organizations actually configure them. Salesforce gives you robust security controls, but they require deliberate configuration. The defaults aren't always restrictive enough, third-party app permissions tend to be over-scoped, and the API access surface is large.

What this means for developers and security teams

If your organization uses Salesforce or any other SaaS platform with similar trust dynamics, the lessons from these incidents are direct:

Audit your third-party integrations. Every connected app, every OAuth grant, every external integration is a potential attack path. ShinyHunters has been exploiting these specifically. Inventory what's connected, review what permissions each integration actually has, and revoke anything that isn't actively needed.

Tighten API access. Most Salesforce breaches involve API access at some point, often through compromised credentials or over-scoped tokens. Implement IP restrictions where possible, use shorter-lived tokens, and monitor for unusual API usage patterns like bulk data exports.

Train against phishing aggressively. Phishing remains the primary initial access vector. Generic security awareness training isn't enough. Run regular phishing simulations specifically targeted at the kinds of approaches ShinyHunters uses, including phishing pages that mimic Salesforce login flows.

Enable MFA everywhere and enforce it. This sounds basic but the number of breaches that succeed because MFA wasn't enforced on every account, including service accounts and integration users, is still staggering.

Monitor for data exfiltration patterns. Bulk data exports, unusual report generation, large API queries from new IP ranges. These are detectable patterns. The challenge is that most organizations aren't watching for them at the SaaS layer because they're focused on infrastructure monitoring.

The bigger structural problem

There's a deeper issue underneath the specific Salesforce angle. SaaS platforms have become repositories for sensitive customer data, but the security responsibility model is shared in a way that creates ambiguity. The vendor secures the platform. The customer is responsible for configuration, access controls, and integration security. In practice, that means a lot of organizations assume their SaaS data is more secure than it actually is because they trust the vendor to handle security.

ShinyHunters has built an entire operation around exploiting that gap. They don't need to breach Salesforce itself. They just need to find customers who haven't configured their Salesforce instance properly, and there are clearly enough of those to sustain a campaign that's hitting major brands month after month.

What 185,000 records actually means

The number gets reported as a statistic, but think about what's in those records. Names, home addresses, email addresses, and dates of birth for 185,000 people. That's enough to enable targeted phishing campaigns against every one of those individuals for years. It's enough for identity verification fraud. It's enough to be cross-referenced with other breach datasets to build comprehensive profiles.

The damage doesn't end when the news cycle moves on. It compounds as the data circulates and gets combined with other leaks.

The bottom line

If your organization handles customer data through SaaS platforms and you haven't done a recent audit of your configuration, access controls, and third-party integrations, you should treat that as urgent. ShinyHunters and similar groups have made it clear that any organization with a misconfigured Salesforce instance is a viable target regardless of brand size.

The 7-Eleven breach isn't an outlier. It's part of a pattern that's going to continue until organizations close the configuration gaps that make these attacks possible at scale.

How are you handling SaaS security at your organization? Are third-party integrations being audited regularly or is it mostly set-and-forget?

Source: https://www.securityweek.com/185000-likely-impacted-by-7-eleven-data-breach/

Most Organizations Don't Have an AI Problem, They Have an Integration Problem

Dimitris Kyrkos — Tue, 26 May 2026 13:05:50 +0000

The real bottleneck isn't the model

Building an AI prototype has never been easier. Spin up an API call to a model, wrap it in a UI, demo it to leadership, get applause. That part is genuinely a solved problem.

The hard part starts the moment the prototype has to leave the demo environment and actually function inside a real organization. And this is where most AI initiatives quietly stall, not because the models failed, but because the integration complexity was massively underestimated from the start.

What AI has to integrate with

When you build a demo, you control everything. The data is clean. The use case is narrow. The user is forgiving. There are no compliance constraints, no audit logs to maintain, no role-based access controls to enforce, no rate limits to manage, no downstream systems that depend on the output being in a specific format.

In production, every one of those constraints is real and non-negotiable:

Existing workflows that people have been doing the same way for years and don't want to change just because you built something new. Your AI tool either fits into how they already work or it gets abandoned in week three.

Governance structures that require approvals, sign-offs, and documentation for any new system handling company data. The procurement and security review process alone can take longer than the entire development of the prototype.

Operational constraints like uptime requirements, latency expectations, cost ceilings, and integration with existing monitoring and alerting infrastructure. A model that takes 12 seconds to respond is unusable in a chat interface no matter how good the answers are.

Compliance environments that dictate what data can be sent where, who can access what, how long data is retained, and what happens during an audit. A lot of "AI projects" die when legal asks one question about where the data flows.

Real accountability systems where if the AI gives a wrong answer, someone has to own the consequences. That changes everything about how the system has to be designed, monitored, and corrected.

Why prototypes lie to you

The dangerous thing about AI prototypes is that they make the integration challenges feel like an afterthought. The model works. The demo is impressive. Leadership gets excited. Everyone assumes the hard part is done.

But the prototype solved maybe 10% of the actual problem. The remaining 90% is operationalizing it: data pipelines, access controls, observability, error handling, fallback paths, audit logging, cost monitoring, user training, change management, and ongoing maintenance.

That 90% doesn't show up in demos. It shows up six months later when the rollout has stalled, the costs are higher than expected, the users aren't adopting it, and nobody is quite sure who owns the system anymore.

The pattern that actually works

The organizations getting real value from AI aren't building flashier demos. They're building systems that reliably fit into how the business actually operates.

That means starting with the workflow, not the model. Understanding the existing process in detail before introducing AI into it. Knowing exactly which step in the workflow the AI is improving and how the output flows downstream.

It means designing for accountability from day one. Who reviews the AI's output? What happens when it's wrong? How is feedback captured and used to improve the system? These aren't questions to figure out after launch.

It means treating AI as a component in a larger system rather than as the system itself. The model is one input. The rest is data pipelines, integration points, user interfaces, monitoring, and the human processes that wrap around all of it.

It means involving compliance, security, and operations teams early. Not as gatekeepers slowing things down, but as partners who can tell you what won't work before you spend three months building it.

What this looks like in practice for developers

If you're a developer building AI features into your product, the implications are concrete:

Don't ship the model, ship the system. That means error handling, retries, fallbacks, observability, cost tracking, and graceful degradation when the model is slow or wrong. These aren't nice-to-haves; they're the difference between a demo and production.

Design for observability from the start. Log every prompt, every response, every retry, every cost. You can't operate what you can't see, and AI systems fail in subtle ways that are impossible to diagnose without good telemetry.

Build in human review where it matters. Not every AI output needs human approval, but the ones that affect customer data, financial decisions, or compliance-sensitive outputs probably do. Design those review flows into the system, don't bolt them on later.

Plan for the model change. The model you use today will be deprecated, updated, or replaced. Your system architecture should make swapping models a controlled change, not a rewrite.

Document the data flows. Compliance teams will ask. Security teams will ask. Your future self will ask. Knowing exactly where data comes from, where it goes, and who can access it is foundational, not optional.

The long game

The companies building a durable AI advantage aren't winning because they have the best models. Everyone has access to roughly the same models. They're winning because they've built the systems, processes, and organizational capabilities to actually deploy AI reliably into the work that matters.

That's a much harder problem than building a prototype. It requires engineering discipline, operational maturity, and a willingness to do the unglamorous integration work that doesn't make for impressive demos.

But it's where the actual value lives.

What integration challenges have you hit moving AI from prototype to production? Curious to hear what surprised people the most.

DEV Community: Dimitris Kyrkos

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.

2026's breach list is out and the pattern is depressingly familiar

Vibe coding gets you the prototype. Then what?

AI projects don't fail because the model is bad. They fail because nobody planned for the mess around it.

LLMs Generate Code, But They Can't Absorb Accountability

The accountability gap nobody wants to talk about

The real question isn't who wrote it

When things break, accountability becomes very real

The discipline problem

What disciplined AI-assisted development actually looks like

The productivity trap

The bottom line

185,000 Affected in 7-Eleven Breach: Why Salesforce Is the New Soft Target for ShinyHunters

What happened

The pattern nobody can ignore anymore

Why Salesforce is becoming the soft target

What this means for developers and security teams

The bigger structural problem

What 185,000 records actually means

The bottom line

Most Organizations Don't Have an AI Problem, They Have an Integration Problem

The real bottleneck isn't the model

What AI has to integrate with

Why prototypes lie to you

The pattern that actually works

What this looks like in practice for developers

The long game

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

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