Lucas Meijer

Lucas Meijer builds AgentsInTheCloud, an open-source environment for running coding agents on a developer’s own server, with a choice of model providers and workflows designed for evaluating their work. His background includes running engineering and shaping technical direction at Unity. Across engine architecture and smaller developer tools, Lucas has addressed concrete obstacles: making performance easier to inspect, simplifying filesystem operations, and keeping agent execution visible.

Unity: changing how the engine handles code and data

Lucas joined Unity in 2009. His account of the company’s growth spans a living-room operation, running its engineering organization, presenting development teams’ work, and focusing on technical direction. These were roles within a collective effort that grew into a public company.

In his 2019 writing about Unity’s Data-Oriented Tech Stack, or DOTS, Lucas explained the engineering judgments behind changes to data representation, compilation, and work distribution across processor cores. These were collaborative Unity technologies; his authored explanations make the choices and their costs accessible.

In his argument for high-performance C#, Lucas challenged the intuition that C++ necessarily offered the best control over hardware. A restricted subset of C# could preserve familiar developer tools while excluding features that complicated optimization, including garbage collection, reflection, and virtual calls. Combined with the team’s Burst compiler, those restrictions created opportunities for predictable machine-code generation. His renderer-culling example made the argument concrete: the Burst version matched the C++ version’s performance with substantially less code devoted to persuading the compiler to vectorize it.

Lucas also wanted developers to inspect and understand the generated instructions. That would let engineers examine the performance consequences of their code rather than discover a regression after an apparently harmless edit.

His explanation of the Entity Component System addressed memory layout. Unity’s familiar component model remained useful: adding a rigid body makes an object participate in physics. The costly part was an implementation that scattered related objects through memory. Grouping component data by the combinations an entity contained let systems process tightly packed arrays instead of repeatedly searching for related objects. Lucas acknowledged the transition’s cost: developers could combine the new systems with the existing engine, but would encounter friction between the architectures.

Small tools for recurring development problems

Lucas’s public projects also address narrower frustrations in everyday programming and agent use:

• Cross-platform filesystem work. NiceIO is a single-file C# library for manipulating files and directories across macOS, Linux, and Windows. Immutable paths, normalized separators, and chainable operations simplify tasks such as creating, copying, and listing files without requiring separate package infrastructure.
• Watching long-running agent commands. pi-bash-live-view adds a live terminal view backed by a pseudo-terminal. It keeps build progress and other terminal displays visible while an agent’s command runs.
• Knowing when an agent finishes. pi-terminal-signals connects Pi’s lifecycle events to existing terminal protocols. Starting work can trigger a progress indicator; finishing can clear it and send a completion notification.

Remote agents and the work of reviewing them

AgentsInTheCloud brings coding agents together with a browser, terminal, and VS Code access, providing a fresh isolated environment for each task. Agents can continue working after the developer closes a laptop, and a mobile interface offers another way to return to the work. The host can be a rented server or a machine the developer already owns. The project supports different model providers and is MIT licensed.

The repository places workflows for evaluating agent work alongside remote execution and provider choice. Lucas’s contribution policy gives a particularly concrete account of how he approaches that evaluation. He welcomes descriptions of users’ problems and proposed improvements, asking that the main explanation come in the contributor’s own voice. He currently declines to merge external pull requests, preferring to have his own agent implement changes. A pull request can still demonstrate a solution that works for a user.

His stated reason is the review burden: he finds unfamiliar contributed code more work to assess than code written by his own agent. The policy keeps implementation within his agent workflow while inviting users to influence the product through problem reports and working examples.