Architecture-first, AI-native: What engineering at ZYGO looks like

Inside the work, the method, and why combined intelligence makes you a better engineer

"AI doesn't have our coffee-machine context."

AI is in every editor, every pull request, every debugging session here. But it's missing the drawings on the whiteboard, the half-finished conversation from yesterday, the four verticals that have to talk to each other for any of this to work.

A software platform for Physical AI Agents doesn't get build by an army of coding agents. We ship code into the real world, where the consequences of bad design might lead to a stranded security robot at 3am. So, at ZYGO, we use combined intelligence to shape the hybrid workforce of the future.

The architecture is still ours

ZYGO ships software across four stacks that have to behave like one system: cloud, embedded Linux, robotics, and navigation. You can't have an LLM hold that in its head.

That's why you need Combined Intelligence. As Arne puts it: "AI only has a horizon of one million tokens. That's a lot, but not enough. The human is very, very good at the overview and the long-term vision." He keeps coming back to the coffee-machine point. "We have our own drawings on the board. We have our own discussions at the coffee machine. AI is missing that context. The human has that context."

What that means in practice: humans own the architecture. Humans hold the long-running, cross-vertical decisions about how a perception stack on a Jetson talks to a route planner that talks to a cloud-side inspection record. AI agents do the code inside those boundaries.

"Humans are still good at building architectures. AI agents do the code. The non-brain tasks. AI is very good at that kind of work."

That split is the spine of the team. Hybrid teams of humans and AI inside engineering. AI-enabled robots and the people who operate them in the field. Combined intelligence at both layers.

What the work feels like now

Across the engineering team, the day-to-day has shifted in the same direction even though the work is wildly different.

Anthony, who runs the backend and wears the CISO hat, uses AI to push back on his own thinking. "I use AI on a day-to-day basis for a wide range of tasks: inspecting my pull requests, intellisense, etc. I also use AI to let it challenge me. Did I forget something? Should I think about something? Trying to get the exceptional cases into the picture."

One example of the kind of work Anthony now offloads: "When someone asks something for a demo, you have to go through some loops. I had to convince myself: why am I still doing this myself? I can just ask the AI. Yo, since you're running in the cloud anyway, connect to the database, fetch me the records for that table, modify them for me. You can pretty much do it in parallel."

Daniyal, a junior robotics engineer, fourteen months in, consults AI before he writes the first line of any new feature. "Before I jump into a new feature, I consult the AI. What are the best practices, what's the best way to go about this problem. As a junior, sometimes I don't see a way. I would think it's pretty straightforward. But when I start making a plan with AI, I see it. Oh, it's thinking about this angle, and that one too."

Mike, who has twenty years of programming experience and runs our open navigation and SLAM work, made the most striking adoption claim. "After 20 years of doing it manually, it's very labor-intensive. I try to use AI now for everything that involves programming. Not only does it take away a lot of the manual labor, it prevents you from shipping stupid bugs. In one go, it can also provide tests of the software. It saves you a lot of brain cycles along the way."

The boilerplate is gone. Good.

Anthony puts the value of the AI shift simply: "It enhances the team's capabilities. They can focus more on what actually matters. It reduces a lot of the boilerplate. We can offload boring tasks to the AI and just inspect the work the AI has done, instead of doing the work."

Daniyal points at the same thing from the other end of the seniority ladder. "Every developer has to create tests and document features. Documentation can take hours, but now I can just use AI: I've created this feature, document it. It speeds up the process a lot."

There's a clean parallel with what we build for a living. ZYGO's robots take on the dull, dangerous, and difficult work humans shouldn't have to do. Inside the codebase, AI is absorbing the dull engineering work for the same reason: so the humans can spend their time on what actually requires a human.

Beware of the confidence trap

"You never know when AI is certain about what it's trying to convince you of. It can keep you in a loop. 'Ah, you're absolutely right. Yes, but you have to do it like this now.' It still doesn't work. 'Ah, you're absolutely right. Oh wait, but now I'm sure. You have to do it like that.' And you're not getting closer to a solution. It's giving you the impression that it knows what it's doing. But in fact, it's not. You can lose hours. Because your brain is always looking for the easiest solution. Thinking for yourself is the hardest solution. That's why you're always tempted to keep consulting AI."

It's something to be wary of according to Mike. Tom describes the same loop from inside an embedded debugging session.

"You can get into a circle and lose a lot of time because you are doing what the AI agent says. Try this, try this, try this. It can keep you busy for an hour. Until you say, let's read the code. Then you can say, hmm, maybe this is the problem. The AI says, oh yeah, of course, you're right. That's why we still need people who have experience in programming to detect such a situation."

Skill atrophy is a risk across every role

The clearest version of the atrophy problem comes from outside engineering. Altin, our in-house designer, describes the pattern in his own work. "I used to feel way better at writing emails, longer texts, compared to now. Now I just do it in a rush and give it to ChatGPT." He notices what it costs him. "When you use AI a lot, sometimes I can't remember what I learned from AI."

The same pattern shows up in engineering. Mike on the cost of switching back into thinking mode: "After doing that for months and months, making the switch, 'okay, now I have to think for myself,' it's really hard. It's like back when you were studying at school. You really have to push yourself to sit behind a desk, open your books, and start concentrating. It really takes energy. It's so tempting to keep going."

Awareness is the key solution. Everyone here can name it when it happens to them. As long as you know the risk and keep doing some of the work by hand, the muscle stays.

The harder case is the junior who hasn't built the muscle in the first place. Tom rightfully points at the following: "If you have the perfect AI and you start and you know nothing about C++, you ask it to write a program. You will not learn C++, because the AI knows it for you. So if there are problems that the AI cannot fix, then who will fix them?"

One partial counter sits in the tooling itself. Seniors don't just review more code now. They encode their standards into a shared file the AI loads on every session. Juniors inherit those rules without having to ask. The bar for "what good looks like" travels through the tooling itself. It doesn't replace learning C++. It does prevent the worst form of atrophy: shipping code you wouldn't write yourself. But in the end, you still have to check and understand the code.

Senior judgment is worth more than ever

"I'm now looking at it from the point of view of a senior developer who has 20 years in the field. You can use that experience to leverage AI to be so much more productive. Because you know what the outcome should be."

It's a point that Mike can't highlight enough. The senior moat isn't coding speed anymore. It's knowing what the result should look like before the AI writes a single line. Mike's caveat on his own work makes the same point. "The stuff I'm working on has an extra layer of complexity. If you generate code via AI, you have to understand every line. It can spit out some code, it can look fine. But the end result can be something completely different than what you want."

Anthony adds a rule we apply on the backend side: never let AI define the domain. "One thing I would never let AI do is modelling our domain. What is an actual robot, what is an inspection, what is a route, what is a user. The domain is ubiquitous across the entire company. If I say an inspection, the sales department should have the same context about what an inspection means, regardless of people's roles."

That's not a small carve-out. The domain model is where the business actually lives. AI gets to write the controllers and the tests around the model. Humans own the nouns.

Mike closes the loop on the architecture side. "The code is already generated from a perspective. It's designed by a human. We as humans still have to decide what design choices to make. That's why programmers will not disappear immediately."

Juniors still have a chance

There's a popular narrative right now: junior developers are in trouble. AI does the coding, so why hire someone who's still learning to do it?

Daniyal, the junior on our team, doesn't dismiss the worry. "A lot of juniors will lose their jobs or have a harder time getting job experience." But he pushes back on the diagnosis. "Too many people still live in the SaaS bubble, where everything is just a dashboard. You can't compare it to deep tech." Once your code has to decide whether a moving figure on a parking lot at 3am is a threat or a contractor, the abstraction stack gets a lot deeper and the consequences of a bad guess get a lot more physical. Coding speed isn't the value. Architecture sense is, and that's still mostly a human skill.

With AI in the loop, seniors could in theory oversee more juniors than before. But the bar for what a junior needs to bring went up, not down. Anthony spelled out what we're checking for. "Does Daniyal understand the business? Does he understand the domain? If something happens, can he follow a logical process? It's not really about the coding. It's about technical thinking and debugging skills."

Juniors need to be capable of doing what a senior like Tom does after every AI-generated patch: Check if it fits the codebase, or if AI hallucinated a pattern that looks plausible but doesn't match anything else we do.

What the first week actually looks like

The clearest tell for whether this approach works is what happens when someone new joins.

Jonas, our frontend developer, had been at ZYGO for three weeks when we talked. "I'm only three weeks into this job, so everything is new. What AI helps me with is learning everything much faster. Now in week three, I already feel more confident in what I see, what I'm doing. It's more at the level of the team."

He noticed the difference in stance from his previous company straight away. "My previous company was more about using AI to create stuff, to design stuff. Here it's like, okay, we believe AI is the way to go. Something that can help us, not replace us. The usage here is much more profound. Much more based upon what we need. Not 'it's the newest tech, we should use it.'"

Onboarding here is less about tutorials and more about architecture calibration. New engineers come in, the AI tools help them read the codebase faster than they could on their own, and the seniors spend their time on the things AI can't explain: why we modeled a route this way, what happens at the embedded layer when the cloud goes silent, where the coffee-machine context lives.

Who we're looking for

AI makes it easier than ever to ship code that looks fine. It makes it harder than ever to hide the fact that you don't know why the code works.

"There were a lot of developers who said they can develop, but they were just looking around on the internet, finding code, copy-pasting. Oh, it worked. But they don't understand. AI exposes the difference between copying code and understanding systems.," Arne says.

The engineers who do well at ZYGO are different. They want to think, not just ship. They use the tools every day. They also know exactly where the tools stop helping and start hurting.

"At ZYGO we are searching for 5, 6, 7 people at this moment," Arne says. "If you don't use AI today, I think we need to have 10 to 15 people today."

Some of the roles we're looking for are an AI Engineer for edge model optimization on Jetson (PyTorch, CUDA, ONNX, TensorRT) and a Robotics Engineer to work across the navigation and perception stack. Both roles are based in Zonnebeke, Belgium. Spontaneous applications welcome if neither title fits but the team does.