Stellar Cyber DevOps Engineering Manager Bhanu Kiran Kaithe on Why the Hard Part Is Not Building Software but Running It

The bill for a piece of software does not arrive when it is written. It arrives later, in installments, and someone other than the author usually pays it: the on-call engineer woken at two in the morning, the security team that finds a gap nobody designed against, the finance line that swells as a data pipeline quietly scales from two terabytes a day to fifteen. A program that runs once on a laptop has proved almost nothing about its ability to operate. The distance between those two states is where most of the real cost of software lives, and it is a distance that demos are designed to hide.

Bhanu Kiran Kaithe spends his working life in that distance. As an Engineering Manager for DevOps at the AI-driven cybersecurity firm Stellar Cyber, he leads a multinational team that operates and scales more than 300 customer data platforms ingesting billions of security events a day. When he reviews code, he is not asking only whether it works. He is asking who has to run it, what it will cost them, and where it will fail when it is no longer the author’s problem.

Kaithe, who scaled one platform’s ingestion from two to fifteen terabytes a day while cutting its cloud cost by sixty per cent, judged Code Olympics 2026 through the one question a demo can never answer on its own: could somebody else operate this.

Code Olympics 2026, organized by Hackathon Raptors, challenged teams to ship working software in 72 hours under four simultaneous constraints: a core technical rule, a strict line budget, an assigned project domain, and a programming language each team did not choose. The format produces small programs, but small does not mean simple, and the constraints have a way of exposing exactly the operational instincts Kaithe spends his days enforcing.

He is well placed to read them. Across more than fifteen years he has built and led DevOps teams at John Deere’s Blue River, at Qualys, and at Health Fidelity, shipping real-time AI systems into cybersecurity, precision agriculture, and healthcare. His published work runs to MLOps pipelines, autoscaling against real-time metrics, and shift-left security, and he serves as a peer reviewer for IEEE international conferences. The thread through all of it is operability: the unglamorous discipline of making software something a team can run, scale, secure, and afford long after the first commit.

Security Belongs Before the First Line, Not After the Breach

The submission that drew Kaithe’s sharpest approval was error909’s SpecGuard, and the reason says everything about how he reads code. SpecGuard is a tool that inspects a project at the earliest possible stage and flags the security, compliance, and operational requirements a team has not yet accounted for, before any of the code that would depend on them gets written.

“It addresses an important early-stage software problem: identifying missing security, compliance, and operational requirements before development begins,” Kaithe wrote, and he singled out the implementation choice that made it trustworthy: “The deterministic Java-based approach is a good design choice.” That word, deterministic, is not incidental praise. A requirements checker that returns a different answer on different runs is a tool a team learns to ignore. One that is deterministic can be wired into a pipeline and trusted as a gate.

This is the shift-left principle Kaithe has written about formally, applied in miniature. The cost of a missing security control is lowest before development starts and rises with every layer built on top of the gap, until it is most expensive of all once it has shipped and been breached. A 72-hour hackathon is the last place one expects to see a team internalise that economics, which is precisely why he rewarded it. SpecGuard treated security not as a feature to add but as a question to ask first, and that ordering is the whole of the discipline.

The Cloud Bill Is a Design Constraint

Where most reviewers would read a file-transfer tool as a networking exercise, Kaithe read Igeti’s r24u as a cost decision. The project moves large files by leaning on temporary Cloudflare infrastructure rather than standing up storage of its own, and he credited the judgement behind that choice rather than the novelty of the problem.

“This project demonstrates strong engineering judgement by focusing on a specific, practical problem rather than building a feature-heavy platform,” he wrote, and then he named the operational reality the team had clearly understood: “Large-file transfer is a common challenge, especially when cloud storage costs become significant.” A junior engineer optimises for whether the file arrives. Someone who has watched a cloud invoice grow optimises for whether the file arrives without provisioning a service that bills by the gigabyte-month forever after.

That instinct is the one Kaithe practises at scale. Taking a platform from two to fifteen terabytes a day while reducing its cloud cost by sixty per cent is not a feat of raw engineering so much as a refusal to treat infrastructure spend as someone else’s concern. r24u, in its small way, made the same refusal. It chose an architecture whose cost profile matched the problem, and in his rubric that is not frugality, it is design.

Determinism Is What Makes a System Auditable

The constraint domains pushed several teams toward systems programming, and Kaithe’s reviews there converged on a single property that has little to do with cleverness and everything to do with whether a system can be trusted in production: predictability.

He found it in krishnap’s GhostByte, a tool that embeds, inspects, extracts, and integrity-checks payloads inside binary files. “The append-only binary protocol is a smart design choice because it preserves the host file while enabling deterministic payload extraction,” he wrote. The phrase to dwell on is, again, deterministic. An append-only format does not mutate what already exists, which means the original is recoverable, the operation is auditable, and the same input yields the same output every time. In a security context, those are not niceties. They are the difference between a tool an incident responder can rely on and one whose behaviour they have to second-guess under pressure.

The same lens shaped his read of Team Batman’s Validator, a browser-based tool that checks whether a submission obeys the Code Olympics constraints. What he valued was its self-consistency: the validator obeys the same rules it enforces. “The fact that the submission obeys the same constraints it evaluates makes the solution particularly compelling,” he noted. A tool that holds itself to its own standard is a tool whose verdicts a reviewer can take at face value, and Kaithe, whose job is to trust automated gates across 300 platforms, knows exactly how rare and how valuable that property is.

Constraint as a Proxy for Operational Restraint

The line budgets and naming rules that define Code Olympics could be read as artificial. Kaithe read them as a rehearsal for the restraint that production operations demand, and his highest constraint-driven marks went to teams that turned the limits into discipline rather than treating them as a cage.

Sanjay Sah’s gosc earned that credit. A real-time animated 256-colour ANSI plasma effect, rendered in exactly 100 lines of pure Go with every variable name limited to three characters or fewer, is the kind of build that only works if the author understands precisely where the performance and memory budget is being spent. “A focused and impressive constraint-first submission,” he wrote, crediting the command of the runtime that real-time rendering under a hard line cap requires. Momo’s RustCard drew the same kind of nod: a spaced-repetition system with proper SM-2 scheduling, persistent progress, and session statistics, delivered in 83 lines of Rust with zero external dependencies.

The zero-dependency detail is the one an operator notices. Every dependency is a future upgrade, a potential vulnerability, and a thing that can break in an environment the author never tested. A tool that does its job without pulling in a tree of third-party packages is a tool with a smaller attack surface and a longer shelf life. Kaithe has spent years reducing exactly that kind of operational surface area across real fleets, and he recognises the instinct when a team shows it under a 72-hour clock.

When the Output Has to Earn Its Compute

Kaithe’s AI background, including peer-reviewed work on MLOps pipelines, made him a careful reader of the submissions that reached for machine learning, and there his standard tightened rather than loosened. He gave RAG’s Quizly real credit for architecture: “Quizly demonstrates a solid understanding of modern AI application design by combining retrieval-augmented generation with an educational quiz experience,” he wrote, noting that it integrated retrieval, generation, and an interactive interface into a coherent whole rather than bolting a model onto a thin wrapper.

That praise is notable because the easy version of an AI project in 2026 is a thin wrapper, and Kaithe has built the infrastructure that makes the difference between the two visible. A retrieval-augmented system has a defensible reason to exist: it grounds generation in real source material instead of inviting a model to improvise. His approval of Quizly was approval of an architecture that does work a simpler prompt could not, which is the same test he applies to every AI system his platforms run. The question is never whether a model is involved. It is whether the design earns the compute, the latency, and the operational complexity that a model brings with it.

Signal Against Noise, the Problem He Lives Inside

One submission sat unusually close to Kaithe’s own working reality, and his read of it showed why. Brain.exe’s SayLess tackles what the team called communication inflation: the swelling of documents, messages, and pull requests with AI-assisted filler that buries the actual decision under prose. Rather than generating more text, the tool works in the opposite direction, stripping the padding to surface the real action items and the genuine substance underneath.

“SayLess tackles a surprisingly important problem that many organisations are beginning to experience,” Kaithe wrote, crediting the team for building a tool that improves clarity instead of adding to the noise. The reason this lands with him is structural. His platforms exist to pull a small number of real security events out of billions of low-value ones every day, which is the same problem SayLess addresses in a different medium: the cost of finding signal rises as the volume of plausible-looking noise grows. A tool that reduces noise at the source is doing the same work as a detection pipeline that filters it downstream, and an operator who spends his life on the downstream side recognises the value of solving it upstream.

What he was rewarding, again, was a team that understood the shape of a real operational problem rather than one that had simply built something that runs. SayLess was not the most technically ambitious entry in the batch, but it was aimed at a cost that organisations are only beginning to feel, and being early to a real problem is its own kind of engineering judgement.

A Reviewer’s Checklist for Software That Has to Be Operated

Read across his batch and Kaithe’s scores resolve into a set of questions that map almost exactly to the work of running software at scale. They are worth stating plainly, because they apply far beyond a hackathon.

Was security asked about first? The cheapest place to close a gap is before the code that depends on it exists. A tool or a team that surfaces security, compliance, and operational requirements at the start has already done the most expensive work to defer.

Does the architecture respect its own cost? An approach that solves the problem while provisioning infrastructure that bills forever has not really solved it. The cost profile of a design is part of the design.

Is the behaviour deterministic and auditable? Append-only formats, reproducible outputs, and tools that hold themselves to their own rules are what make a system something an operator can trust under pressure rather than second-guess.

Is the dependency footprint as small as the job allows? Every dependency is future maintenance, future vulnerability, and a new way to break in an untested environment. Zero-dependency is not minimalism for its own sake, it is operational longevity.

Does the expensive component earn its place? Before a system reaches for a model, a service, or a moving part, the design should justify the latency, the spend, and the complexity it is taking on. Capability that is not earned is just cost.

Why Operability Is the Skill That Compounds

There is a reason a person who runs 300 platforms reads a 72-hour submission the way Kaithe does. The industry is very good at celebrating the moment software first works and very slow to reckon with the years it then has to run. As generation gets cheaper and teams ship faster, the scarce skill is not producing working code. It is producing code that a different person, on a different day, can operate, secure, scale, and afford without the author in the room.

That gap is widening, not closing. The tooling that lets a small team ship quickly does nothing to make the result easier to run, and often makes it harder, by hiding the cost and complexity behind a smooth first impression. An engineer who has inherited other people’s quick wins and had to keep them alive at scale learns to distrust the smoothness and look for the seams underneath.

The Code Olympics format, by stripping teams down to a few hundred lines in an unfamiliar language, surfaces that skill in a way a sprawling project would bury. The teams Kaithe ranked highest were not always the most inventive. They were the ones that asked the operator’s questions early: what does this cost, who has to trust it, where does it fail, and what does it leave behind. Those questions do not get easier at scale. They get more expensive to answer late. A judge who has paid those bills across real fleets spent his hours at Code Olympics rewarding the teams that had started asking them at line one.

Code Olympics 2026 was organised by Hackathon Raptors, a Community Interest Company supporting innovation in software development. The event challenged teams to build working software across 72 hours under four simultaneous constraints: a core technical rule, a line budget, an assigned project domain, and a programming language teams did not choose. Bhanu Kiran Kaithe served as a judge evaluating projects for functionality, constraint mastery, language adaptation, code quality, and innovation.