Name-based reflective dispatch in a Go agent shipped to edge devices — do you allow it, and who decides?

## What the decision actually is A team proposes a registry: types register themselves by name, and at run time the agent looks up a name that arrives in a message and dispatches to it. It is elegant, it removes a switch statement, and it makes adding a type a one-line change. It also silently changes the contract with the linker, because a method name computed at run time cannot be enumerated at build time, so the linker retains exported methods and their metadata that it would otherwise have discarded — along with everything those methods reach. On a service behind a load balancer, few people would notice. On a single binary pushed to constrained devices over a slow or metered link, the artifact is a product constraint, and the person who owns that constraint is not the person writing the registry. That asymmetry is what makes this a policy question rather than a code-review question. ## Set the rule where the cost lands - **Name the owner.** Whoever owns the device image and the rollout owns the size ceiling. They set the number; they can veto a change that crosses it. - **Make the ceiling mechanical.** Record the artifact size on every build and fail the pipeline above the agreed limit. A number in a document is a suggestion; a failing build is a decision. - **Require evidence, not argument.** Any change proposing dynamic dispatch arrives with a before-and-after measurement of the real artifact for the real target. This converts a debate about elegance into a number people can weigh, and it is often surprising in both directions. - **Keep the exception path short.** There must be a way to say yes — a named approver and a recorded justification — or the rule gets routed around. ## Default to the boring alternative Explicit registration achieves nearly everything the reflective registry does: a map from a string key to a function or constructor value, with each package registering its own entries. Every reference is static, so the linker prunes normally; the compiler checks the wiring, so a rename is a build failure instead of a run-time one; and the table is greppable, so the next reader can find every implementation. If the ergonomics of writing those entries is the objection, generate them — the generated file is still statically wired. Reserve name-based lookup for cases where the set of names genuinely is not known at build time, which is a much smaller set than it first appears. ## Weigh the costs that are not bytes Size is the visible cost and rarely the worst one: - **Refactoring safety.** A method reached only by string is invisible to the compiler and to rename tooling. The failure appears in the field. - **Reachability reasoning.** Every tool that answers *is this code used* is now wrong, which affects dead-code cleanup, coverage interpretation and security review of what actually ships. - **Blast radius.** Retention is not local. One reachable lookup changes what the linker keeps across the whole program. Against that, the honest case for allowing it: a plugin surface whose implementations genuinely arrive from outside the build, a decoder over shapes that are not known until run time, or a migration where writing the static table now would block a delivery that matters more than the megabytes. ## Where to draw the line for a constrained target My default position: name-based dispatch is not permitted in the code paths reachable from the device artifact; it is permitted in tooling, tests and server-side components, where the artifact is not the constraint. If a device feature needs it, the request goes to the artifact owner with a measurement attached, and the answer is a number, not a principle. That is deliberately a *default with an override*, not a ban. A ban invites people to hide the mechanism, and a mechanism you cannot see is worse than one you priced. ## What interviewers are checking That you separate the technical fact (dynamic lookup defeats dead-code elimination) from the organisational decision (who sets and enforces the size budget); that you propose a mechanical guardrail rather than relying on reviewer vigilance; that you can name a cheaper default and say when the expensive option is still right; and that you are honest that the non-size costs — lost compile-time checking and lost reachability reasoning — often outweigh the megabytes.