DEV Community: Atharva Khairnar

Why Most Developers Learn Docker but Never Learn What Comes Next

Atharva Khairnar — Thu, 18 Jun 2026 11:36:04 +0000

Why I Started Learning Kubernetes After Docker (And What Changed)

Most developers stop after learning Docker.

I used to think Docker was enough too.

I could containerize applications, run containers, and deploy services. But as soon as multiple containers entered the picture, new challenges appeared:

Service discovery
Scaling
Load balancing
Health checks
Rolling updates

This is where Kubernetes started making sense.

Docker Solves Packaging

Docker makes applications portable.

docker build -t my-app .
docker run my-app

The same application can run anywhere.

But Docker doesn't solve large-scale orchestration.

Kubernetes Solves Operations

Kubernetes focuses on managing containers at scale.

Instead of manually starting containers, Kubernetes can:

Restart failed containers
Scale applications automatically
Perform rolling updates
Distribute traffic

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3

With a single configuration, Kubernetes can manage multiple instances automatically.

What Surprised Me

The biggest lesson wasn't learning Pods, Services, or Deployments.

It was realized that Docker and Kubernetes solve completely different problems.

Docker packages applications.

Kubernetes manages them.

Understanding this distinction made the entire cloud-native ecosystem much easier to understand.

Let's Be Real about DevOps in 2026

Atharva Khairnar — Thu, 18 Jun 2026 11:29:21 +0000

The Autonomous Infrastructure Era

If an AI agent can watch Kubernetes logs, detect an ImagePullBackOff error, identify the root cause, generate a fix, create a pull request, and restore the deployment...

Do we still need massive Internal Developer Platforms (IDPs)?

Or is AI about to flatten the infrastructure layer itself?

The Purpose of Today's IDPs

Most Internal Developer Platforms exist to reduce complexity.

Instead of every developer becoming a Kubernetes expert, teams build Golden Paths that provide:

Standardized deployments
Self-service infrastructure
Security guardrails
Operational best practices

The goal is simple:

Make the right way the easiest way.

But What Happens When AI Understands the Entire Stack?

Imagine an AI agent with access to:

Kubernetes events
Application logs
CI/CD pipelines
Infrastructure configurations
Monitoring dashboards

Instead of following a predefined workflow, the agent can reason about the system in real time.

A deployment fails.

The agent investigates.

The agent identifies the issue.

The agent proposes a fix.

The agent creates a PR.

The agent restores service.

All without a developer manually jumping between multiple dashboards.

A Traditional Workflow

Developer
    ↓
Check Logs
    ↓
Identify Issue
    ↓
Update Config
    ↓
Create PR
    ↓
Deploy Fix

A Possible Future Workflow

Error
   ↓
Analysis
   ↓
PR Generation
   ↓
Recovery

Example

Imagine a deployment failure caused by an invalid image tag.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app

spec:
  template:
    spec:
      containers:
        - name: main
          image: registry.com/app:latest

An AI agent detects the issue and proposes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app

spec:
  template:
    spec:
      containers:
        - name: main
          image: registry.com/app:v2.0.1

The change is validated and submitted automatically.

The Real Question

Perhaps AI won't replace infrastructure platforms.

Perhaps infrastructure platforms will evolve into AI-powered control planes.

Instead of providing static workflows, they provide:

Context
Guardrails
Permissions
Observability

while autonomous agents handle execution.

Final Thought

For years we've focused on making infrastructure easier for developers.

The next phase might be making infrastructure understandable for AI agents.

And if that happens, the role of the platform may change more dramatically than the infrastructure itself.

What do you think?

Will AI reduce the need for large Internal Developer Platforms?

Or will it make them even more important?

As a developer, what are you spending most of your time learning in 2026?

Atharva Khairnar — Tue, 16 Jun 2026 11:49:43 +0000

AI/GenAI
Cloud
DevOps
System Design
Full Stack
Cybersecurity

Curious to see where everyone is investing their time.

Why Retrieval Quality Can Matter More Than Model Quality in RAG Systems

Atharva Khairnar — Mon, 15 Jun 2026 06:12:10 +0000

One thing that stands out while working with RAG systems is how much influence the retriever has on the final answer.

A common assumption is that improving the model will automatically improve the results. In reality, the model can only work with the context it receives.

If the retriever brings back irrelevant documents, incomplete information, or misses the most relevant content entirely, even a powerful LLM will struggle to produce a useful response.

That's what makes retrievers so important.

Their job isn't to generate answers. Their job is to find the right information at the right time.

In many RAG pipelines, improving retrieval quality can have a bigger impact than switching to a larger model.

The model gets most of the attention, but the retriever often decides whether the answer has a chance of being correct in the first place.

Have you found retrieval quality or model quality to be the bigger bottleneck in your RAG applications?

Is AI Whispering the Evolution of Prompt Engineering?

Atharva Khairnar — Thu, 11 Jun 2026 14:57:37 +0000

For a long time, the focus in GenAI has been Prompt Engineering.

The common advice was simple:

Write better prompts
Provide more context
Structure instructions carefully

Recently, I came across the term AI Whispering, which introduces a slightly different perspective.

Instead of treating AI interactions as a one-shot prompt, AI Whispering views the process as an ongoing conversation.

The goal isn't necessarily to craft the perfect prompt on the first attempt, but to guide the model through:

Refinement
Clarification
Iteration

Prompt Engineering vs AI Whispering

Prompt Engineering

Focuses on designing effective instructions
Optimizes the initial prompt
Treats the interaction as a structured input-output process

AI Whispering

Focuses on steering the interaction
Uses follow-up questions and feedback
Treats the process as a collaborative conversation

An Interesting Observation

Many real-world AI workflows already look more like AI Whispering than traditional Prompt Engineering.

We rarely stop after a single prompt.

Instead, we:

Refine requirements
Challenge outputs
Ask follow-up questions
Gradually shape the response

As models become more capable, I wonder whether the key skill will shift from writing prompts to guiding conversations.

What Do You Think?

Is AI Whispering genuinely different?

Or is it simply Prompt Engineering with a new name?

Why people Think Runnables Are One of the Most Underrated Concepts in LangChain

Atharva Khairnar — Thu, 11 Jun 2026 14:29:33 +0000

One thing I found interesting while working with LangChain is the concept of Runnables.

At first, they look like a small abstraction. But as workflows grow, their value becomes much more obvious.

Without Runnables, every component would need its own way of being called and connected. Prompts, models, retrievers, and output parsers would all behave differently.

Runnables solve this by providing a common interface across components.

This means a PromptTemplate, an LLM, a Retriever, or an Output Parser can all be connected together in a consistent way.

What I like most is that they make workflows feel composable.

Instead of thinking about individual components, you start thinking about pipelines and workflows.

A simple concept on the surface, but one that sits at the foundation of many LangChain applications.

If an LLM Can Answer a Question, Why Does LangChain Need Chains?

Atharva Khairnar — Tue, 09 Jun 2026 10:12:45 +0000

When someone uses a GenAI application, it often feels simple:

Ask a question → Get an answer.

But have you ever wondered what actually happens between those two steps?

In many real-world AI applications, a single user request can trigger multiple operations:

A prompt is generated or formatted
An LLM is called
The output is processed
The response is validated
Data is converted into a structured format

Suddenly, what looked like a single AI call becomes a complete workflow.

The Challenge

Imagine handling each of these steps manually.

Every component would need its own code, its own logic, and its own data flow.

As applications become more complex, managing these interactions quickly becomes difficult.

This raises an important question:

How can we connect all these steps in a clean and reusable way?

Enter Chains

This is where Chains in LangChain become useful.

A chain allows multiple components to be linked together into a workflow.

Instead of managing each step independently, the output of one step automatically becomes the input of the next.

A simplified example:

User Input
↓
Prompt Template
↓
LLM
↓
Output Parser
↓
Final Response

This creates a structured pipeline rather than a collection of disconnected operations.

Why Does This Matter?

As GenAI applications grow, developers spend less time worrying about individual model calls and more time thinking about workflows.

Questions become:

How does data move through the system?
How do different components interact?
How can workflows be reused?

Chains help answer those questions.

An Interesting Fact

One thing I found interesting is that many advanced AI systems start with simple chains.

Before adding agents, memory, tool calling, or multi-agent architectures, developers often build workflows using chains.

In many cases, agents themselves depend on underlying chain-based execution patterns.

Exploring How Redis Can Improve GenAI Application Performance

Atharva Khairnar — Mon, 08 Jun 2026 03:14:02 +0000

As I continue exploring GenAI systems, one challenge that keeps appearing is handling repeated requests efficiently.

Every time a user sends a request to an AI application, the model performs inference to generate a response. While this works well, repeated requests can increase both latency and inference costs, especially as the number of users grows.

This led me to explore how Redis can be used as part of a GenAI application's architecture.

The Challenge

Consider a scenario where users frequently request the same information or interact with similar workflows.

Without any optimization:

User Request → LLM Inference → Response

The model performs inference every time, even when similar data has already been processed.

As traffic increases, this can lead to:

Higher response times
Increased infrastructure costs
Additional load on AI services
Where Redis Fits In

Redis is an in-memory data store known for its speed and simplicity.

In GenAI applications, Redis can be used to store:

Frequently accessed responses
Session data
Conversation state
Intermediate processing results

A simplified flow might look like:

User Request → Redis Check

If data exists:

Return cached result

If data does not exist:

Call LLM
Generate response
Store result in Redis
Return response

This helps reduce unnecessary processing and can improve overall application performance.

What I Found Interesting

One thing that stood out to me is how modern AI systems still rely heavily on traditional infrastructure concepts.

When learning GenAI, it's easy to focus only on models, prompts, and frameworks. However, building efficient AI applications also requires understanding components such as caching, databases, cloud infrastructure, and system design.

Redis is a great example of how an established technology continues to be highly relevant in AI-powered applications.

Final Thoughts

I'm still exploring this area, but learning how infrastructure components integrate with AI systems has been an interesting experience.

It reinforces the idea that building GenAI applications is not only about working with models—it's also about designing systems that can perform efficiently at scale.

DSA Alone Is No Longer Enough: Why Students Should Learn Beyond Coding Problems

Atharva Khairnar — Fri, 05 Jun 2026 05:19:19 +0000

For a long time, the standard advice for computer science students was simple:

Learn a programming language, practice Data Structures and Algorithms, solve LeetCode problems, and prepare for interviews.

While this advice is still valuable, the software industry has evolved significantly over the last few years.

Today, companies are building large-scale distributed systems, cloud-native applications, AI-powered products, and highly scalable platforms. As a result, the expectations from software engineers are changing as well.

DSA remains important because it teaches problem-solving, logical thinking, and helps in technical interviews. However, real-world software development involves much more than solving algorithmic problems.

Modern engineers are expected to understand concepts such as:

System Design
Cloud Computing
Databases
DevOps Practices
CI/CD Pipelines
Containerization with Docker
Orchestration with Kubernetes
Distributed Systems
Machine Learning and AI
Large Language Models (LLMs)

A student may be able to solve difficult LeetCode problems, but building and deploying a production-ready application requires a completely different skill set.

For example, creating a full-stack application is only the first step. Questions that come next are often more important:

How will the application be deployed?
How will it scale when traffic increases?
How will data be stored and backed up?
How will failures be handled?
How will updates be released without downtime?
How will monitoring and logging be implemented?

These are real engineering challenges that developers face every day.

The goal should not be to stop learning DSA. Instead, students should combine DSA with broader system knowledge.

A balanced learning path could look like:

Programming Fundamentals
Data Structures and Algorithms
Databases
Backend Development
Cloud Computing
DevOps and CI/CD
System Design
AI and Emerging Technologies

The students who stand out in the coming years will not necessarily be those who solve the most coding questions. They will be the ones who can understand, build, deploy, and maintain complete systems.

The industry needs engineers, not just interview problem solvers.

DSA can help you get an interview.

Understanding systems can help you build a career.

Full Stack Projects Are Not Enough Anymore

Atharva Khairnar — Mon, 25 May 2026 07:12:43 +0000

A lot of students learn full-stack development today.

They build projects using React, Node.js, MongoDB, APIs, and modern frameworks.

But very few try to integrate the cloud into their projects.

Not because the cloud is unimportant, but because it feels difficult and confusing at first.

And that’s where students can actually stand out.

Building a full-stack project is good.
But deploying it, scaling it, using cloud storage, CI/CD, containers, monitoring, and infrastructure makes it feel closer to a real-world system rather than just another CRUD project.

The difference between developers is slowly shifting from:

Who can build applications? To whom can one build production-ready systems?

Good Code Is Not the Same as Production-Ready Code

Atharva Khairnar — Wed, 28 Jan 2026 18:56:05 +0000

For developers or students with around 3–6 months of experience, writing clean and working code feels like a big achievement — and it should. It means you understand syntax, logic, and basic structure.

But there’s an important distinction that often appears next:

Good code is not always production-ready code.

Production environments introduce realities that local development rarely shows:

Network failures
Unexpected input
Performance constraints
Security concerns
Long-term maintenance

Code that works perfectly in isolation may fail under these conditions.

As developers, growth happens when we:

Revisit the code we’ve already written
Ask how it behaves under failure
Explore better ways to structure it
Improve readability, error handling, and scalability
Learn alternative approaches and design patterns

This doesn’t mean rewriting everything from scratch. Often, it’s about refining the same logic with better practices.

Exploring production-ready methodologies — logging, validation, defensive coding, monitoring, and clear boundaries — helps bridge the gap between “it works” and “it lasts.”

That shift in mindset is what turns a beginner developer into a reliable engineer.

Things Tutorials Don’t Teach You About Building Real Applications

Atharva Khairnar — Mon, 26 Jan 2026 18:08:31 +0000

After working on multiple real-world applications, one thing has become clear to me: Tutorials are useful, but they only cover a very small part of what it actually means to build software.

Real applications expose challenges that tutorials rarely address — not because they are unimportant, but because they are hard to simulate in controlled examples.

The Hard Problems Are Rarely About Syntax

In real systems, bugs are rarely caused by not knowing a language feature.

Most problems come from:

Incorrect assumptions about data
Misunderstood requirements
Unclear ownership between services
Edge cases that were not considered

Syntax can be learned quickly. Judgment and system thinking take time.