Roman Khramets

One uncomfortable thought that terrifies me lately is that in the day and age of AI-assisted coding the concept of System Design will change again. Hear me out. SysDesign used to be about patterns. When the "bad OOP" [1] era was in full bloom, a "good" "system designer" effectively was the person who can tell you where and how to use a SQL database and how to [not] use the visitor and the observer patterns. Throw in some knowledge of how to separate the read path from the write path, and how to invalidate caches, and one is a decent engineer SysDesign-wise as of ~2015. If the candidate can clearly articulate how strong consistency is different from eventual consistency, and which cloud primitives are best at replacing which self-hosted solutions, they truly are on top of their game. As the "bad OOP" [1] era started its decline, by ~2020, we had a period of renaissance for System Design. People started talking about causality, vector clocks, logical sharding, read-your-own-writes, consistency, message queues vs. message buses, idempotency and fencing tokens. I remember in ~2022 you could base an interview on offering the candidate to explain how they understand the CAP theorem after they brought it up in the context of consistency models. For a well-articulating candidate, asking how the Bitcoin protocol maps to these "C, "A", and "P" letters was almost guaranteed to result in an insightful conversation, with tons of signal to extract from follow-up questions. Now we are entering the post-OOP era, which is great. Rust, for example, specifically makes the claim that we do not need inheritance and what not for the language to be powerful and easy to use. Fantastic. Unfortunately, humankind entering the post-OOP era coincided with, well, Cursor. So we are at this weird spot where on the one hand it still is seemingly important to understand SysDesign fundamentals. On the other hand, an increasing share of code is being written with or by the AI assistant. All in all, using tools to boost productivity is great. On the flip side, AI-assisted coding makes it far too easy for an inexperienced developer to make expensive mistakes reliability- and consistency-wise when it comes to making changes to a complex system with many moving parts. Naturally, on this journey towards conquering complexity, we're back to square one: SysDesign is about making sure the candidate is _less likely_ to use the AI in a way that introduces an expensive-to-debug error. Which, in my book, is even worse than when a SysDesign interview is about "tell me about the pros and cons of the visitor pattern". Because instead of designing systems thoughtfully we're inevitably teaching less senior engineers how to speed-run this game of "shipping something". The end result, predictably, will be far more legacy code that no one dares to touch. Only this time the people who wrote the code did not just leave. They never existed in the first place. It was LLMs all the way down.

27

4 Comments

See how Forward Deployed Engineers have helped close the gap on implementing AI agents leading to a 800% spike in FDE job postings between Jan. and Sep. 2025, according to Indeed and the Financial Times:

3

Hiring engineers for hard operational problems is different. Most candidates can write clean code. Fewer can sit with a dispatcher at 7am and understand why their shift planning breaks down. Fewer still can go back to the codebase and design something that actually works in production with those constraints. What I look for at Mirage Metrics is not just skill with Python, SQL, or distributed systems. It is a willingness to go into environments that are messy, sometimes chaotic, and keep digging until the real bottleneck shows up. That can mean inventory mismatches hidden in Excel, planning rules written on a whiteboard, or API endpoints that return inconsistent data depending on who queries them. The best engineers I have worked with are the ones who do not flinch at this. They treat debugging a customs declaration pipeline with the same seriousness as debugging a memory leak. They know that solving “boring” problems in data quality or workflow mapping is what unlocks everything else. On the technical side, I test for clarity. Can someone explain the trade-offs between running a model via an API versus hosting it on GPUs without getting lost in jargon. Can they design a schema validator that will still make sense six months later when requirements change. Can they write glue code that is robust, not fragile. On the personal side, I look for stamina. These projects are rarely about building a shiny feature in isolation. They require iteration with operators, late-night debugging of OCR failures, and the patience to integrate into legacy systems that were never designed for AI. If you want to work on AI for logistics, manufacturing, or mining, the question is not only whether you can code. It is whether you can hold your ground in the real world, in front of the people whose work depends on your system. That is the bar.

17

5 Comments