For a while, the answer to a disappointing AI feature seemed straightforward: use a better model. That assumption is becoming harder to sustain. Once an AI system moves beyond a demonstration and starts handling real users, real data and real actions, the difficult problems are often elsewhere. They involve security, permissions, evaluation, state, monitoring, cost and governance.
These are the problemsAtul Kumar examines in his technical writing for HackerNoon and DZone. As an AI product architect, he writes from direct experience of building AI systems, but his focus extends beyond individual models to the engineering required to make them reliable in production.
Prompt injection is a good example. Kumar argues that the answer isn't simply to give a model stronger instructions, but to design the surrounding system sothat untrusted input cannot easily become an unsafe action. External content should be treated as untrusted data, while agents should have access only to the tools and permissions their tasks require. Even if a model is manipulated, the architecture limits what it can do.
He develops the same argument in “The Hardest Part of AI Isn't the Model Anymore”, examining evaluation, memory, cost, monitoring and governance. An AI system cannot be considered reliable simply because its responses look convincing. It needs to be tested, observed and controlled. One section heading captures the point: “Vibes Are Not a Test Suite.”
Another recurring idea in Kumar’s writing is that many problems presented as uniquely difficult AI problems are familiar engineering problems in another form. Once an agent starts calling APIs, maintaining state and waiting for external events, it has many of the characteristics of a distributed system. A problem that appears to be an agent “forgetting” something may actually be a state-management issue; a timeout may reflect how the system was designed to handle waiting.
This framing gives engineers an established way to reason about newer AI architectures. Rather than treating every agent failure as a new class of problem, Kumar connects emerging AI systems with disciplines that have already dealt with state, failure, permissions and reliability.
He applies similar reasoning to coding agents, which can now investigate bugs and open pull requests with limited human intervention. In his DZone analysis, Kumar proposes a practical principle for deciding what to delegate: the important question is not simply how large the task is, but how easily its result can be verified. A substantial refactor in familiar code may be easier to delegate safely than a small change in a payment flow. The developer's role consequently shifts towards framing problems, reviewing results and making the final decision.
His writing on AI workers and agentic enterprises extends this thinking to organisations. Once AI can perform work rather than simply provide information, questions of ownership become technical as well as organisational. Who approves a new capability? Who controls its permissions? Who is responsible when an agent takes the wrong action?
His work has also received recognition beyond the immediate engineering audience. HackerNoon selected Kumar’s essay on agentic enterprises for its daily newsletter of homepage stories, and it subsequently appeared in its trending digests. Several of his essays have also been adapted into audio episodes of HackerNoon's Machine Learning Tech Brief.
Across Kumar’s work, the focus remains on the engineering decisions that determine whether AI capability can be used safely and reliably. His writing applies established principles such as least privilege, testing, observability and system design to a rapidly changing class of AI systems.
As organisations move from AI experiments towards systems that can act on their behalf, these questions become increasingly important. Kumar’s contribution is to give engineers practical ways to reason about them: treat external content as untrusted, keep permissions tight, design agents with distributed systems in mind, and delegate only what can be properly verified.
