As intelligent tools move from experiments into production, they’re also reshaping the people who build it, especially how they think about reliability, accountability, and the boundaries of trust in a system. Aleksandr Nikolenko, a search engineer at Perplexity, made the journey from high-load payment systems at Yandex to the front lines of building AI agents and search infrastructure.
In this interview, he talks about his professional path, which trends in AI engineering are worth watching versus which ones are just noise, and how he sees the role of the software engineer evolving as agents take on more and more of the routine work.
1. How did your career path lead you from traditional software engineering to working on AI agents and search infrastructure at Perplexity?
Aleksandr Nikolenko:
I don’t think of it as leaving traditional engineering behind: the problems changed, but the instincts carried over.
Before Perplexity, I worked on high-load payment systems at Yandex. Payments teach you fast that the happy path is never enough: retries, duplicate requests, and partial failures all need handling, and someone has to be able to understand what broke at 3 a.m. That work makes you suspicious of anything that only looks good in a demo.
AI became interesting to me once it stopped being a side tool and started becoming real product infrastructure. I wanted to work close to that shift, not watch it from outside, in a place where models were strong enough to change workflows but the engineering abstractions were still being invented.
That’s what drew me to Perplexity. Search, agents, and runtime systems occupy a new place: familiar backend discipline, but an unfamiliar shape. It feels less like maintaining a discipline than helping define one, which is what makes AI and search a new engineering frontier, not just a continuation of the old one.
2. What skills from your earlier engineering roles turned out to be most valuable when you started working with AI systems?
Aleksandr Nikolenko:
The most useful habit was distrusting anything that only worked under friendly conditions. In backend systems, code is one part of the problem: you’re constantly asking what happens if a call runs twice, if a service is slow, or if whoever debugs this later has less context than you do.
That translated directly to AI systems. A model can produce an impressive answer, but the real question is whether the product can tell if that answer is grounded, whether it can act safely, and whether another engineer can reconstruct what happened afterwards. Without that, you don’t have a reliable system: you have a capability that works when nothing goes wrong.
Incident discipline mattered too. When something breaks, the goal isn’t to look clever or patch it fast; it’s to narrow the unknowns, pick a mitigation that doesn’t start a second fire, and make the failure easier to catch next time.
AI raises the stakes in that discipline because its failures are often quiet: a plausible-sounding answer, the wrong tool path, a missing piece of context. The instincts are the same. They just show up in new places.
3. AI engineering is changing very quickly. Which trends do you believe are important, and which ones are mostly hype?
Aleksandr Nikolenko:
The shift I pay most attention to is moving from prompting a model to designing the loop around it: the right context, the right tools, a way to check progress, and a clear point where the system should stop and ask for help. The model is one part of that loop, not the whole thing.
I also think model selection is becoming an engineering decision rather than a brand decision. The best model on a leaderboard isn’t automatically the best fit for your product: one task cares about latency, another about long-context reasoning, another about cost or predictability. Learning those tradeoffs, and choosing deliberately, is the actual skill.
The hype, for me, is treating a polished demo as proof of a product. A demo shows a model is capable of something; it doesn’t show the workflow is debuggable, affordable, or trustworthy enough to run every day.
So I separate capability from leverage. A new capability is exciting, but what matters is what it lets people stop doing manually: a repetitive step removed, an investigation shortened, a workflow made cheap enough to run often. An impressive one-off result isn’t the same thing.
4. Do you think the next major breakthrough in AI will come from better models or from better infrastructure around them?
Aleksandr Nikolenko:
I wouldn’t separate the two too cleanly, but if I had to put it simply: models are the ceiling, infrastructure is the floor.
A stronger model makes whole classes of tasks realistic: longer reasoning chains, more reliable tool use, more delegation than before. That’s real progress, worth staying close to. But whether those possibilities turn into dependable work depends on what’s built around the model: does it know what state it’s allowed to touch, are permissions clear, can we see what it tried and where it got stuck, and can we recover cleanly if it makes a bad step?
That’s where I expect much of the next breakthrough to happen, not in wrapping a model in a nicer UI, but in building environments where models can act, check themselves, and leave a trail that engineers can actually trust. The model gives you capability. The infrastructure is what lets a team rely on it.
5. How is the role of a software engineer changing as AI agents become capable of writing code, running tools, and completing longer tasks?
Aleksandr Nikolenko:
The scarce skill is shifting from “can you produce code” to “can you make the right decisions around it.” Writing still matters: you need taste, debugging ability, and enough depth to catch a model that’s confidently wrong. But once an agent can generate a decent first version in minutes, the engineer’s leverage moves to framing the problem well.
That means being precise about intent, constraints, and what “done” actually means. A vague task given to an agent usually produces vague software; a good engineer turns an ambiguous request into clear boundaries, test cases, and a rollout plan.
Review changes too. A diff isn’t enough on its own: I want to know what context the agent used, what it assumed, and how easy it is to roll back if it’s wrong.
So I don’t think engineers become less important. The job becomes more about delegation with ownership: you can hand off the mechanical work, but not the judgment.
6. What advice would you give to engineers who want to move into AI infrastructure or agentic systems today?
Aleksandr Nikolenko:
I’d be careful giving “timeless” advice here: the field moves too fast for that, and my answer might look different in a few months. What I’d say right now: build a real agent loop around a workflow you already understand, and study where it breaks.
I started with monitoring and RCA, because it looks simple from the outside (an alert fires, find out why) but is messy in practice. A useful agent has to pull together the right signals, form a hypothesis, check it, and notice when the evidence doesn’t fit.
The first version won’t work well, and that’s fine. What matters is debugging why: missing context, a tool that’s too narrow, an environment that’s awkward to work in. That boundary, between a fixable engineering gap and an actual model limitation, is where most of the learning happens right now.
So, pick a workflow you have taste in, build the loop, and make it observe, act, verify, and improve. Better models raise the ceiling. Engineers raise the floor by giving agents the context and feedback they need to be dependable.
