You’ve written extensively about agentic AI and frameworks like smolagents and LangGraph. What excites you most about this emerging space?
I first began exploring generative AI largely out of curiosity and, admittedly, a little bit of FOMO. Everyone around me gave the impression to be using LLMs or a minimum of talking about them. So I carved out time to get hands-on, starting with the very basics like prompting techniques and LLM APIs. And the deeper I went, the more excited I became.
What fascinates me essentially the most is how agentic systems are shaping the way in which we live and work. I consider that this influence will only proceed to grow over time. That’s why I exploit every probability to make use of agentic tools like Copilot or Claude Desktop or construct my very own agents using technologies like smolagents, LangGraph or CrewAI.
Probably the most impactful use case of Agentic AI for me has been coding. It’s genuinely impressive how tools like GitHub Copilot can improve the speed and the standard of your work. While recent research from METR has questioned whether the efficiency gains are truly that substantial, I definitely notice a difference in my day-to-day work. It’s especially helpful with repetitive tasks (like pivoting tables in SQL) or when working with unfamiliar technologies (like constructing an online app in TypeScript). Overall, I’d estimate a couple of 20% increase in speed. But this boost isn’t nearly productivity; it’s a paradigm shift that also expands what feels possible. I consider that as agentic tools proceed to evolve, we’ll see a growing efficiency gap between individuals and firms which have learned how one can leverage these technologies and those who haven’t.
On the subject of analytics, I’m especially enthusiastic about automatic reporting agents. Imagine an AI that may pull the fitting data, create visualisations, perform root cause evaluation where needed, note open questions and even create the primary draft of the presentation. That might be just magical. I’ve built a prototype that generates such KPI narratives. And regardless that there’s a major gap between the prototype and a production solution that works reliably, I consider we’ll get there.
You’ve written three articles under the “Practical Computer Simulations for Product Analysts” series. What inspired that series, and the way do you think that simulation can reshape product analytics?
Simulation is a vastly underutilised tool in product analytics. I wrote this series to point out people how powerful and accessible the simulations will be. In my day-to-day work, I keep encountering what-if questions like “” or . You possibly can simulate any system, irrespective of how complex. So, simulations gave me a method to answer those questions quantitatively and fairly accurately, even when hard data wasn’t yet available. So I’m hoping more analysts will start using this approach.
Simulations also shine when working with uncertainty and distributions. Personally, I prefer bootstrap methods to memorising a protracted list of statistical formulas and significance criteria. Simulating the method often feels more intuitive, and it’s less error-prone in practice.
Finally, I find it fascinating how technologies have modified the way in which we do things. With today’s computing power, where any laptop can run hundreds of simulations in minutes and even seconds, we are able to easily solve problems that may have been difficult just thirty years ago. That’s a game-changer for analysts.
Several of your posts give attention to transitioning LLM applications from prototype to production. What common pitfalls do you see teams make during that phase?
Through practice, I’ve discovered there’s a major gap between LLM prototypes and production solutions that many teams underestimate. Probably the most common pitfall is treating prototypes as in the event that they’re already production-ready.
The prototype phase will be deceptively smooth. You possibly can construct something functional in an hour or two, test it on a handful of examples, and feel such as you’ve cracked the issue. Prototypes are great tools to prove feasibility and get your team excited concerning the opportunities. But here’s where teams often stumble: these early versions provide no guarantees around consistency, quality, or safety when facing diverse, real-world scenarios.
What I’ve learned is that successful production deployment starts with rigorous evaluation. Before scaling anything, you would like clear definitions of what “good performance” looks like by way of accuracy, tone of voice, speed and another criteria specific to your use case. Then it is advisable to track these metrics constantly as you iterate, ensuring you’re actually improving quite than simply changing things.
Consider it like software testing: you wouldn’t ship code without proper testing, and LLM applications require the identical systematic approach. This becomes especially crucial in regulated environments like fintech or healthcare, where it is advisable to exhibit reliability not only to your internal team but to compliance stakeholders as well.
In these regulated spaces, you’ll need comprehensive monitoring, human-in-the-loop review processes, and audit trails that may withstand scrutiny. The infrastructure required to support all of this often takes much more development time than constructing the unique MVP. That’s something that consistently surprises teams who focus totally on the core functionality.
Your articles sometimes mix engineering principles with data science/analytics best practices, akin to your “Top 10 engineering lessons every data analyst should know.” Do you think that the road between data and engineering is blurring?
The role of a knowledge analyst or a knowledge scientist today often requires a mixture of skills from multiple disciplines.
- We write code, so we share common ground with software engineers.
- We help product teams think through strategy and make decisions, so product management skills are useful.
- We draw on statistics and data science to construct rigorous and comprehensive analyses.
- And to make our narratives compelling and truly influence decisions, we want to master the art of communication and visualisation.
Personally, I used to be lucky to achieve diverse programming skills early on, back at college and university. This background helped me tremendously in analytics: it increased my efficiency, helped me collaborate higher with engineers and taught me how one can construct scalable and reliable solutions.
I strongly encourage analysts to adopt software engineering best practices. Things like version control systems, testing and code review help analytical teams to develop more reliable processes and deliver higher-quality results. I don’t think the road between data and engineering is disappearing entirely, but I do consider that analysts who embrace an engineering mindset will probably be far simpler in modern data teams.
You’ve explored each causal inference and cutting-edge LLM tuning techniques. Do you see these as a part of a shared toolkit or separate mindsets?
That’s actually an excellent query. I’m a powerful believer that every one these tools (from statistical methods to modern ML techniques) belong in a single toolkit. As Robert Heinlein famously said, “Specialisation is for insects.”
I feel of analysts as data wizards who help their product teams solve their problems using whatever tools fit the very best: whether it’s constructing an LLM-powered classifier for NPS comments, using causal inference to make strategic decisions, or constructing an online app to automate workflows.
Fairly than specialising in specific skills, I prefer to give attention to the issue we’re solving and keep the toolset as broad as possible. This mindset not only leads to raised outcomes but in addition fosters a continuous learning culture, which is crucial in today’s fast-moving data industry.
You’ve covered a broad range of topics, from text embeddings and visualizations to simulation and multi AI agent. What writing habit or tenet helps you retain your work so cohesive and approachable?
I often write about topics that excite me in the meanwhile, either because I’ve just learned something latest or had an interesting discussion with colleagues. My inspiration often comes from online courses, books or my day-to-day tasks.
After I write, I all the time take into consideration my audience and the way this piece will be genuinely helpful each for others and for my future self. I try to clarify all of the concepts clearly and leave breadcrumbs for anyone who desires to dig deeper. Over time, my blog has turn into a private knowledge base. I often return to old posts: sometimes just to repeat a code snippet, sometimes to share a resource with a colleague who’s working on something similar.
As everyone knows, all the pieces in data is interconnected. Solving a real-world problem often requires a mixture of tools and approaches. For instance, in the event you’re estimating the impact of launching in a brand new market, you would possibly use simulation for scenario evaluation, LLMs to explore customer expectations, and visualisation to present the ultimate advice.
I attempt to reflect these connections in my writing. Technologies evolve by constructing on earlier breakthroughs, and understanding the foundations helps you go deeper. That’s why lots of my posts reference one another, letting readers follow their curiosity and uncover how different pieces fit together.
Your articles are impressively structured, often walking readers from foundational concepts to advanced implementations. What’s your process for outlining a posh piece before you begin writing?
I consider I developed this manner of presenting information in class, as these habits have deep roots. Because the book explains, different cultures vary in how they structure communication. Some are concept-first (ranging from basics and iteratively moving to conclusions), while others are application-first (starting with results and diving deeper as needed). I’ve definitely internalised the concept-first approach.
In practice, lots of my articles are inspired by online courses. While watching a course, I outline the rough structure in parallel so I don’t forget any essential nuances. I also note down anything that’s unclear and mark it for future reading or experimentation.
After the course, I start serious about how one can apply this data to a practical example. I firmly consider you don’t truly understand something until you are attempting it yourself. Despite the fact that a lot of the courses have practical examples, they are sometimes too polished. So, only whenever you apply the identical ideas for your individual use case will you run into edge cases and friction points. For instance, the course might use OpenAI models, but I’d need to try an area model, or the default system prompt within the framework doesn’t work for my particular case and desires tweaking.
Once I actually have a working example, I move to writing. I prefer separate drafting from editing. First, I give attention to getting all my ideas and code down without worrying about grammar or tone. Then I shift into editing mode: refining the structure, selecting the fitting visuals, putting together the introduction, and highlighting the important thing takeaways.
Finally, I read the entire thing end-to-end from the start to catch anything I’ve missed. Then I ask my partner to review it. They often bring a fresh perspective and indicate things I didn’t consider, which helps make the article more comprehensive and accessible.
To learn more about Mariya‘s work and stay up-to-date along with her latest articles, follow her here on TDS and on LinkedIn.
