Lakshminarayanan “Lak” Vijayaraghavan is an AR/VR systems engineer, inventor, and immersive technology architect whose career has included engineering the “Land on Mars” and “Walk on Mars” simulations at NASA Kennedy Space Center’s Astronaut Training Experience, developing foundational technologies for TikTok Effect House, engineering validation systems for Magic Leap, and creating interactive systems used across widely adopted AR and VR platforms.
Lak’s work spans immersive simulation, creator platforms, enterprise augmented reality, and AI-assisted development tools, bringing together systems architecture, real-time graphics, and human-centered design to solve complex engineering challenges.
In Part 1 of this series, we jumped into the conversation with Lak, including the biggest lessons he’s learned from the above endeavors, and how he approaches systems engineering and platform design today. We pick up the conversation there…
EW: As one of the first two engineers on TikTok’s Effect House, you helped build the platform into one of the world’s largest AR creator ecosystems while also contributing to immersive simulation technologies at NASA Kennedy Space Center. Both environments demand software that performs reliably at scale, albeit in very different ways. How do engineering priorities change when platforms must support such different users, use cases, and operational requirements?
LV: The two environments define reliability very differently. Kennedy Space Center is a location-based experience operating in front of visitors. A failure cannot always be corrected through a remote update, and taking the system offline immediately affects the experience. That places the engineering emphasis on repeatability, controlled behavior, careful testing, and a scope that can be supported consistently. Every visitor should receive the same stable experience.
Effect House operates under almost the opposite conditions. The platform supports a diverse creator community using different computers, mobile devices, network conditions, project complexity, and levels of technical experience. Reliability in that environment does not mean making every situation identical. It means designing the platform to remain dependable despite constantly changing conditions. That requires resilience, graceful handling of partial failures, continuous delivery, strong observability, and analytics that reveal problems across a broad user base.
At NASA, the challenge was ensuring one controlled experience behaved consistently every time. At Effect House, it was ensuring thousands of unpredictable creator workflows remained understandable and recoverable. The operational models are very different, but both require a precise definition of what failure means for the people using the system.
The common engineering principle is to begin with the environment rather than the architecture. Once the operating conditions, user expectations, and consequences of failure are understood, the system design, testing strategy, rollout process, and monitoring model become much clearer. Reliability is not a fixed property. It is a product decision expressed through engineering.
EW: Your article places significant emphasis on validation rather than generation. Why do you believe validation systems will become one of the defining competitive advantages for AI-native creator platforms?
LV: One of the clearest lessons we have learned is that the quality of AI-generated output depends heavily on the quality of the request. That shifts the engineering challenge from simply generating content to consistently producing the right result for a particular user and project.
Validation therefore begins before generation. The system should recognize ambiguity, identify missing information, and help users communicate their intent without turning every interaction into a lengthy prompting exercise. The objective is to reduce the burden on the creator instead of expecting every user to become an expert at prompt engineering.
That is only the first stage of validation. After generation, the platform must still determine whether the output matches the original intent and whether it is structurally correct, performant, visually consistent, and appropriate for the target environment. In an AR workflow, that includes inspecting project state, running automated checks, comparing previews, validating device constraints, and confirming that a generated change has not introduced problems elsewhere in the project.
Although AI models will continue improving across the industry, validation remains closely tied to a platform’s architecture, creator workflows, project structure, and deployment environment. That makes it far more difficult to replicate than generation alone. The platforms that consistently help users express the right intent and verify the results will build a level of trust that model access by itself cannot provide.
EW: You have served as an engineering interviewer, mentor, technical reviewer, and member of the Technical Design Committee for TikTok’s Effect House. What have those leadership responsibilities taught you about maintaining engineering quality as organizations scale?
LV: Engineering quality is rarely created during a final review. By that stage, many of the most important decisions have already been made. Quality is established much earlier through how the problem is framed, how responsibilities are divided, what constraints are visible, and whether the team has enough context to challenge initial assumptions.
Context becomes even more important as organizations grow. Engineers make better decisions when they understand not only what they are building, but why it matters and what outcome the product is intended to achieve. The level of guidance should also reflect experience. Less experienced engineers often benefit from clearly defined problems and regular feedback, while experienced engineers create greater value when they understand the broader product direction and have the autonomy to make architectural decisions.
The strongest technical designs usually come from engineers who understand the product problem well enough to question the proposed solution. They identify edge cases, uncover hidden dependencies, and often discover simpler approaches because they are reasoning from the desired user outcome rather than translating requirements directly into code.
Focus is equally important. As organizations scale, experienced engineers can become spread across too many meetings, reviews, and partially owned initiatives. Strong teams create clear ownership and protect uninterrupted time for deep technical reasoning.
Interviewing, mentoring, and design reviews have reinforced that engineering quality depends less on adding more processes than on improving the decisions those processes enable. Clear context, appropriate autonomy, strong product understanding, and protected focus produce better systems while helping engineers develop stronger judgment over time.
EW: Your work has required close collaboration across desktop engineering, mobile runtime systems, AI, backend services, creator tooling, and product design. What leadership practices have you found most effective for leading complex technical initiatives across multidisciplinary teams?
LV: When a technology such as AI reaches an inflection point, it quickly influences almost every product area. The leadership challenge is not to isolate AI within a small specialist group, but to help existing teams adopt the technology while preserving the product knowledge, platform experience, and operational judgment they have already developed.
When we began developing AI-powered creator systems, we did not expect every engineer to become an expert in models and prompting overnight. Instead, we brought together engineers with AI expertise and others who had spent years working on the editor, runtime, backend services, creator workflows, and production infrastructure. Each group recognized risks and opportunities the other would naturally miss.
AI specialists helped define what the models could do reliably and where their limitations remained. Product and platform engineers understood how those capabilities fit into existing projects, deployment systems, user expectations, and operational constraints. Product, design, quality assurance, analytics, desktop, mobile, and backend teams also needed a shared understanding of the workflow so the user experience remained cohesive rather than becoming a collection of disconnected features.
In practice, AI became most valuable when it amplified the strengths already present across the organization. Engineers spent less time on repetitive implementation and more time solving architectural and product challenges. Designers and product managers could test ideas earlier, reducing the effort required to move concepts into working software.
Leading initiatives like these requires a clear outcome, visible constraints, and well-defined ownership at the boundaries between systems. Multidisciplinary teams succeed when each group understands its responsibilities, the information other teams depend on, and how the complete user journey will be evaluated. The technology matters, but the coordination model ultimately determines whether it becomes a reliable product.
We’ll pause there and pick things up in Part 3 of this series…
Ellen F. Warren
AR Insider Guest Author