H
HackerNoon Writers Spotlight
Guest
So let’s start! Tell us a bit about yourself. For example, name, profession, and personal interests.
I’m Sai Gowtham Reddi Seethi, a software engineering and AI practitioner with more than 14 years of experience building large-scale distributed systems, search platforms, APIs, and cloud-native applications. Much of my recent work and research has focused on agentic AI, enterprise search, retrieval systems, and using AI agents to improve the software development lifecycle.
I’m particularly interested in taking AI beyond demos and exploring how autonomous agents can work reliably with deterministic systems, enterprise data, testing platforms, and human oversight. I enjoy experimenting with these ideas through independent research and hands-on projects, and then writing about what I learn.
Outside of my professional work, I enjoy building technology projects, researching financial markets, writing about emerging AI architectures, and continuously learning about new developments in AI and software engineering.
Interesting! What was your latest Hackernoon Top story about?
My latest HackerNoon Top Story explored a problem I’ve become increasingly interested in: security in the age of autonomous AI agents.
As AI systems evolve from simply generating responses to actually using tools, accessing data, calling APIs, and executing actions, prompt injection becomes much more than a chatbot problem. An untrusted webpage, document, or external data source can potentially contain instructions that influence an agent’s behavior.
The article looks at why traditional security assumptions don’t always translate cleanly to agentic systems and argues for stronger separation between trusted instructions, untrusted content, and executable actions. I also discuss practical safeguards such as least-privilege tool access, trust boundaries, deterministic controls, and human oversight.
What interests me most about this topic is that we’re effectively giving AI systems more agency while still figuring out the security architecture needed to control that agency safely. I think that will become an increasingly important engineering challenge as agentic AI moves into real enterprise systems.
Do you usually write on similar topics? If not, what do you usually write about?
Yes, there’s definitely a common thread in what I write about. Most of my work focuses on practical applications of AI and agentic systems in real-world software engineering.
I write about topics such as agentic AI architectures, enterprise search and retrieval, intelligent routing between AI agents and deterministic systems, AI-assisted software development and testing, and the security and governance challenges that emerge as agents gain more autonomy.
A lot of these ideas come from problems I’ve encountered or explored as an engineer. I’m especially interested in the gap between an AI prototype that looks impressive and a system that can actually operate reliably at enterprise scale.
I also enjoy experimenting outside my day-to-day engineering work, including applying machine learning and multi-agent approaches to areas such as financial-market research. Ultimately, I try to write about what happens when AI leaves the demo environment and has to work with real data, real systems, and real engineering constraints.
Great! What is your usual writing routine like (if you have one?)
I wouldn’t say I have a strict writing routine. Most of my articles actually start with a technical problem or an idea that I encounter while building or experimenting with something.
I usually begin by taking notes, testing the idea, and asking myself whether there’s a broader engineering lesson behind it. Once I have enough practical context, I start writing around the problem: what made it interesting, what approaches worked or didn’t work, and what other engineers might take away from it.
I also spend quite a bit of time researching and validating the technical details before publishing. I prefer writing from hands-on experience rather than simply commenting on the latest trend. So my writing process is really an extension of how I work as an engineer: build something, question it, research it, refine it, and then share what I learned.
Being a writer in tech can be a challenge. It’s not often our main role, but an addition to another one. What is the biggest challenge you have when it comes to writing?
The biggest challenge for me is turning something highly technical into a story that people actually want to read.
As an engineer, my natural instinct is to explain everything: the architecture, edge cases, tradeoffs, implementation details, and all the reasons behind a decision. But good technical writing requires a different kind of discipline. You have to decide what really matters and explain it without losing the technical depth that makes the article valuable.
Finding time is another challenge. Writing isn’t my primary job, so most of it happens around my engineering work and personal projects. Interestingly, that also gives me most of my ideas. I’m usually writing about something I’ve built, researched, questioned, or struggled with myself.
For me, the challenge is finding that balance: keeping an article technically credible while making it accessible and interesting enough that someone outside the immediate problem space can still take something useful from it.
What is the next thing you hope to achieve in your career?
The next thing I hope to achieve is to be in a position where I can guide and mentor engineers on how software development is changing, particularly with Spec-Driven Development (SDD) and AI-assisted engineering.
I’ve spent much of my career building systems and solving engineering problems myself. What excites me now is the opportunity to help other engineers become more effective. I believe SDD can fundamentally change the way teams work by making requirements clearer and allowing AI agents to participate across development, testing, validation, and documentation.
For me, though, it’s not just about developing software faster. The real value is showing engineers how that speed can translate into business impact—shorter feedback cycles, faster experimentation, better quality, and ultimately getting useful capabilities into customers’ hands sooner.
I’d like the next stage of my career to be about helping teams adopt these approaches responsibly and creating an environment where the next generation of engineers can build things that would have taken us months in a fraction of that time.
Wow, that’s admirable. Now, something more casual: What is your guilty pleasure of choice?
Probably starting new side projects when I already have enough things to work on!
I’ll come across a new AI tool, an interesting idea, or a problem I think I can automate, and suddenly I’m building something at midnight just to see if it works. What starts as “I’ll try this for an hour” can very quickly turn into a whole new project.
And when I’m not doing that, my other guilty pleasure is probably spending far too much time scrolling through my phone—something I’m still trying to get better at!
Do you have a non-tech-related hobby? If yes, what is it?
Yes! I really enjoy DIY projects and building things around the house. There’s something very satisfying about starting with an idea, figuring things out as I go, and eventually seeing something physical that I built with my own hands.
It’s also a nice change from software. After spending so much time working with code and systems, working with wood, tools, and real materials gives me a completely different kind of challenge. Of course, I somehow still manage to turn even a simple DIY project into an engineering problem!
What can the Hacker Noon community expect to read from you next?
Going forward, I want to spend more time writing for people who are trying to turn an idea into a real product, especially early-stage founders and engineers.
One area I’m particularly interested in is how startups can use AI, open-source technologies, and modern development approaches to build and validate ideas without taking on significant infrastructure or engineering costs too early.
I’d like to explore practical startup ideas, but also go a step further: how could someone actually build the first version, what can be automated, where can AI agents help, and what should they avoid spending money on until the idea is validated?
If something I write helps a founder or engineer take an idea they thought was too expensive to build and turn it into a working prototype, I think that would be incredibly rewarding.
What’s your opinion on HackerNoon as a platform for writers?
What I like most about HackerNoon is that it gives people who are actually building and experimenting with technology a place to share what they’re learning.
You don’t necessarily have to be a full-time writer or academic researcher to contribute something valuable. Engineers, founders, and practitioners can take an idea from their own experience, write about what worked, what didn’t, and what they learned, and put it in front of a much broader technology community.
I’ve also enjoyed the interaction that happens after publishing. Sometimes a reader’s comment makes you look at your own idea from a completely different perspective, and that discussion can be just as valuable as writing the article itself.
For someone like me who is primarily an engineer and became a writer because I wanted to share what I was learning, HackerNoon feels like a very natural platform.
Thanks for taking time to join our “Meet the writer” series. It was a pleasure. Do you have any closing words?
Thank you for having me. I’ve really enjoyed being part of the HackerNoon community and having a place where I can turn the things I’m learning, building, and sometimes struggling with into conversations with other people in technology.
One thing I’ve learned throughout my career is that you never really reach a point where you’re done learning. Technology keeps changing, and right now AI is changing the way we build software faster than anything I’ve experienced before. I find that incredibly exciting.
My goal is to keep experimenting, keep writing, and most importantly, share things that someone else can actually use. If one of my articles helps an engineer approach a problem differently, or gives someone the confidence to take an idea and start building it, then writing it was worth the time.
And I’m always happy to learn from the people reading my work too, so keep the comments, questions, and disagreements coming!