Zendrop CTO Mikita Hrybaleu on Why Code Written by Machines Has to Arrive With Its Own Proof

Zendrop CTO Mikita Hrybaleu on Why Code Written by Machines Has to Arrive With Its Own Proof

The engineering leader whose team ships AI agents to merchants and supervises a codebase that is mostly machine-written spent the Zero Dependency 2026 hackathon reading for one thing: whether a team could show that its software did what it claimed. The submissions he rated highest did not ask to be trusted. They handed over the evidence.

The opening line of the Zero Dependency 2026 brief was written for a world in which a large share of new code comes from a model: "Half your code is written by an AI that hallucinates the other half's package names." The second line put a number on the risk. Public registries catalogued 454,600 new malicious packages in 2025, according to the Sonatype figures the organisers cited, pushing the cumulative total past 1.2 million. When a model suggests a package that does not exist, someone can register that name and wait. The attack has a name now, slopsquatting, and it turns a moment of misplaced trust into a running process on a developer's laptop.

Mikita Hrybaleu lives on the other side of that sentence. As Chief Technology Officer at Zendrop, an e-commerce fulfilment platform serving more than 300,000 connected Shopify and Wix stores, he runs an engineering organisation that has gone AI-first: between 65 and 95 percent of production code is generated, and engineers spend their time supervising, orchestrating and reviewing it. Over the past year his team shipped Zendrop's AI product line, including an MCP server listed in OpenAI's ChatGPT app catalog that lets merchants automate their dropshipping business with AI agents, an in-app merchant copilot, and Addrop, a standalone AI creative studio and the company's first product of its own. Before Zendrop he spent 20 years across game distribution, financial technology and e-commerce SaaS, growing from full-stack developer to software architect to CTO. He mentors founders through the EBRD-backed XMENTOR programme and has judged hackathons including the IEEE Response Quest Challenge.

Zero Dependency 2026, organised by Hackathon Raptors, ran for 72 hours from August 28 to 31 with a single rule: ship something genuinely useful with an empty dependency manifest. No crates, no npm packages, no go.sum, only the standard library of the language each team chose. 295 projects were submitted and judged. Hrybaleu reviewed two full batches of them, and the event's rules matched the standard he already runs his own team on. The organisers said plainly that they did not care whether participants used AI. They cared whether the result held up: "If the artifact can't be defended in writing, it scores accordingly."

A supply-chain scanner built with no supply chain

The project that sat closest to Hrybaleu's daily work finished second overall. Stranger, from the team Cause Of Death, reads a lockfile and reports the dependencies a developer has never actually met: package names that look hallucinated, code that runs at install time, and the same package sitting in the tree at four different versions. The event's own write-up called it a supply-chain tool built with no supply chain, and it scored 4.76 out of 5.

A slopsquatting detector is an easy thing to describe and a hard thing to make trustworthy. Flag every unfamiliar name and the tool drowns its user in false positives. Flag too few and it misses the one name that matters. Stranger narrowed its rule with an additional condition: a suspicious name is reported when, among other things, nothing else in the dependency graph points to it, which is the shape a package takes when a person or a model added it by hand rather than when it arrived as part of a real library's tree.

What Hrybaleu credited was not the idea but how the team defended it. His review named "differential testing against CPython's json and an ablation quantifying the no-parent clause instead of asserting it." Both halves of that sentence describe a habit that matters more as code generation gets cheaper. Differential testing means the team's hand-written JSON parser was run against Python's own json module, so disagreements show up as test failures rather than surprises in production. An ablation means the team switched off its own design choice and measured what changed. Most projects that add a clever filter simply state that it reduces noise. Stranger showed by how much.

His one request was small and specific: "One ask: print the corpus snapshot date in scan output." The reasoning follows from how the tool works. Stranger compares names against a corpus of known packages, and any corpus is a photograph of a registry on a particular day. A name that is absent today may be published tomorrow, by its real author or by an attacker. Printing the snapshot date tells the person reading the report how old the photograph is, which is the difference between a finding and a finding with its limits stated. It is the kind of note an engineer writes after years of reviewing systems that were correct when they shipped and quietly drifted afterwards.

Proof documents that say what they do not prove

The theme of evidence ran through the rest of his batch. Netlens, from the team Tacos, scored 4.53 and earned some of his strongest language. "The honesty architecture stands out," he wrote, pointing to "a dependency verifier running with the tests, a proof doc stating what each check fails to prove, and disclosed ICMP shell-out where Node lacks raw sockets."

Each item in that list answers a different trust question. A dependency verifier that runs with the test suite means the empty manifest is checked on every run rather than claimed once in a README. A proof document that names what each check fails to prove is unusual in any codebase, let alone one written in 72 hours, because it requires the authors to think like a hostile reviewer of their own work. The ICMP disclosure is the most telling of the three. Node's standard library does not expose raw sockets, so sending an ICMP packet from Node without a native module means calling out to the operating system. The rules said that shelling out to a separately installed tool counts as hiding a dependency. Netlens did not hide it. The team wrote it down, explained why the platform forced it, and let the judges weigh it. On the engineering itself he was direct: "The DNS codec and X.509 parser are senior-grade." He also asked the team to "Deduplicate the README, it deserves a clean front page," a reminder that documentation is read by people deciding whether to trust a tool, and a cluttered first page costs that trust before the code is ever opened.

Two other entries in his batch turned the zero-dependency claim into something a machine could check. Of Leaklens, by Solo- Yogesh, he wrote that it handled "real packfile internals with hostile-input hardening," and that its built-in prove mode, a self-audit, "makes zero-dep machine-checkable." A tool that parses git packfiles is processing data it did not create and cannot assume is well formed, so hardening against hostile input is the baseline for a security tool, not an extra. The prove mode goes further: it lets anyone ask the tool to demonstrate its own dependency status instead of taking the team's word for it.

JValue, from code-ops, drew the shortest and perhaps the most pointed comment in his batch: "Your STDLIB.md plus the jdeps proof is what zero-dependency honesty should look like." STDLIB.md was the event's required receipt, a file naming each package a team would normally have installed and the standard-library feature used instead. jdeps is the dependency analysis tool that ships with the Java Development Kit. Putting the written receipt next to a tool-generated proof means the claim and the evidence can be compared line by line. For a reviewer who reads machine-written code all day, that pairing is the whole point. A statement is cheap to generate. A statement that an independent tool confirms is not.

Crash shapes and torn tails

A second group of projects in his batch were storage engines and logs, the kind of software that is easy to demonstrate and hard to make correct. A key-value store that works while the process stays alive proves very little. The real question is what is on disk after the power goes out halfway through a write.

Needle, from hollanov, is a full-text search engine in pure Go, with its own tokenizer, stemming, inverted index and ranked search over local files. It finished in the event's Excellence tier at 4.63. Hrybaleu's review singled out the persistence layer: its "durability design is production-grade, and the WAL treats a torn tail as an expected crash shape, with tests." A write-ahead log with a torn tail is what remains when a process dies mid-append: a final record that was only partly written. Engines that treat this as an exceptional error tend to refuse to start, or worse, read garbage. Engines that treat it as an expected shape detect the partial record, discard it, and recover to the last complete state. The phrase "with tests" is the part that separates a design note from a guarantee.

The same standard showed up in his comment on nobroker, by Semicolonscopy: "The crash-test suite is the most convincing part of the project," built on "kill-based tests plus per-byte torn-tail coverage." Kill-based testing means the suite actually terminates the process at points during a write and checks what survives. Per-byte coverage means the torn-tail case is checked at every byte offset, not just at a few convenient boundaries. That is exhaustive in a way that hand-picked examples never are, and it is exactly the kind of evidence that holds up regardless of who, or what, wrote the code under test.

Forge, from Forge_Labs, earned the phrase "Serious craft" and a note that "the checksummed log store with bit-rot resync and forge explain's per-term log-odds both impress." Checksums on every record let a store notice when stored bytes have silently changed. Resyncing after bit rot lets a store skip past the damage to the next valid record rather than failing outright. The second half of the comment points at a different kind of honesty: a command that explains a result term by term, so that a user can see why the tool decided what it decided.

Hrybaleu's own track record gives this part of his reading some weight. At Zendrop he took the platform through hypergrowth to more than 99.9 percent uptime, grew test coverage from near zero to more than 70 percent, and put CI/CD quality gates around an AWS migration. Those numbers describe an engineer who has learned that reliability is something a system demonstrates under failure, not something its authors describe.

Threat models written where the code lives

Parcel, from beTheNOOB, drew the label "Standout craft" for "hand-rolled HKDF, a complete QR encoder with real Reed-Solomon, and threat models written into package docs." HKDF is the standard key derivation function defined in RFC 5869, and writing it by hand rather than importing it is the sort of substitution the event set out to reward. A QR encoder with real Reed-Solomon error correction is a substantial piece of mathematics to write from scratch in a weekend.

The last item in his list is the one with the widest reach. A threat model usually lives in a separate document, if it exists at all, and drifts away from the code it describes. Writing it into the package documentation keeps the assumptions next to the functions that depend on them. That habit matters more in a world of AI agents acting on real systems. When Hrybaleu's team ships an MCP server that lets merchants hand parts of their business to an agent, the questions of what that agent is allowed to touch, and what happens if its inputs are hostile, are not abstract. A codebase that states its threat model where a reviewer will see it is a codebase that can be reviewed for the right things.

Scoring what was submitted, and only that

Not every entry in a batch of this size arrives complete. For Homevault, by Second, Hrybaleu wrote: "No code link was submitted, so there was nothing to review," adding that "the scores reflect that, not your idea."

The comment is short, but it shows the same discipline as his praise. A judge who rewards evidence has to apply the rule in both directions. An idea without an artifact cannot be evaluated, however promising it sounds, and saying so plainly while separating the score from the person's idea is a fair way to deliver bad news to a team that may well have built something worth seeing. It is also the standard an AI-first organisation has to hold: a pull request description is not the pull request.

What the receipts mean for teams that let models write the code

Zero Dependency 2026 was nominally about package managers. Read through Hrybaleu's comments, it was also a test of what a reviewer needs from code that nobody on the team typed by hand. The event's FAQ said it directly: tools such as Claude Code, Cursor, Aider and Copilot were all expected, and the README, the STDLIB.md and the empty manifest were the receipts.

That framing maps closely onto how an AI-first engineering organisation has to work. When most of the code is generated, the scarce resource is no longer the ability to produce an implementation. It is the ability to show that an implementation is correct, that its claims about itself are true, and that its limits are written down. The projects Hrybaleu rated highest supplied exactly those things: a differential test against a reference implementation, an ablation that measured a design choice, a dependency check that runs with every test, a proof document that names its own blind spots, a crash suite that truncates the log at every byte, a threat model sitting next to the code.

None of those artefacts requires a large team or a long timeline. Several of them were produced in 72 hours by small teams and solo developers. What they require is a decision to treat every claim as something a sceptical reader will check, and to make the check easy. The event's organisers summed up the result in one line: the empty manifest turned out to be a test of honesty more than cleverness. For an engineering leader whose reviewers read machine-written code every day, that is the right test to set, and the teams that passed it were building software in the way the next decade of engineering will need.

Zero Dependency 2026 was organized byHackathon Raptors, a Community Interest Company supporting innovation in software development. The event ran for 72 hours from August 28 to 31, 2026, and 295 projects were submitted and judged, each built with an empty dependency manifest using only the standard library of its language. Mikita Hrybaleu served as a judge evaluating submissions on Functionality & Usefulness, Zero-Dependency Craft, Code Quality & Idiom, and Innovation.

For a broader look at trustworthy AI-assisted work, see The Great AI Arbitrage.