Teaching software to think was always in the books for Anri, who began building software at 12, when he created a personal platform where he could upload and read books. The project was small and entirely his own, but the instinct behind it has stayed with him: when he encounters a problem, he wants to understand whether technology can make it work better.
Today, as a Software Engineer specializing in AI and cloud technologies at Bytex, he builds APIs, connects and orchestrates generative models, and designs the infrastructure required to deploy them at scale. Outside his day-to-day work, he continues experimenting with products of his own, including an AI-powered learning platform built to create personalized courses around almost any subject.
We spoke with Anri about the difference between generating code and designing a product, why system architecture is becoming more valuable, and what may happen as AI moves from software into the physical world.
This interview is part of The Art of Solving, a series about the people behind Bytex and the experiences, instincts, and principles that shape how they approach difficult problems.
Tell us about your role. What are you currently working on?
I work as a Software Engineer, primarily on generative AI and cloud infrastructure. My role involves creating APIs, connecting and orchestrating different models, deploying them, and making sure the resulting systems can scale.
Before this project, I worked on other machine learning products and built an AI learning platform of my own. The idea came from noticing that most learning applications focus on one subject: a language, mathematics, or another predefined area. I wanted to create something that could help people learn almost anything they chose.
The user enters a goal, and the platform creates a personalized learning plan that might run for 10 or 20 days, with lessons taking approximately three minutes each. The curriculum adapts to the person’s existing knowledge so that it does not simply repeat the same material for everyone. I built the backend, mobile application, architecture, and deployment myself. It began as a side project intended to create something useful, and it reached around 100 users within a couple of weeks.
You seem to become absorbed in an idea until you have worked out how to build it. Have you always been like that?
Yes. When I have an idea, I tend to keep returning to it until I find a way to make it work. Sometimes the technology is not ready when the idea first occurs to me, but I do not necessarily abandon it.
A few years ago, for example, I wanted to generate original music for myself in the style and voice of artists I liked. I could not build it at the time. When the necessary tools became available, I returned to the idea and created a personal version. That is typical of how I work: I may carry an idea for years, watch the technology develop, and build it once the missing capability appears.
How do you decide which ideas are worth pursuing?
I look at the value they could create for me or for other people. At work, the priority is clear: I want to deliver well and, when possible, earlier than expected. With side projects, the decision is more intuitive. I usually start with the idea that feels most useful or interesting at that moment.
Spending too much time choosing can become its own form of delay. If you debate several ideas for weeks, you may remain in the same place. If you choose one and begin, you can have an initial version within a few days and learn from something concrete.
Was there a moment when you realized building things was what you wanted to spend your career doing?
I would make a distinction between building something and building something that can grow and create value. The first version is only the beginning. What interests me is taking an idea further, scaling it, and seeing whether it becomes useful to people.
I do not remember one decisive moment when I chose that path. If I see that something needs to be done in a particular way, my instinct is to begin working out how to do it. The career grew from that.
When you encounter a new technology, what is the first question you ask?
Why do I need it? New applications, devices, and features are released every day. Some may be valuable to many people without being relevant to my work. I want to know whether that technology will help me learn something, save time, or create something I could not build before.
That question keeps me focused on utility. I do not need to adopt every new design tool, for example, if the tools already in my workflow allow me to produce what I need. Curiosity makes me examine what has changed, but usefulness determines whether I integrate it.
You think about technology through engineering, product, and business at the same time. Did that come naturally to you?
I think it did. I have always been interested in all three.
I started building applications when I was about 12. I was reading many books at the time, so I created a website using HTML, CSS, and JavaScript where I could upload them and read them more easily. It ran locally and was intended only for me, but I enjoyed both identifying the need and creating the product that answered it.
That early experience probably shaped how I still think. The technical implementation matters, but so do the person using it, the reason it exists, and whether it delivers enough value to keep developing.
AI has moved from generating content toward performing tasks. Where do you think technology is heading?
The first widely used systems were mostly chat interfaces that generated text. They then became multimodal, accepting and producing images, audio, and video. The current stage is agentic: systems can execute tasks, use tools, run commands, and coordinate parts of a workflow. Some can already build software or support marketing and operational work.
The next major direction will be physical AI. The same capabilities will increasingly appear in robots and devices that work in restaurants, offices, industrial environments, and eventually homes.
This progression also changes the risk. A system that generates a weak answer is one problem. A system with access to tools, the internet, a software environment, or physical machinery can cause much greater damage. Model companies are competing to release more capable systems, and I am concerned that security and control do not always advance at the same speed.
Where should we draw the line between what AI can decide autonomously and what requires a human?
Any decision that can materially affect a person’s life should remain with a human. Medicine is a clear example. AI can analyze information, identify patterns, and provide guidance, but a qualified person should lead the process and remain responsible for the decision.
The same principle applies outside obviously critical sectors. A decision may not threaten someone’s health or safety, but it can still determine what a product becomes. If teams allow AI to choose the features, design, architecture, and direction, they gradually surrender the judgment that gives the product its purpose.
What does responsible use of AI look like when you are building a product?
The person building it should define the system before asking AI to implement it. When I worked on my learning platform, I described the data model, the users and their skills, the API endpoints, the microservices they should trigger, the models each service should call, the prompts, the response flow, and the cloud services where everything would run.
AI could then help write the code, but I reviewed what it produced line by line. I needed to understand why it had made each choice and whether the implementation still matched the architecture I had designed. After that came testing and verification.
I would not give a system a broad instruction to build an entire product and accept whatever it returned. AI is very good at implementation when the direction is specific. It is much weaker at deciding why the product should exist, which compromises are appropriate, and where it should go next.
Do you think every product will eventually become AI-native?
Many products will add AI without changing their foundations. Search is a good example. Generative systems have changed how some people look for information, so established search products have added AI-generated summaries. The underlying product remains a search engine, but AI improves one part of the experience.
That approach will be enough for many consumer products. People do not need every platform they use to be rebuilt around AI. If they visit a service mainly to browse, communicate, or watch content, a fundamental redesign may add very little.
Products built for specific professional workflows are more likely to become AI-native. Software engineering tools, for example, may increasingly organize the entire workflow around collaboration between the engineer and AI. The deciding factor is whether AI changes the core work being performed, rather than whether the company can add an assistant to the interface.
What separates companies that are rethinking their products from those adding AI because the market expects it?
The difference becomes clear in the customer experience. Many companies have launched AI assistants because other companies have them, even when the assistant does not solve the user’s problem.
I experienced this when I needed help with an online order. The automated assistant kept repeating the same response and gave me no route to a person who could resolve the issue. I eventually selected an unrelated support category simply to reach a human operator, then explained the real problem. In that case, AI had added friction to a process that previously worked better.
A useful AI feature begins with a specific problem and improves the route to a solution. If the customer has to work around the AI to complete the task, the company has automated the interface without improving the product.
How has AI changed the way you build software compared with five years ago?
Five years ago, I wrote every character of the code myself. Today, much of the implementation can be generated. If an engineer provides a clear design and the right constraints, a coding model can follow established patterns, produce functional code, and improve it through review.
That makes system design and architecture more valuable. Writing code from a specification is becoming easier to automate. Understanding what should be built, how the components should interact, how the system behaves in a real environment, and which compromises fit the product remains much harder.
AI sometimes challenges my architectural choices, but it evaluates them primarily as code. It may recommend a more robust design without understanding that I am building a demonstration that must be ready tomorrow. For an MVP, a good solution delivered in one day can be more valuable than a theoretically stronger one delivered after the opportunity has passed. The right architecture depends on the product’s stage and purpose.
Will AI remove technology jobs, or will people use it to create more value?
Both will happen. Some jobs will disappear, others will emerge, and most technical roles will change substantially.
AI currently makes experienced engineers faster, much as calculators made certain kinds of work faster without eliminating the expertise behind them. At the same time, fewer junior engineering roles appear to be available, which makes it harder for graduates to enter the field. As the technology develops and becomes more physical, its effect will extend beyond software.
The skills companies hire for will change as well. An interview focused on writing an algorithm from memory may become far less relevant. Companies will place more value on people who understand systems, can work effectively with specialized AI tools, and know how to evaluate what those tools produce. A designer who can direct AI without giving up design judgment, or an engineer who can control implementation through a strong architecture, can create far more than before.
What does that mean for how future engineers should be educated?
System design should be taught earlier. Today, someone who understands architecture still needs coding ability to build a working product. Within a few years, it may be possible to build credible systems with much less direct coding, provided the person understands how the system should work.
That does not make technical knowledge irrelevant. Someone still has to recognize when the generated implementation is weak, unsafe, or inconsistent with the design. But education will need to move from treating code production as the central skill toward teaching architecture, patterns, evaluation, and the ability to direct increasingly capable tools.
You have worked on AI-powered search, speech recognition, and large-scale systems. Which project most influenced how you think about software?
There is no single project. What changed my thinking was seeing how differently software should be built depending on its context.
A prototype intended to demonstrate an idea to a client has to move quickly. A growing startup needs to balance speed with a foundation that can support more users. A feature inside a mature product requires much more care because people already depend on the existing experience.
When a product has no users, you can rebuild its architecture or change its direction. Once many people have adapted to it, sweeping changes carry a much higher cost. Progress has to be gradual and informed by how the product is already used. The strongest technical solution is the one that fits the situation, rather than the one that appears most sophisticated in isolation.
If you could spend the next five years solving one problem in AI, what would it be?
Hallucinations. If you ask a model to produce a 300-page book, it can generate enough language to fill those pages without ensuring that the ideas remain correct, meaningful, or consistent from one section to the next. The system is optimized to continue producing an answer, even when the information is weak.
Part of the problem comes from training data. The internet contains accurate information, inaccurate information, and a growing volume of AI-generated material. It is impossible to annotate and validate all of it manually.
There is also an architectural limitation. Large language models use transformer-based systems to predict tokens. The technology has become remarkably capable, but hallucination remains part of how these models operate. I do not expect the problem to disappear completely while the industry continues building on the same underlying approach. Solving it may require substantial experimentation and a new architecture designed to prioritize correct information rather than plausible continuation.
What is one prediction you hope proves correct five years from now?
I think physical AI will have reached people’s homes. Someone reading this interview five years from now may already have a robot helping with ordinary tasks.
That is the direction I keep returning to: watching new technologies emerge, understanding what has changed, and trying to see where the world is moving before the next capability becomes ordinary.
