Notes from the workbench

A compiler intermediate representation sits in an interesting middle ground. It is more structured than source code, but more expressive than the machine instructions it eventually becomes. The IR is useful because it preserves the parts of the program that still matter while removing details that no longer do.

Machine learning systems have a similar problem. A research idea starts with a rich description: a model, a dataset, a training recipe, a metric, and an environment. By the time that idea reaches a production service, most of those details have been compressed into an interface. The question is what gets lost in the compression.

Good boundaries do not erase complexity. They put it somewhere deliberate.

That is why I keep coming back to compiler work when thinking about ML infrastructure. A useful interface should make the common path simple while keeping the information needed for optimization, debugging, and correctness visible to the layer that owns it.

The practical lesson is small: when designing an ML component, write down what the next layer needs to know. If the answer is only a tensor shape and a callback, that may be enough. If it needs provenance, timing, constraints, or uncertainty, make those first-class too.

Natural language is an appealing control surface because it lets people describe intent without learning a robot's entire command language. But intent is not a trajectory. A sentence such as “make the swarm form a wave” leaves many questions unanswered: how fast, how close, with what safety margin, and what happens if one vehicle cannot keep up?

Our SwarmGPT work treats the language model as a high-level choreographer, not as the final authority. The model proposes structure. A motion-planning layer turns that structure into executable primitives. A safety filter checks feasibility and makes the smallest correction needed for deployment.

That separation matters because it gives each layer a job it can be evaluated on. The language layer can be judged on expressiveness and usefulness. The planner can be judged on smoothness and coordination. The safety layer can be judged on whether it prevents invalid actions.

Expressive systems become trustworthy when the last word belongs to a constraint-aware layer.

The broader pattern applies beyond drones. Anytime an LLM is asked to control a system with hard limits, the design should make invalid actions difficult to express and easy to reject. The goal is not to remove creativity. It is to give creativity a safe place to operate.

Technical portfolios often become inventories: a row of tools, a collection of screenshots, and a set of links. Those things are useful, but they answer only one question: what did you touch?

The more interesting questions are about judgement. What was the constraint? Which part was uncertain? What did you measure? What did you decide not to build? Those details make a project legible to someone who was not in the room when it was made.

I want this site to work less like a trophy case and more like a lab notebook. The projects show outcomes, the research section shows the questions, and these notes are a place to record the bridge between the two.

That bridge is also where collaboration starts. A good collaborator does not need every implementation detail on the first page. They need enough context to see where their curiosity or experience could connect.