Interview with Roman Martynenko, Full-Stack Software Engineer and Founding Engineer

As a full-stack software engineer and founding engineer, how would you describe the problems you focus on solving and the perspective you bring to building AI-enabled products?

Our customers were generating decks for their deals mostly by hand. They had tons of spreadsheets and other documents in different formats, with no clear source of truth. They dealt with that chaos every time they needed a deck and spent a lot of time going back and forth over the information.

They also hired whole teams of analysts and designers to sort through those documents and produce the decks. I built an AI-powered deck generation engine that structured the data and then used it to generate high-quality decks. I also worked on map generation and the front end around it.

That’s the kind of problem I focus on: a task that takes people a lot of time because the information is messy and the process is manual. My full-stack background lets me work on both the generation engine and the interface customers use. In this project, I needed to address the data behind the deck as well as the deck itself.

What path led you to become a founding engineer working at the intersection of full-stack development, automation and AI-powered business workflows?

My journey started as a front-end engineer at PVD-Technology, my first position in the information technology (IT) field. Frameworks like React weren’t really popular back then, so my main stack was Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and vanilla JavaScript. Having that narrow focus allowed me to build solid front end expertise, which served as a foundation for my future career.

In my next position, as a full-stack developer at DecisionMapper, I started extending my skill set with backend technologies. I was fascinated by how the whole thing worked end to end. It helped me deepen my expertise and connect the dots in my understanding of building complex applications with heavy data processing and traffic.

My journey in the startup world began at Zocdoc. During that period, I started paying more attention to the business impact of the software I was building, as well as the importance of domain expertise and working with stakeholders. Later, I joined the founding team at Henry AI, where we built AI-driven solutions for commercial real estate. My work included a deck generation engine that helped customers structure their data and automate work they had previously done manually.

When you move from an AI demo to a real product feature, what is the first real user workflow you examine to determine whether AI can genuinely improve it?

Usually, I start with manual tasks where users spend most of their time and cognitive effort tediously going through documents, entering information, comparing it and reconciling differences. These are tasks where I see AI agents helping more and more.

What interests me is that models can do more than parse documents in various formats and consolidate the information. They can also reason about that information, detect possible inconsistencies and anomalies, suggest changes and, with the right permissions, make changes themselves.

Another task that takes a lot of effort for knowledge workers is research. It might mean searching through documents, doing online research or combining both. With Model Context Protocol (MCP) connectors and plugins, models can retrieve more context from third-party services as they work. Instead of following the whole thread of a complex, multi-hour search, the user can review the end result, its citations, and the sources and actions behind it.

From your experience building workflow-level AI systems, how do you narrow a promising but broad AI idea into a first use case with clear business value?

The first and most important thing is to make sure there is a shared understanding of user needs. That involves user research and a lot of communication with the end user. When I talk to customers, I do not try to sell them my product immediately or ask for their opinion about my idea. Usually, people in that situation compliment your intentions to make you feel good. Instead, I ask questions that help me explore their past experiences with their workflows and the main pain points they had to deal with.

It is also critical to verify whether the problem they are talking about is really a problem. Sometimes people get emotional about things that irritate them once in a while, but it turns out they already have a low-effort workaround that works well enough. Such problems may become worth solving at some point, but at the moment, they are unlikely to bring much business value.

When a real customer problem with the highest potential for business value is identified, it is time to scope the first release. It should cover the core user needs in a specific area, but stay narrow enough to be delivered quickly and improved through further iterations.

What design choices have helped you make AI outputs dependable enough for professionals to use in their day-to-day work rather than treat as a novelty?

Product design is crucial to turning an idea into a useful product, alongside the technical implementation. A lot depends on user research: understanding people’s current workflows, needs and habits. Beyond following interface design best practices, we need to know how technical our users are, how comfortable they are with new technology and how willing they are to change established ways of working.

For example, in the deck editor I built at Henry AI, tables were among the most-used components. They could contain financial data, comparison analyses or breakdowns of metrics. We initially introduced a new way to edit them, but our users found it difficult. So we developed an interface that followed familiar Excel mechanics. Our users already spent a lot of time in Excel, and that familiarity made them much more comfortable making the final corrections to presentations generated by the agentic workflow.

Another part of making AI dependable is showing users where the output came from. In my experience, citations make a big difference. Users can check where a particular number came from or where an image was sourced. If the model takes a number from a profit-and-loss (P&L) statement for the wrong period, that is still a mistake, but the source makes it easier to understand and correct. Without it, the user has no straightforward way to tell whether the number came from the wrong document or was invented by the model.

How do you decide where an AI system can act autonomously and where a human checkpoint is essential in a business workflow?

There are two sides to the decision. On one side, it is the user’s call whether they are comfortable with AI developing, improving and executing a decision for them. Usually, if the cost of a mistake is not very high or critical to the business, and users trust the system, they are more willing to delegate the whole process. Otherwise, they are more cautious and want to keep the final approval.

On the other side, the product itself has to be reliable and traceable. What I find critical in AI-driven systems is evals. These are basically tests for an AI system: We provide use cases and check whether the output meets predefined quality criteria. The results help us understand which tasks the system can handle reliably and where human review is still needed.

This testing system is not static. As the product evolves and we discover new use cases or mistakes, we include them in the tests. That way, our understanding of the system’s reliability develops along with the product, and we have a basis for deciding whether to give it more autonomy.

As a full-stack engineer, how have you built reliability, observability and fallback behavior into AI-powered workflows when model outputs or connected systems fail?

Generally, the techniques developed over decades of classic software engineering still apply to AI-powered systems. We need systems that can scale up and down with the load and have enough redundancy to keep operating if an underlying service fails. For observability, I want to trace a user action from input to output or failure. In an AI workflow, that includes the model’s inputs and outputs, calls to connected services, intermediate artifacts, errors, token usage and the cost of a particular run. These records help us understand where something went wrong, even when the workflow involves several systems.

Another useful technique is deploying agents that observe the system while it runs in production. For example, an agent can monitor an internal assistant’s conversations with users and flag possible anomalies or signs of frustration. It can alert a human while the conversation is still happening, giving them a chance to step in. Those signals can also feed into further improvements, including automatically creating evaluation cases from problematic conversations. I would test any resulting changes before applying them to the live system.

For founding teams looking to turn AI experimentation into a dependable product, what is one practical habit you would establish early to keep development grounded in customer value?

If I had to highlight the most valuable practical habit for keeping development grounded in customer value, it would be continuous user research. As I mentioned earlier, it is critical to understand the user’s problem, their past experiences, their pain points and how they try to resolve those pain points. With that understanding, we can dig into the real user problem and then come up with a solution using our ideas and our product.

However, initial research is not enough. It should be a continuous habit. We keep talking to our customers as we solve certain problems for them, but other problems emerge as their workflows evolve with our product and the other tools they use daily. It is still important to avoid simply asking for feedback on our product or idea and instead focus on their past experiences.

Another point is the importance of building trust. It has always been critical to build trust with your customers, but in the AI era, it is becoming increasingly important and difficult as more and more products are driven by large language models (LLMs) with unpredictable outputs that are hard to control. In that situation, we have to be transparent about the capabilities and limitations of the system we build for our users so they do not encounter unexpected results or face risks they are unaware of.

Disclosure: I previously worked at Henry AI as a Founding Engineer, where I helped develop the AI-powered tools discussed in this interview

This article was first published on Featured News.