DEV Community: codecraft

The sepsis model that learned to predict the doctor

codecraft — Fri, 17 Jul 2026 07:22:03 +0000

In 2021, a team at Michigan Medicine ran an external validation of the Epic Sepsis Model across 38,455 hospitalizations. Epic's own documentation put the model's AUC somewhere between 0.76 and 0.83. Michigan measured 0.63. Sensitivity was 33%, meaning it missed about two-thirds of septic patients, and it still managed to fire alerts on 18% of everyone admitted.

The detail that should bother you as an engineer is in the inputs. One of the model's features was whether a clinician had ordered antibiotics. Ordering antibiotics means somebody has already suspected an infection. So the model was, in part, learning to predict a decision that had already been made, then congratulating itself on the prediction.

That is textbook leakage. It ran in production at hundreds of hospitals for years.

Why do healthcare AI pilots fail at scale?

Nobody caught it because the environment had no mechanism for catching it. There was no external validation until researchers did it on their own initiative, no post-deployment monitoring worth the name, and no owner whose job it was to ask whether the thing was still working.

This is the pattern underneath most stalled healthcare AI. The model is rarely the constraint. The real constraint is everything it plugs into: patient records spread across EHR instances that different departments bought in different decades, imaging sitting in a system that speaks to nothing, duplicate MRNs, coding standards that drifted three reorganizations ago, and operational data (scheduling, staffing, supply) that has never been joined to clinical data in any usable way.

Train on a curated dataset, and you get a demo. Point the same weights at live ingestion, and performance degrades quietly, which is the worst way for it to degrade.

What AI-ready infrastructure means

Four things, and they're all boring:

Interoperability. Data can actually move between clinical, operational, and administrative systems without a human exporting a CSV.

Governance: Someone owns data quality, someone owns access, while someone's name is on the model's performance next quarter.

Workflow integration: Output lands where the clinician already works. If it creates a parallel process, it creates one that gets eventually ignored.

A scalable operating model: Monitoring, retraining, and drift detection exist before you need them, not after a JAMA paper.

Miss one and you get pilot purgatory. Organizations that assess AI-ready infrastructure before procurement end up making very different buying decisions than those who discover the gaps at integration time, which is roughly when the budget is already committed.

Aged care shows the failure mode at its bluntest. Fall detection works fine in a lab. Deploy it into a facility where half the documentation is still paper, and the notification pathway was never wired into anyone's actual shift; also, the alert fires into a void. The system produces the appearance of intervention but the resident is still on the floor.

Questions worth asking before the demo:

Can you access the same patient consistently across systems, or are you resolving identity by hand?
Who owns data quality, by name?
Have the alert escalation paths been tested with real people on shift?
Is there a monitoring framework, or are you planning to find out from a study?

The unglamorous work is the real work. Nobody puts an interoperability audit in a board deck. It's still the difference between a system a nurse trusts at an unexpected time and one she's learned to click through.

Nobody would ship this Protocol

codecraft — Fri, 10 Jul 2026 15:21:35 +0000

Consider a message passed between two processes. No acknowledgment. No schema. No retry. The sender is throttled, the receiver is saturated, and the channel drops packets under load.

You would not merge that. Hospitals run it every twelve hours.
Communication failures during care transitions sit behind most serious adverse events, and that share has held flat while the industry shipped template after template.

Why do clinical handovers keep failing?

The remediation always lands on the human. Better forms, more training, and another mandatory field. Each assumes the sender skipped an instruction.

Look closer at what the sender is doing. A doctor, nineteen hours into a shift, is running lossy compression on twelve patients, deciding what to drop, pulling from records with holes, inside a rank structure where contradicting a senior costs something real. Exhaustion, uneven experience, rank, scattered records. Those conditions are the runtime, not an exception path.

A protocol that degrades under expected load was specified incorrectly. A finished SBAR form confirms that the payload left the sender. It reveals nothing about parsing, nothing about the downstream effect. Whether the receiving clinician read the critical field, whether anything happened in the next six hours, is entirely unobserved.

So the status page reports healthy while the service quietly loses data.

What real instrumentation would capture

Signal lives after the exchange, not during it. Did the care plan execute? Did escalation fire within the threshold? Did drift accumulate before anyone queried the state?

Wire those events back into the loop, and you have telemetry. Skip them, and you have an audit trail. Reframing the clinical handoveras a system to instrument rather than a ritual to enforce is what makes the failure mode addressable.

Why the tooling never reaches production

Electronic I-PASS functions. Model-generated summaries from existing notes function. Most sit indefinitely in a pilot. Rollouts fragment across sites, enablement trails deployment, and regulatory validation under HIPAA and EU MDR run slower than any clinical timeline tolerates.

A structured field clinician's bypass becomes overhead. The actual exchange moves out of band, unlogged, unreplayable.
We have world-class metrics on this, and metrics were never the constraint.

Fulfillment is just another API now

codecraft — Fri, 03 Jul 2026 13:06:02 +0000

For most of software history, the supply chain was the thing nobody wanted to touch. A monolith in the basement. Order in, inventory pulled, package out. It worked fine right up until e-commerce raised the overall demand and customers started expecting two-day delivery from a five-person shop.

That old model cracked because it assumed the world sat still. It doesn't. So teams stopped treating fulfillment as a locked black box and started treating it like something you can actually call from code.

What does an API-driven fulfillment architecture look like?

You break the monolith into pieces that each do one job well. Inventory visibility, order routing, carrier selection, and last-mile coordination. Each one lives behind a documented API. Instead of a single rigid system, you get modular services you can swap, reroute, or reconfigure without a full rebuild. If that pattern feels familiar, it should. It's basically the thinking behind microservices applied to physical goods.

The nice part is what opens up once those endpoints exist. Your storefront can check real inventory before it confirms an order, while your CRM shows a delivery window without a human looking for it. Logistics reroutes around a carrier delay automatically, and data that used to rot in isolated systems becomes something every touchpoint can query in real time. That single move is what pushes real supply chain digital transformation from a slide deck into production.

Why do teams move faster with composable fulfillment?

Because the boundaries get porous. Logistics no longer owns one silo while the e-commerce team waits three sprints for IT to broker an integration. The people closest to a problem can ship a fix against a component without triggering a system-wide change request. That's less a logistics upgrade and more an org-chart upgrade disguised as architecture.

What breaks when you go modular?

Plenty, if you're honest about it. More APIs mean more entry points, so auth and API security stop being optional. Independently deployed services drift, so you need real contract testing, or a small change in one place quietly breaks another. And most of you aren't greenfield. You're basically wiring modern services into a legacy ERP that predates REST. Expect coexistence, not a clean cutover.

Done right, fulfillment stops being the scary basement monolith. It becomes another layer you build on. An ongoing supply chain digital transformation turns delivery from a cost center into something that actually ships.

Latency is a Design Decision, Not a Performance Metric

codecraft — Thu, 25 Jun 2026 13:24:37 +0000

Users rarely say an app is slow. They just leave. They bail on the cart, close the tab, jump to a competitor, and usually can't tell you why. The friction registers emotionally before it registers consciously.

So if you're still treating latency as something to optimize after the build works, you're already behind.

Why is latency actually three problems, not one?

"Latency" gets thrown around like a single number. It isn't. There are three:

Analysis latency: time to interpret incoming data
Decision latency: the gap between analysis and action
Action latency: execution delay

At enterprise scale, these compound. A system that analyzes fast but acts slowly still ships a bad experience. Treat the stack as a chain where the weakest link sets your ceiling. Optimizing the visible stage while ignoring upstream or downstream delays is the classic trap, and the wins look real in isolation while the tail stays broken.

What reduces latency in a real-time data processing architecture?

No single fix solves this. A solid real-time data processing architecture makes decisions at several levels at once:

Geography. Data crosses physical distance. Edge nodes, distributed data centers, and PoP networks push processing closer to users and often decide whether you land under the threshold.
Caching, still one of the highest-impact moves. Keep hot data near the user and kill repeated retrieval.
APIs. The connective tissue. Lean, low-overhead APIs let data flow; sloppy ones turn every integration point into a bottleneck.

Stop shipping averages

A clean average that hides a slow tail still burns a real chunk of your users. Watch behavioral signals, like bounce rate, session length, and engagement depth, not just synthetic numbers under controlled load. Lighthouse, New Relic, and Datadog give you continuous monitoring, but the real discipline is treating latency as an ongoing operational practice, not a quarterly audit.

For context: past two seconds of page load, abandonment climbs sharply. In voice and video, anything over 50ms degrades quality before users consciously notice.

The teams winning here pull latency into product planning early, measure infra against retention instead of raw benchmarks, and stop treating performance and UX as separate conversations. Build the experience that feels invisible, and speed stops being a feature. It becomes the reason people stay.

Treating Carbon as a Constraint in your Supply Chain Logic

codecraft — Fri, 19 Jun 2026 13:28:43 +0000

Most carbon isn't decided in a sustainability report. Someone picks a supplier, weighs price and lead time, signs, and quietly locks in years of emissions nobody ever scored. The data existed. It just never entered the moment the choice got made.

Why carbon never reaches the decision layer

In most orgs, two systems never talk to each other. One produces targets and disclosures, the other produces purchase orders and vendor contracts. The emissions leak out in the gap between them. And that gap is huge, because supply chains drive up to 80% of a company's total greenhouse gas footprint. The people deciding your real environmental impact are buyers and logistics leads, and most of them have never seen a carbon number in their workflow.

Why Scope 3 is the hard part

Scope 1 and Scope 2 are direct and trackable. The real weight sits in Scope 3, the upstream emissions you don't control, which averages around 74% of an industry's footprint. The problem is that visibility falls off a cliff past your Tier 1 suppliers. This is exactly where most carbon emission reduction in supply chain efforts stall. Not at strategy, at the data pipeline. You can't weigh a number you can't get.

Why mandates don't move the needle

The instinct is to hand suppliers a list of ESG requirements. That mostly generates email. The suppliers with the heaviest emissions are usually the ones with the least capacity to respond, running thin margins with no sustainability staff. The teams seeing real results invest in a few high-impact suppliers directly instead of pushing the whole base at once.

Making it real-time

IoT feeds, AI procurement platforms, and joined-up analytics can already surface carbon intensity at the point of purchase. The blocker isn't the tech. It's the discipline to act on the number once it's on screen. That last step, turning a visible value into a different choice, is the one almost everyone underestimates.

Your turn

If you had to add one carbon signal to your sourcing decisions tomorrow, where would the data even come from? Drop how your stack handles Scope 3 visibility in the comments, because that pipeline is where most of us are stuck.

How enterprises are escaping platform lock-in

codecraft — Wed, 10 Jun 2026 15:14:38 +0000

Most enterprise commerce teams know the feeling. A feature your competitor shipped in two weeks takes your team three months, not because your engineers are slow, but because your platform won't get out of the way. That's the monolith problem. And composable commerce architecture is how enterprises are solving it.

What composable commerce architecture looks like in practice

Composable commerce architecture applies MACH principles (Microservices, API-first, Cloud-native, Headless) across the entire stack, not just the frontend. Instead of one platform owning everything, each capability is a discrete, replaceable service.

In practice, that looks like this: your PIM is Akeneo, search is Algolia, payments are Stripe, content lives in Contentful, and cart/checkout runs on commercetools. Each service exposes APIs. Each can be swapped, upgraded, or scaled independently without touching the others.

The frontend consumes all of it through a composition layer. No single vendor owns your roadmap anymore.

Why enterprises are moving now

The numbers back the urgency. 91% of organizations are currently expanding their MACH infrastructure, and 61% expect to achieve a fully composable architecture by 2026. This isn't experimentation anymore. It's a structural shift in how enterprise commerce is built.

The legacy systems problem is real, though. Organizations with more than 51% legacy systems face a demanding financial equation, with 48% of the budget going toward MACH software acquisition alone. The transition cost is high, and the cost of staying put compounds silently.

The ownership question nobody asks early enough

Composable commerce architecture isn't just a technical decision. It's a platform ownership decision.

With a monolith, your vendor owns the upgrade cycle, the feature backlog, and by extension, your release velocity. With a composable stack, your team owns the assembly. You choose the best tool for each capability and integrate on your terms.

The tradeoff is real: more surface area to manage, more integration complexity, more engineering discipline required. But for enterprises at scale, that tradeoff becomes worth it the moment a critical business need gets blocked by a vendor's quarterly release cycle.

Start with the seams in your current platform, the places where your business needs outpace what the vendor delivers. That's where composable commerce architecture earns its value first.

Why Playwright 1.59 shifts test automation from speed to context

codecraft — Wed, 03 Jun 2026 14:33:32 +0000

Most test suites today answer one question: Does this element exist on the page? Playwright 1.59 is built around a harder question: is the application behaving the way users actually expect?

That is not a small distinction. It is a fundamentally different problem.

What is context-aware testing, and why traditional suites keep breaking

Traditional test scripts break because they are tightly coupled to specific UI states. A layout change, a renamed class, a structural tweak, and suddenly tests fail even though the application behavior is completely correct. The fragility is not a tooling problem, but a design problem.

Playwright 1.59 reflects a broader shift in playwright test automation toward validating workflows and intent rather than individual elements. The test suite stops acting as a UI consistency checker and starts acting as a behavioral signal.

How Playwright 1.59 turns CI failures into explainable narratives

A red CI run tells you something broke, but it rarely tells you what happened, in what sequence, and under what conditions.

The updated Trace Viewer lets teams group actions into logical steps and navigate complex end-to-end flows visually. The new Screencast API adds annotated video recordings to CI runs. A failing test with an attached video is a completely different debugging experience than a stack trace and a screenshot.

You can now see what led to the failure, which makes it much easier to tell the difference between an actual bug, flaky infrastructure, and broken test logic. Those three things look identical in a log, but very different on video.

How standardised debugging reduces test triage time across teams

The new --debug=cli flag gives teams a consistent, repeatable investigation path. When any engineer can follow the same process regardless of their familiarity with the test suite, triage time drops, and knowledge stops being siloed with whoever built the tests originally.

Why accessibility testing belongs in the same pipeline as functional tests

The deeper Axe Core integration means WCAG compliance checks run in the same CI pipeline as functional tests. Accessibility becomes a regression you catch in development, not a retrofit you fund after launch.

The inflection point is not when complexity forces a change. It is when teams decide to get ahead of it. Playwright 1.59 gives them the tools to do exactly that.

Shift-Right testing: The reality check every QA strategy needs

codecraft — Fri, 29 May 2026 13:53:44 +0000

For years, software teams treated quality as something that could be validated before release. Run the test suite. Pass regression. Deploy.

The problem? Software rarely breaks in staging.

It breaks when thousands of users interact with it in ways nobody anticipated.

A feature that worked perfectly in testing suddenly slows down under real traffic. An edge case appears that never existed in your test scenarios. A dependency fails in production even though every pre-release check passed.

That is why more teams are embracing Shift-Right testing.

Production is where quality gets measured

Shift-Left testing remains essential. Catching defects early is still one of the most cost-effective practices in software engineering.

But Shift-Left only finds the issues you know how to look for.

Shift-Right focuses on what happens after deployment. It treats production as a source of quality insights rather than simply the destination. Real user behavior, live traffic patterns, performance bottlenecks, and production incidents become inputs for improving future releases.

The goal is simple: learn from reality instead of relying entirely on assumptions.

Observability is the foundation

Shift-Right cannot work without strong observability in software testing.

Logs, metrics, traces, and APM tools provide visibility into how applications behave under real-world conditions.

Without observability, production remains a black box. Teams discover issues only after users report them, but with observability, teams can identify anomalies early, correlate issues to deployments, and understand the impact of failures across services and user journeys.

The difference is not just faster troubleshooting. It is faster learning.

User behavior is test data

One of the biggest flaws in traditional testing is that engineers test what they expect users to do, but users rarely cooperate.

They click unexpected paths, abandon workflows halfway through, and combine actions in ways no test case anticipated. Production data reveals these patterns.

Session recordings, error reports, click paths, and support tickets often expose quality issues that never appear in pre-production environments.

That makes user behavior one of the most valuable testing inputs available.

The future of Quality Engineering

The most effective engineering teams no longer view release day as the finish line but the start of the feedback loop.

As observability platforms, AI-driven anomaly detection, and automated monitoring continue to evolve, production will become an even more important source of quality intelligence.

Because software quality is not proven before release.

It is revealed after real users start interacting with your system.

How Zero Trust Architecture is becoming essential in healthcare

codecraft — Thu, 07 May 2026 14:30:15 +0000

Zero Trust architecture is becoming essential in healthcare because traditional perimeter-based security models can no longer protect modern hospital environments from ransomware, identity attacks, and third-party vulnerabilities.

Healthcare is one of the few industries where a cybersecurity failure can directly impact patient safety, not just data loss or operational downtime.

That’s why Zero Trust architecture is becoming critical for modern healthcare systems.

Traditional security models assumed that users and devices inside the network could largely be trusted once authenticated. But hospitals today operate across cloud platforms, remote clinicians, connected medical devices, telehealth systems, third-party vendors, and legacy infrastructure that was never designed for today’s threat landscape. That complexity has made healthcare one of the most targeted industries for ransomware and credential-based attacks.

Zero Trust architecture changes this model completely by enforcing continuous verification instead of implicit trust. Every access request is authenticated, authorized, and validated in real time based on identity, device posture, behavioral signals, and contextual risk. Access becomes temporary, granular, and continuously monitored instead of broadly persistent.

This matters because ransomware in healthcare is not just a financial problem. A compromised system can disrupt emergency care, delay diagnoses, and impact critical patient services. That is why healthcare organizations are increasingly investing in MFA, least-privilege access, microsegmentation, behavioral analytics, AI-driven threat detection, immutable backups, and continuous monitoring as part of a broader Zero Trust architecture strategy.

What stood out to me most is that Zero Trust is no longer just a cybersecurity framework. It is becoming part of operational resilience itself, where security, observability, identity governance, and recovery workflows all work together to reduce clinical and operational risks.

Nobody planned their cloud architecture, and that is the problem

codecraft — Fri, 24 Apr 2026 12:01:50 +0000

One chooses AWS, another picks Azure, and some legacy systems never move. Now you are managing all of it without ever planning to. That is basically the norm today.

Hybrid vs multi-cloud: what actually separates them

Hybrid cloud is about integration. You connect private or on-prem infrastructure with public cloud, and workloads move between them based on compliance rules, performance needs, or where data legally has to live.

A multi-cloud strategy is about diversification. You run workloads across two or more public providers without necessarily linking them. The point is avoiding dependency on any single vendor's pricing, uptime, or roadmap.

They are not competing approaches. Plenty of organizations run both. The problem is that most are doing it accidentally.

Why is this getting harder to ignore

AI workloads are shifting the math. Training models and running inference at scale needs specialized GPU infrastructure that is not evenly distributed across providers. Your best general-purpose cloud is often not your best AI cloud, and that is pushing more teams toward a deliberate multi-cloud strategy rather than defaulting to whoever they already use. On the other side, regulated industries are not going to fully public cloud anytime soon. Healthcare, finance, and government, these environments have data residency requirements that make it legally complicated. Hybrid cloud is not a transitional phase for them. It is the long-term architecture.

The real issue is not which model you pick

The risk is not choosing one approach over the other. The risk is running a complex distributed environment without any coherent framework governing it. Complexity without intention is just debt.

The teams getting this right are starting from workload requirements and working backward to infrastructure decisions, not picking a model and forcing everything into it.

Hot take: most "AI-powered" products are just regular products with an API call in the middle

codecraft — Fri, 17 Apr 2026 14:09:53 +0000

That's not a diss. It's where most teams start. But there's a real gap between wiring up an LLM and actually building a system that learns from its environment, adapts to changing conditions, and doesn't quietly rot the moment your data drifts.

This is where product engineering starts to matter, especially when AI systems move from experimentation to production.

AI-driven product engineering is a different discipline. It's not about the model you pick. It's about how you design the feedback loops around it.

A few things I keep seeing separate the teams shipping intelligent systems that hold up in production:

Observability is non-negotiable. If you can't see how your model is influencing decisions in real time, you can't debug it, you can't improve it, and you definitely can't explain it to a stakeholder at 9 am when something breaks. Strong product engineering practices make this visibility a built-in capability rather than an afterthought.

Adaptability has to be designed in, not added later. User behaviour changes. Business logic changes. Retraining pipelines, feedback mechanisms, and fallback paths need to be first-class concerns from day one, not things you bolt on after your model goes stale.

Sustainability means more than green compute. It means building systems your team can actually maintain six months from now. That means clean abstractions, documented decision boundaries, and governance that doesn't make engineers want to quit.

The products that compound in value over time aren't the ones with the most sophisticated models. They're the ones built on disciplined engineering around the model.

Curious what patterns others are using to keep AI systems adaptive in production. What's working for your team?

Your AI Pilot worked. So why is ROI still MIA?

codecraft — Thu, 09 Apr 2026 16:39:30 +0000

The gap nobody talks about

Most enterprise AI pilots succeed. The demo is clean, the sponsor is excited, and the productivity numbers look promising. Then it goes to scale and quietly falls apart.

This is the pattern playing out across almost every large organization right now. Adoption is up, investment is up, and sustained ROI is still concentrated in a frustratingly small group of companies.

The models aren't the problem. The execution is.

When AI moves from pilot to production, a few things tend to go wrong fast: nobody owns the outcomes, measurement gets stuck tracking adoption instead of business impact, and governance gets bolted on after the fact when it's already too late to matter.

Complexity scales. Accountability diffuses. ROI flatlines, especially when enterprise AI solutions are deployed without clear ownership or operational alignment.

What separates the companies actually compounding value

It's not the fanciest models or the biggest budgets. It's execution discipline, clear ownership, governance embedded into the workflow from day one, and performance measurement tied to actual business outcomes rather than usage metrics.

AI amplifies what's already there. Strong execution culture gets stronger. Fragmented ops get more fragmented, which is why scaling enterprise AI solutions requires operating model changes, not just better models.

The question for most engineering and product teams right now isn't whether AI works. That's settled. The question is whether your operating model is built to capture the value at scale.

Pilots are easy. Operationalizing is the hard part. That's where the real work is.