HEAL-A-Thon at PESU: 6 Hours to Impact
By the time I showed up at PESU for the HEAL-A-Thon, six-hour hackathons didn't intimidate me. I'd been building and shipping production systems for months. Tight deadlines were routine. I had a solid handle on agentic AI workflows and enough experience to know exactly how far I could push a short sprint.
By the time I showed up at PESU for the HEAL-A-Thon, six-hour hackathons didn't intimidate me. I'd been building and shipping production systems for months. Tight deadlines were routine. I had a solid handle on agentic AI workflows and enough experience to know exactly how far I could push a short sprint.
I decided to build something with weight. A kernel-level module for hospital systems that detects hypovolemic shock in ICU patients at least thirty minutes before onset. The concept: unify real-time data streams from multiple patient sensors, run them through a detection engine, and surface early warnings through a lightweight dashboard. Thirty minutes of advance warning could be the difference between intervention and catastrophe.
The stack matched the seriousness. C++ for the kernel module handling sensor data processing and unification. Python for the API layer and testing. A simple HTML, CSS, JavaScript dashboard for hospital staff to monitor patients in real time. The architecture was layered microservice / event-driven pipeline based: kernel at the core, API layer wrapping it, dashboard on the outside. All inputs and outputs standardized to HL7 FHIR, making the whole system plug-and-play with existing hospital infrastructure.
The hardest part wasn't writing code. It was finding data worth testing against.
A health-tech hackathon means you can't validate your system on synthetic numbers and keep a straight face during judging. I needed real ICU patient records. After some digging, I found PhysioNet's MIMIC-IV dataset: actual clinical data from ICU patients. Fed it through the module. The system identified hypovolemic shock indicators at least thirty minutes before onset in the test cases. Watching those early warnings surface on a dashboard I'd built hours earlier, knowing the underlying data came from real patients, was a feeling I hadn't expected.
Here's where it gets unsettling.
I built the entire system using an agentic AI workflow. One orchestration agent managing all the context and planning, linked to a development agent that wrote the code. After each run, the orchestrator tested the output, flagged issues, noted improvements, and kicked off the next cycle with updated context. Opus 4.6 as the orchestrator. Sonnet 4.6 as the development agent. Four runs. That's all it took to go from nothing to a fully functional, tested system capable of predicting a life-threatening condition in ICU patients.
Four runs.
The speed was exhilarating for about ten minutes. Then the unease settled in. By the end, I had a working system I barely understood. I could explain the architecture because I'd designed it. I could describe the data pipeline because I'd specified it. But the actual C++ implementation doing the heavy computation? I'd need to read through it like someone else's codebase. Because functionally, that's what it was.
That realization sat with me for days. The system was complex and medically significant. The bottleneck in building it wasn't compute or model capability. It was me. My ability to review, understand, and verify what the AI produced. We've reached a point where the constraint on AI-assisted development isn't the AI. It's the human trying to keep pace.
I built custom skills and prompts for the entire workflow. The GitHub repo has everything: each run, the memory bank, the prompt definitions, the skill structures. Worth looking through if you're curious about how to orchestrate agentic AI for system-level development.
Did I win? No. Turns out having the soft skills of a bar of soap doesn't help when you need to sell your project to judges. The system worked. My pitch didn't. Fair enough.
I'll be posting a detailed technical breakdown of the full agentic development process soon. Short version: it's equal parts wonderful and terrifying what you can build when you stop writing code and start directing the things that write it for you.
Links: