DEV Community: Jaideep Parashar

I Asked AI to Review My Code. It Found Bugs I Didn't See.

Jaideep Parashar — Fri, 18 Sep 2026 10:36:28 +0000

For a long time, I used AI in software development for one primary purpose:

Write the code.

Give it a requirement.

Get some Python.

Ask for a function.

Get a function.

Describe an API.

Get an API.

It was fast. Sometimes impressively fast.

But recently, I've been using AI differently.

Instead of asking:

"Can you write this for me?"

I've started asking:

"Can you review what I wrote?"

And the difference surprised me.

AI wasn't just helping me write code faster.

It was helping me look at my own code differently.

The Problem With Asking AI to Write Everything

There is an obvious benefit to AI-generated code.

You can move from an idea to a working prototype extremely quickly.

But there's a downside.

When AI writes the code, I can become focused on whether the code works rather than whether the code is actually good.

It is very easy to accept:

It runs → Ship it.

But software engineering doesn't end when the program runs.

What happens with unexpected input?

What happens when the API fails?

What happens when the database is unavailable?

What happens when the data is empty?

What happens when another developer has to maintain it six months from now?

Those questions are much harder to answer by simply generating more code.

That's where code review becomes interesting.

So I Tried a Different Workflow

Instead of starting with AI, I started with myself.

I wrote the code.

Then I asked AI to review it.

My prompt was intentionally simple:

Review this code as a senior software engineer. Don't rewrite it immediately. First identify potential bugs, edge cases, security concerns, maintainability problems, and unnecessary complexity. Explain why each issue matters.

That last sentence matters.

I didn't want AI to immediately produce another 100 lines of code.

I wanted it to think about the code first.

It Found Things I Hadn't Considered

Some findings were obvious once pointed out.

Others were not.

For example, a function might work perfectly for normal input but behave incorrectly when it receives:

an empty list
a missing value
unexpected data
a duplicate record
a failed API response
a very large input

None of these necessarily appear during a quick manual test.

And that's the interesting part.

A second reviewer doesn't need to discover something magical.

Sometimes it simply needs to ask:

"What happens if this assumption isn't true?"

That question alone can expose a surprising number of problems.

But AI Didn't Always Get It Right

This is where things get interesting.

I don't treat AI's review as truth.

Sometimes it identifies a genuine issue.

Sometimes it identifies something that isn't actually a problem.

And sometimes it suggests a change that would make the code more complicated without providing meaningful value.

This is exactly why I don't think AI replaces code review.

It changes the review process.

The developer still has to decide:

Is this actually a problem?
How serious is it?
Is the suggested solution appropriate?
What trade-off does it introduce?

AI can point at something.

It cannot automatically decide whether changing it is worth the cost.

The Most Useful AI Review Isn't "Fix My Code"

I've noticed a subtle difference between two prompts.

Prompt 1

Fix this code.

Prompt 2

Review this code and tell me what I should worry about.

The first asks AI to become the programmer.

The second asks AI to become the reviewer.

I find the second approach much more interesting.

Because it keeps me involved in the reasoning.

Instead of outsourcing the entire task, I'm using AI to increase the number of perspectives looking at the problem.

I Wouldn't Use AI as the Only Reviewer

There are still things AI may not understand.

It might not know why a particular architectural decision was made.

It might not understand the business requirement.

It may not know which performance trade-off is acceptable.

It may flag code that looks unusual but is intentionally designed that way.

And it can confidently make incorrect claims.

So I think of AI code review as another layer.

Something like:

Developer writes code
↓
Automated tests
↓
AI review
↓
Human review
↓
Production
↓
Monitoring

Each layer answers a different question.

Tests ask:

Does the software behave correctly for the cases we've defined?

AI review asks:

What problems might we have overlooked?

Human review asks:

Does this implementation make sense in the real system?

Monitoring asks:

What happens after real users start using it?

No single layer is enough.

There's Another Benefit I Didn't Expect

AI reviewing my code has also changed how I write code.

When I know I'll eventually ask an AI to review something, I become more deliberate about my implementation.

I think more about:

naming
assumptions
edge cases
error handling
duplicated logic
unnecessary complexity

In other words, the reviewer starts influencing the author.

And that's a useful side effect.

The goal isn't simply to have AI catch mistakes.

The goal is to become better at anticipating mistakes before they happen.

This Applies Beyond AI-Generated Code

There's a temptation to think AI code review is useful only when AI generated the original code.

I don't think that's true.

Human-written code has bugs.

Human-written code has assumptions.

Human-written code becomes difficult to maintain.

Human-written code gets reviewed by people who are tired, rushed, or unfamiliar with the particular problem.

A second perspective can be valuable regardless of who wrote the original code.

AI is simply an unusually fast second perspective.

But Don't Confuse Review With Testing

This distinction is important.

AI can tell me:

"This function may fail when the API returns an empty response."

That's useful.

But a test can actually execute the scenario.

For example:

def test_empty_api_response(): response = process_api_response([]) assert response == expected_result

The two approaches complement each other.

AI can help identify what to test.

Tests can verify what actually happens.

That's a much stronger workflow than relying on either one independently.

I've written before about how developers routinely test traditional software while treating AI behavior differently. I think the same principle applies here:

AI should become part of an engineering discipline, not a replacement for it.

The Bigger Lesson

The most interesting change isn't that AI can review code.

We've known that AI can analyze code.

The bigger change is that we can now cheaply introduce additional reasoning into our development process.

A developer working alone can effectively have another pair of eyes available within seconds.

That doesn't mean the second pair of eyes is always correct.

It means the cost of asking for another perspective has become extremely low.

And when something is cheap enough, we can incorporate it into our workflow.

I'm Changing How I Use AI for Coding

I still use AI to generate code.

It would be silly not to take advantage of that capability.

But I don't want my relationship with AI to become:

Human thinks → AI writes.

I'd rather have:

Human thinks → AI helps build → AI challenges → Human evaluates → Tests verify.

That is a much healthier development loop.

Because the objective isn't to remove the developer from the process.

It is to make the developer better at the process.

Maybe AI's Best Coding Feature Isn't Code Generation

We spend an enormous amount of time talking about how quickly AI can write code.

I'm starting to think another capability deserves more attention:

AI can challenge the code we already wrote.

It can ask questions we didn't think to ask.

It can point toward assumptions we forgot we were making.

It can identify edge cases hiding behind apparently simple functions.

It can suggest tests.

It can act as a tireless second set of eyes.

But there is an important condition:

We still have to think.

If we blindly accept AI-generated code, we haven't improved the engineering process.

We've simply accelerated it.

And accelerated bad decisions are still bad decisions.

So perhaps the better question isn't:

"How can AI write more of my code?"

Maybe it's:

"How can AI help me become a better engineer?"

That's the question I'm increasingly interested in.

How are you using AI in your development workflow today, primarily as a code generator, debugger, reviewer, teacher, or something else?

Want More:

Head over to ReThynk AI to access our latest research, magazine articles, and developer resources. Click Here

I Think Developers Are Building Too Much Software

Jaideep Parashar — Fri, 11 Sep 2026 03:36:19 +0000

There was a time when the difficult part of building software was writing the software.

Today, that is increasingly not true.

We have better frameworks, better libraries, better APIs, better cloud infrastructure, better developer tools, and now AI can generate a significant amount of the code for us.

Yet I keep seeing the same pattern:

We are getting better at building things, but not necessarily better at deciding what should be built.

And I think that is becoming one of the biggest engineering problems of our time.

Software Has Become Too Easy to Start

Think about what it takes to build an application today.

You can generate a frontend in minutes.

Connect an API.

Add authentication.

Add a database.

Deploy it.

Add an AI model.

Give the model access to tools.

Add an agent.

Add another service.

Add monitoring.

Add a queue.

Add a vector database.

Add an orchestration framework.

Before long, you have a surprisingly sophisticated architecture.

And sometimes you have solved a problem that didn't actually require any of it.

This is the paradox of modern software development:

The cheaper it becomes to build software, the easier it becomes to build unnecessary software.

AI Made This Problem Bigger

AI has changed the equation even further.

Previously, I might have spent several hours implementing a feature.

Today, I can describe the feature and have an AI coding assistant generate much of the implementation.

That is incredibly useful.

But it also removes an important friction.

When building something required significant effort, effort itself acted as a filter.

You naturally asked:

"Is this worth building?"

When implementation becomes cheap, that question becomes easier to ignore.

You can simply build it.

And then build another version.

And then add another feature.

And then add an agent because the agent framework looks interesting.

The cost of implementation falls.

But the cost of complexity does not disappear.

Every Feature Creates a Future Problem

A feature rarely costs only what it takes to build it.

It also creates:

code to maintain
bugs to investigate
dependencies to update
documentation to maintain
edge cases to handle
users to support
security concerns
performance considerations
monitoring requirements
decisions future developers need to understand

This is why a 30-minute feature can sometimes create a six-month maintenance problem.

The original implementation was cheap.

The system became expensive.

This is particularly dangerous with AI-generated code because the initial implementation can feel almost free.

You ask for a feature.

The code appears.

It works.

You move on.

Six months later, someone has to understand why seventeen components depend on it.

Complexity Is a Technical Debt You Can See Too Late

Developers are generally good at recognizing obvious technical debt.

Poor naming.

Duplicated code.

Missing tests.

Outdated dependencies.

Large functions.

But there is another type of technical debt that is harder to recognize:

unnecessary architecture.

You can have beautifully written code inside an unnecessarily complicated system.

You can have excellent abstractions that nobody needed.

You can have perfectly implemented microservices where a single application would have been enough.

You can have an impressive AI agent where a deterministic workflow would have been safer.

The individual components can all be technically correct.

The overall system can still be wrong.

I Am Increasingly Suspicious of "More"

More services.

More abstractions.

More tools.

More frameworks.

More automation.

More agents.

More integrations.

More dashboards.

More features.

More AI.

None of these things are inherently bad.

The problem starts when more becomes the default definition of progress.

Sometimes the best engineering decision is to remove something.

Remove a dependency.

Remove an abstraction.

Remove a service.

Remove an AI step.

Remove a feature.

Remove an entire workflow.

That can be harder than adding something.

Because adding demonstrates activity.

Removing requires judgment.

The Best Architecture Might Look Boring

There is something I have increasingly come to appreciate about good systems:

They can look surprisingly boring.

Imagine two solutions.

System A

User → API → Database → Response

System B

User → Gateway → Service A → Queue → Service B → Agent → Tool Router → Vector DB → External API → Validation Service → Event Bus → Service C → Database → Response

System B looks more sophisticated.

But sophistication isn't the same thing as quality.

If both systems solve the same problem reliably, System A may be dramatically better.

Not because it uses newer technology.

Because it has fewer things that can break.

This is why I increasingly believe that simplicity is not the absence of engineering.

It is the result of engineering judgment.

This Is Where AI Agents Fit Into the Conversation

This is also why I have become cautious about the current obsession with AI agents.

Agents are useful.

There are problems where dynamic decision-making, tool selection, iteration, and autonomy genuinely create value.

But if a deterministic workflow can solve the problem, an agent may simply introduce additional uncertainty.

The question shouldn't be:

"Can I turn this into an agent?"

The better question is:

"Does this problem actually require autonomous decision-making?"

That distinction matters.

I wrote about this in more detail in my article “Stop Building AI Agents. Start Building AI Systems.”

The broader principle is the same:

Don't optimize for technological sophistication. Optimize for the outcome.

We Need a New Engineering Question

For a long time, developers were encouraged to ask:

"How do I build this?"

Then we learned to ask:

"How do I build this well?"

I think there is another question we need to put before both:

"Should this exist at all?"

That question applies to much more than software.

Should this feature exist?

Should this service exist?

Should this automation exist?

Should this database exist?

Should this AI component exist?

Should this entire application exist?

Sometimes the answer will be yes.

But sometimes the answer will be:

No.

And that's not failure.

That's engineering.

AI Makes Judgment More Valuable, Not Less

This is perhaps the most interesting consequence of AI-assisted development.

If AI continues making implementation faster, then implementation itself becomes less differentiated.

The valuable skills move upward.

Understanding the problem.

Defining the right requirements.

Choosing the right architecture.

Recognizing unnecessary complexity.

Knowing when not to automate.

Knowing when not to use AI.

Understanding trade-offs.

Evaluating whether something actually works.

And, perhaps most importantly:

knowing what not to build.

AI can generate ten possible implementations before you've finished explaining the problem.

That makes judgment more important, not less.

Before You Build the Next Thing

I've started thinking about software decisions through a much simpler filter.

Before building something, ask:

What problem does this solve?

If you cannot explain the problem clearly, stop.

Who actually needs it?

"Someone might use this" is not a strong enough answer.

What is the simplest solution?

Not the most impressive.

The simplest.

What complexity will this introduce?

Think beyond today's implementation.

Does this need automation?

Maybe a manual process is perfectly acceptable.

Does this need AI?

Maybe a rule, query, function, or conventional application is better.

What happens if we don't build it?

This is the question I think we ask far too rarely.

Sometimes nothing happens.

And that may be the best outcome.

The Builder's Paradox

We are entering an unusual period in software development.

Building is becoming incredibly easy.

But deciding what deserves to be built may become increasingly difficult.

That creates a strange paradox:

The better our tools become, the more important restraint becomes.

When writing code was expensive, we naturally avoided unnecessary code.

When infrastructure was difficult, we naturally avoided unnecessary infrastructure.

When software development becomes increasingly assisted by AI, we will need a different constraint.

Judgment.

Not everything that can be built deserves to exist.

Not every workflow needs automation.

Not every application needs AI.

Not every AI application needs an agent.

And not every technical problem needs a technical solution.

Maybe the next great developer skill isn't building faster.

Maybe it's learning to look at a problem and confidently say:

"We don't need to build this."

What do you think?

Are developers becoming better at building software or simply better at building more of it?

Note: Looking for deeper insights into the future of artificial intelligence? Head over to ReThynk AI to access our latest research, magazine articles, and developer resources. Click Here

Stop Building AI Agents. Start Building AI Systems.

Jaideep Parashar — Fri, 04 Sep 2026 05:27:08 +0000

There's a phrase I keep seeing everywhere in AI development:

"We need an AI agent."

Need to analyze documents?

Build an agent.

Need to automate a workflow?

Build an agent.

Need to interact with APIs?

Build an agent.

Need to write code?

Build an agent.

At some point, I started asking a different question:

Why are we so obsessed with building agents when what users actually need are reliable systems?

I don't think the agent is the product.

The system is the product.

And that distinction matters.

An Agent Is Only One Component

Let's take a simple AI customer-support application.

The agent might be responsible for deciding which tool to call.

But the actual application needs much more:

User
↓
Authentication
↓
Request Validation
↓
Context Retrieval
↓
AI Agent
↓
Tool Selection
↓
API / Database
↓
Output Validation
↓
Safety Checks
↓
Response
↓
Logging
↓
Evaluation

Where is the agent?

Right in the middle.

It's important.

But it's not the entire system.

This is why I believe we're spending too much time discussing agent capabilities and not enough time discussing system architecture.

The Agent Is Not Your Architecture

I've seen AI projects where the architecture diagram looks like this:

User
↓
AI Agent
↓
Magic

It makes for a great presentation.

It doesn't make for a great production system.

Real applications need answers to much less glamorous questions:

Where does the data come from?
How is context retrieved?
What happens when retrieval fails?
What happens when the model produces invalid output?
How are tool calls validated?
How are errors handled?
How do we monitor the system?
How do we evaluate quality?
Who owns the system after deployment?

These questions aren't exciting.

They're engineering.

And engineering is what turns an AI demo into a product.

Start With the Workflow

Before I decide whether an application needs an agent, I first map the workflow.

For example:

Customer Question
↓
Identify Intent
↓
Retrieve Relevant Information
↓
Generate Response
↓
Validate Response
↓
Escalate if Necessary

Maybe that's all we need.

Why introduce an autonomous agent if the workflow is already predictable?

This is the central idea behind my article Why I Think Workflows Matter More Than Agents.

A workflow gives us control.

An agent gives us flexibility.

We should choose flexibility only when the problem actually requires it.

Agents Make Sense When Decisions Are Dynamic

I'm not anti-agent.

Quite the opposite.

Agents are extremely useful when the path through the system cannot be predetermined.

For example:

Research Request
↓
Agent
┌────┼────┐
↓ ↓ ↓
Web SQL GitHub
└────┼────┘
↓
Synthesize
↓
Validate

The agent can determine which tools are necessary.

That's valuable.

But notice something important.

The agent still operates inside a larger system.

That's the distinction I think we need to make.

Reliability Is a System Property

Suppose your agent is incredibly intelligent.

It can reason.

It can plan.

It can use tools.

It can recover from errors.

Does that guarantee that your application is reliable?

No.

Reliability also depends on:

Data quality
Retrieval quality
API reliability
Validation
Authentication
Observability
Evaluation
Infrastructure

You can have an excellent agent inside a terrible system.

The user will still experience a terrible product.

Evaluate the System, Not Just the Model

This is another area where AI development needs to mature.

Developers naturally evaluate the model:

"Which model gives better answers?"

But production systems need broader evaluation.

Consider:

Model Quality
+
Retrieval Quality
+
Tool Accuracy
+
Workflow Reliability
+
Latency
+
Cost
+

Safety

System Quality

I've written about this in Most Developers Test Their Code. Why Don't They Test Their AI?

The important shift is from:

"Is the model good?"

to:

"Does the complete system consistently achieve the desired outcome?"

That's a much more useful question.

For organizations, this can be formalized through an AI Evaluation Framework: 7 Critical Metrics for AI Success, which looks beyond model capability toward measurable AI performance.

Context Is Part of the System

Another common mistake is treating the prompt as the entire intelligence layer.

It isn't.

Consider a coding assistant.

The model might receive:

Prompt:
"Fix this bug."

But the system may also provide:

Repository
+
Relevant Files
+
Documentation
+
Dependencies
+
Previous Errors
+
Coding Standards

That context can completely change the quality of the result.

This is why I've argued that context engineering is becoming more important than simply optimizing prompts.

The model doesn't just need instructions.

It needs the right information.

MCP Makes Systems More Connected

This is where MCP becomes particularly interesting.

Instead of building a separate custom integration for every AI capability, MCP provides a standardized way for AI applications to interact with external tools and data.

For example:

AI System
↓
MCP
┌──┼──────┐
↓ ↓ ↓
GitHub DB Files

Now the agent or model isn't isolated.

It becomes part of a connected system.

I've explored practical examples in 5 MCP Servers That Changed How I Build AI Workflows.

Don't Confuse More Components With More Intelligence

There's another trap.

Once developers discover agents, they start adding components.

One agent becomes three.

Three become ten.

Then comes:

Agent supervisor
Planner agent
Research agent
Coding agent
Reviewer agent
Memory system
Vector database
Multiple models

Eventually:

Simple Problem
↓
Complex Architecture
↓
More Failure Points
↓
More Debugging
↓
More Cost

This is one reason I wrote The Hidden Cost of Using Too Many AI Tools.

Complexity isn't evidence of sophistication.

Sometimes it's evidence that we haven't simplified the problem enough.

The Production Test

Here's a test I like to use.

Before calling an AI application production-ready, ask:

Can we reproduce failures?

If not, observability is weak.

Can we measure quality?

If not, evaluation is weak.

Can we control the workflow?

If not, architecture may be too autonomous.

Can we replace the model?

If not, the system may be too tightly coupled.

Can another developer maintain it?

If not, complexity may already be too high.

These questions tell me much more than whether an agent can successfully complete a demo.

Build the System Around the Outcome

The most important shift is this:

Don't start with:

"What agent should we build?"

Start with:

"What outcome are we trying to reliably produce?"

Then work backward.

Desired Outcome
↓
Process
↓
Workflow
↓
Context
↓
Tools
↓
Model
↓
Agent — only if necessary
↓
Evaluation
↓
Production

The agent becomes a design decision.

Not the starting assumption.

My Rule for AI Architecture

I now think about AI systems using a simple hierarchy:

Outcome
↓
Process
↓
Workflow
↓
Context
↓
Tools
↓
Model
↓
Agent

Notice where the agent appears.

Near the bottom.

That's intentional.

Because an agent should exist to serve the architecture.

The architecture shouldn't exist to justify having an agent.

Final Thoughts

The AI industry has become very good at building autonomous demos.

Now I think we need to become much better at building dependable AI systems.

Systems that can:

Be evaluated
Be monitored
Be debugged
Be governed
Be maintained
Be scaled
Be improved

Agents will absolutely be part of that future.

But they won't be the whole future.

The winning AI products won't necessarily have the most agents.

They'll have the best-designed systems around those agents.

So before you start your next agent project, pause for a moment.

Draw the workflow.

Define the outcome.

Identify the context.

Determine the tools.

Design the evaluation.

And only then ask:

"Do I actually need an agent?"

That question alone can save you weeks of unnecessary engineering.

Your AI Demo Works. So Why Is Your Product Failing?

Jaideep Parashar — Fri, 28 Aug 2026 08:31:56 +0000

I've seen this pattern repeatedly in AI development.

Someone builds an impressive prototype.

The prompt works.

The demo looks amazing.

Everyone in the meeting gets excited.

Then the project enters the real world.

And suddenly everything becomes difficult.

The responses aren't consistent.

Users ask questions nobody anticipated.

The context is incomplete.

Costs increase.

Latency becomes a problem.

Nobody knows how to evaluate the system.

Eventually, the "successful AI project" becomes another abandoned prototype.

This leads to an uncomfortable question:

If the demo worked, why didn't the product?

I think the answer is simple.

A demo proves that something is possible. A product has to prove that it is reliable.

A Demo Is Not a Product

Consider an AI document assistant.

Your prototype might look like this:

PDF
↓
LLM
↓
Question
↓
Answer

You upload one excellent document.

Ask three carefully selected questions.

The model produces impressive answers.

Demo complete.

But production looks more like this:

User
↓
Authentication
↓
Document Retrieval
↓
Context Selection
↓
LLM
↓
Validation
↓
Logging
↓
Evaluation
↓
Response

Now you have an engineering system.

And every additional component introduces potential failure.

The Prototype Trap

AI makes prototyping incredibly easy.

That's both a blessing and a problem.

A developer can create something impressive in an afternoon.

That creates the illusion that the hard part is finished.

It isn't.

The prototype answers:

"Can we make this work?"

Production asks:

"Can we make this work reliably thousands of times?"

Those are completely different questions.

The First Problem: Nobody Defined "Good"

This is probably the biggest issue I see.

Teams build an AI application without defining what a good output actually means.

Imagine an AI coding assistant.

What does success mean?

Is the generated code:

Syntactically valid?
Functionally correct?
Secure?
Tested?
Consistent with the existing architecture?
Maintainable?

If you don't define these criteria, you can't properly evaluate the system.

And if you can't evaluate it, you can't improve it systematically.

I've written about this problem in Most Developers Test Their Code. Why Don't They Test Their AI?

The principle is straightforward:

AI systems need tests too.

The Second Problem: The Context Is Wrong

Another common mistake is blaming the model when the real problem is context.

Suppose you're asking an AI assistant to fix a Python bug.

You provide:

Fix this authentication bug.

But the system doesn't know:

Which framework you're using
Your database schema
Authentication architecture
Existing middleware
Coding conventions
Related files

Even a powerful model is operating with incomplete information.

That's why I've become increasingly interested in context engineering.

The quality of an AI system depends not only on the instruction but also on the information supplied around it.

I explored this in Why Context Engineering Is More Important Than Prompt Engineering.

The Third Problem: The Workflow Was Never Designed

Another common pattern is:

User
↓
LLM
↓
Answer

That's fine for a chatbot.

It isn't necessarily enough for a production application.

A reliable AI system might instead look like:

Request
↓
Classify
↓
Retrieve Context
↓
Generate
↓
Validate
↓
Apply Business Rules
↓
Return Result
↓
Log Outcome

The model is only one component.

This is also why I believe workflows matter more than agents.

Before adding autonomy, memory, planning, or multiple agents, I want to know whether the underlying workflow is actually well designed.

The Fourth Problem: Teams Add AI Before Fixing the Process

This one is particularly important in enterprise AI.

Imagine a company has a slow approval process.

Instead of examining the process, they immediately add an AI agent.

The agent now automates:

Bad Process
↓
AI
↓
Faster Bad Process

That's not transformation.

That's automation of inefficiency.

I've explored this extensively in Why You Should Fix Your Process Before Implementing AI.

The process should determine where AI belongs, not the other way around.

The Fifth Problem: Nobody Owns the System

Who owns the AI application after launch?

The developer?

The product team?

The data team?

The business?

Nobody?

This sounds like an organizational question, but it directly affects technical quality.

Someone needs to own:

Evaluation
Prompt changes
Model changes
Data quality
Monitoring
Security
Cost
User feedback

Without ownership, AI systems slowly degrade.

What I Now Ask Before Calling an AI Project "Ready"

Before moving an AI project from prototype to production, I want answers to five questions:

What problem are we solving?
What does a good output look like?
What context does the system need?
How will we evaluate failures?
Who owns the system after launch?

If we can't answer these questions, we're probably not ready.

We're still experimenting.

And that's completely fine.

Experimentation isn't failure.

Pretending an experiment is a production system is.

Build the Smallest Reliable System

My philosophy has changed considerably as I've built more AI systems.

I don't want the most sophisticated architecture.

I want the smallest architecture that reliably solves the problem.

That might mean:

Python
+
FastAPI
+
One LLM
+
A database
+
A simple workflow
+
Evaluation

Not:

7 agents
+
4 frameworks
+
3 vector databases
+
12 tools
+
complex orchestration

More technology doesn't automatically create more intelligence.

Sometimes it creates more places for things to break.

I've discussed this broader problem in The Hidden Cost of Using Too Many AI Tools.

Turn the Prototype Into an Engineering System

If I had to summarize the transition in one diagram, it would be:

DEMO

Prompt
↓
LLM
↓
Interesting Output

PRODUCT

Problem
↓
Workflow
↓
Context
↓
LLM
↓
Validation
↓
Evaluation
↓
Monitoring
↓
Continuous Improvement

That's the difference.

The model didn't necessarily change.

The engineering around the model did.

Final Thoughts

The AI industry has become exceptionally good at creating impressive demos.

I'm less interested in impressive demos.

I'm interested in systems that continue working after the demo ends.

Systems that can be tested.

Systems that can be monitored.

Systems that can be improved.

Systems that developers can actually maintain.

That's where I think the next level of AI engineering will come from.

Not from making the demo more impressive.

From making the system more dependable.

So the next time your AI prototype works perfectly, don't celebrate too early.

Ask the harder question:

"What happens when this meets 10,000 real users?"

That's when the real engineering begins.

Most Developers Test Their Code. Why Don't They Test Their AI?

Jaideep Parashar — Fri, 21 Aug 2026 05:21:43 +0000

Here's something I've been thinking about while building AI systems:

Developers are obsessed with testing code.

We write unit tests.

Integration tests.

End-to-end tests.

CI pipelines.

Code reviews.

Linting.

Type checking.

But then we build an AI feature and suddenly the testing strategy becomes:

"I tried it three times and it seems pretty good."

That's not testing.

That's optimism.

And I think this is becoming one of the biggest weaknesses in AI development.

AI Applications Are Software

Consider a simple AI coding assistant.

The workflow might look like this:

User Request
↓
Context Retrieval
↓
Prompt
↓
LLM
↓
Generated Code
↓
Validation

Every component can fail.

The retrieval can return the wrong files.

The context can be incomplete.

The prompt can be ambiguous.

The model can hallucinate.

The generated code can contain bugs.

Yet many AI applications have no automated way of detecting these failures.

We wouldn't accept that standard from a normal API.

Why should AI be different?

"It Worked Once" Means Almost Nothing

Suppose you're building a system that converts natural language into SQL.

You test:

"Show me the top 10 customers by revenue."

The model generates:

SELECT customer_name, SUM(revenue) AS total_revenue
FROM sales
GROUP BY customer_name
ORDER BY total_revenue DESC
LIMIT 10;

Looks good.

You ship it.

Then a user asks:

"Show me the top 10 customers by revenue in 2025,
excluding cancelled orders."

Suddenly your system may produce completely different behavior.

AI outputs are probabilistic.

That means testing one input isn't enough.

Build an Evaluation Dataset

One of the simplest things an AI builder can do is create a small evaluation dataset.

For example:

test_cases = [
    {
        "input": "Find the top 10 customers by revenue.",
        "expected_contains": ["GROUP BY", "ORDER BY", "LIMIT"]
    },
    {
        "input": "Find revenue for 2025 excluding cancelled orders.",
        "expected_contains": ["2025", "cancelled"]
    },
]

Now you can run your AI system against the same cases whenever you change:

The prompt
The model
The retrieval system
The context
The workflow

That changes everything.

You're no longer asking:

"Does this feel better?"

You're asking:

"Did performance improve?"

Prompts Need Tests Too

This is one reason I don't think prompt engineering is disappearing.

A production prompt isn't just something you write once.

It is part of the system.

And if you change it, you should know whether the change improved the output.

I discussed the importance of this broader discipline in The Real Reason Prompt Engineering Isn't Going Away.

The next step is to connect prompt engineering with evaluation.

Think of it like software:

Prompt v1
↓
Evaluation
↓
Results
↓
Prompt v2
↓
Evaluation
↓
Compare

That's much more reliable than changing prompts based on intuition.

Context Needs Testing Too

Here's another problem.

You can have a perfect prompt and still get a terrible answer because the AI received the wrong context.

Imagine a coding assistant receives:

Prompt:
"Fix the authentication bug."

Context:

5 unrelated files
+
outdated documentation
+
wrong configuration

The model may generate perfectly reasonable code based on completely incorrect information.

This is why I believe context engineering is becoming just as important as prompt engineering.

I wrote about this in Why Context Engineering Is More Important Than Prompt Engineering.

The lesson is simple:

Don't only test what you ask the model. Test what you give the model.

Workflows Need Evaluation

This becomes even more important when AI is part of a larger workflow.

Consider:

User
↓
Retriever
↓
LLM
↓
Tool Call
↓
Validation
↓
Final Response

Where did the failure happen?

You need to know.

Was the retrieval wrong?

Did the model select the wrong tool?

Did the API return bad data?

Did validation fail?

This is one reason I've argued that workflows often matter more than agents.

A well-defined workflow gives you clear places to measure and debug.

I explored that argument in Why I Think Workflows Matter More Than Agents.

Start Small

You don't need an expensive AI evaluation platform to begin.

Start with 20–50 representative test cases.

For each case, record:

Input
Expected Behavior
Actual Output
Pass/Fail
Notes

Then run the dataset whenever you make a significant change.

Over time, your evaluation dataset becomes one of the most valuable assets in your AI project.

It captures what "good" actually means.

My AI Evaluation Rule

I've started thinking about AI systems in three layers:

Can it produce an answer?

Basic functionality.

Can it produce a correct answer consistently?

Reliability.

Can we measure whether it is improving?

Engineering maturity.

The third question is where many AI projects struggle.

If you cannot measure improvement, you're mostly guessing.

Evaluation Is the Missing Layer

The AI industry has spent enormous effort improving:

Models
Prompts
Agents
RAG
MCP
Vector databases

But evaluation deserves the same attention.

Because eventually every AI system needs to answer one uncomfortable question:

"How do you know it works?"

Not:

"The demo looked impressive."

Not:

"The model is highly capable."

Not:

"Users seem to like it."

Show me the evaluation.

That's the engineering mindset I want to see more often in AI.

Build This Into Your GitHub Workflow

I'm also adding a simple AI evaluation starter to my companion AI Builder resources.

A useful structure is:

ai-evaluation/
├── README.md
├── test_cases.json
├── evaluate.py
├── results.csv
└── prompts/
├── v1.txt
└── v2.txt

The idea is straightforward:

Prompt changes → Run tests → Record results → Compare versions.

This turns experimentation into an engineering process.

Final Thoughts

I don't think AI development should be:

Prompt
↓
Looks good
↓
Ship

It should look more like:

Build
↓
Evaluate
↓
Measure
↓
Improve
↓
Evaluate Again
↓
Deploy

That's how we build reliable software.

And I believe that's how we need to start building reliable AI.

The future of AI engineering won't belong only to people who know how to make models produce impressive outputs.

It will belong to developers who can measure, reproduce, debug, and improve those outputs.

Because the most important question in AI isn't:

"Can the model do it?"

It's:

"Can I prove that my system does it reliably?"

The 7 AI Repositories I Starred This Month

Jaideep Parashar — Mon, 17 Aug 2026 06:31:54 +0000

I don't star GitHub repositories just because they are popular.

A repository earns a star from me when I can see myself returning to it later.

Maybe it solves a real engineering problem.

Maybe it introduces a new architecture.

Maybe the code teaches me something.

Or maybe it represents where AI development is heading.

I've been spending a lot of time exploring AI repositories around agents, workflows, RAG, MCP, browser automation, model training, and API development.

These are seven repositories that stood out to me recently.

Not because you need all seven.

But because each one represents an important direction in AI development.

1. OpenAI Cookbook

Repository: https://github.com/openai/openai-cookbook

If you're building with the OpenAI API, this is one repository I would keep bookmarked.

The OpenAI Cookbook contains practical examples and guides covering common API development tasks, with many examples written in Python.

What I particularly like is the implementation-first approach.

Instead of spending hours reading theoretical explanations, you can study working examples and adapt them to your own application.

It's useful for:

API integration
Structured outputs
Embeddings
Agents
Evaluations
Multimodal applications

For beginners, it can also serve as a bridge between understanding an AI concept and actually implementing it.

2. LangChain

Repository: https://github.com/langchain-ai/langchain

LangChain remains one of the most important repositories in the LLM application ecosystem.

But I don't recommend it simply because it is popular.

I recommend understanding it because it exposes you to the building blocks behind modern AI applications.

Models.

Tools.

Retrievers.

Agents.

Integrations.

Structured outputs.

If you're serious about AI engineering, studying how these components fit together is valuable even if you eventually choose another framework.

3. LangGraph

Repository: https://github.com/langchain-ai/langgraph

This is probably one of the repositories I would recommend most strongly to developers interested in agentic systems.

LangGraph focuses on building stateful, controllable agents and long-running workflows.

What interests me most isn't the word "agent."

It's control.

AI systems become difficult when you don't know what happened during execution.

LangGraph provides concepts around state, persistence, human-in-the-loop interaction, and workflow orchestration.

That aligns closely with an idea I've written about before:

I believe workflows often matter more than agents.

I explored that argument in Why I Think Workflows Matter More Than Agents:

https://dev.to/jaideepparashar/why-i-think-workflows-matter-more-than-agents-3p82

4. LlamaIndex

Repository: https://github.com/run-llama/llama_index

If you're interested in RAG, document intelligence, or connecting LLMs to private data, LlamaIndex deserves your attention.

Its ecosystem provides tools for ingesting and structuring information from sources such as:

PDFs
APIs
Documents
SQL databases
Knowledge bases

The important idea here is simple:

An LLM becomes much more useful when it can work with your data.

This is also why I've become increasingly interested in context engineering rather than thinking only about prompt engineering.

The quality of the information supplied to the model can matter just as much as the wording of the instruction.

5. Browser Use

Repository: https://github.com/browser-use/browser-use

This is one of the more interesting repositories if you're thinking about AI agents interacting with the actual web.

Browser Use allows AI agents to control browsers and perform actions such as navigating websites, clicking elements, entering information, and extracting data.

That opens up a different category of AI applications.

Instead of:

User → Prompt → LLM → Text

You can build:

User
↓
AI Agent
↓
Browser
↓
Website
↓
Action
↓
Result

That's a significant shift.

The AI isn't merely generating an answer.

It's interacting with software.

6. Model Context Protocol Servers

Repository: https://github.com/modelcontextprotocol/servers

MCP has become one of the most interesting developments in the AI tooling ecosystem.

The official MCP servers repository contains reference implementations that demonstrate how AI applications can interact with external tools and data sources.

The important concept isn't any individual server.

It's the standardization.

AI systems can connect to external capabilities through a common protocol rather than requiring a completely different integration approach every time.

I've explored this topic in detail in 5 MCP Servers That Changed How I Build AI Workflows:

https://dev.to/jaideepparashar/5-mcp-servers-that-changed-how-i-build-ai-workflows-16j6

If you're building AI workflows in 2026, I think MCP is worth understanding.

7. Unsloth

Repository: https://github.com/unslothai/unsloth

The last repository on my list takes us in a different direction.

Unsloth focuses on running and training AI models locally, including workflows around fine-tuning and open models.

This matters because not every AI builder wants to depend entirely on hosted APIs.

There are legitimate reasons to explore local models:

Privacy
Cost control
Experimentation
Customization
Offline development
Model fine-tuning

The open-model ecosystem is becoming increasingly important, and projects like Unsloth make experimentation considerably more accessible.

What I Look For Before Starring a Repository

I don't use GitHub stars as a popularity contest.

When I evaluate an AI repository, I usually ask:

Does it solve a real problem?
Is the architecture worth studying?
Is the project actively maintained?
Can I learn something from the code?
Could I actually use it in a project?

If the answer is yes to several of these questions, the repository gets my attention.

That's also why I don't believe you need hundreds of AI repositories in your bookmarks.

You need the right ones.

Don't Build Your AI Stack From GitHub Stars

There is a trap here.

You discover an impressive repository.

Then another.

Before you know it, you're running ten frameworks, six databases, four agent libraries, and three orchestration systems.

That's not an AI stack.

That's dependency collection.

I've written about this problem in The Hidden Cost of Using Too Many AI Tools:

https://dev.to/jaideepparashar/the-hidden-cost-of-using-too-many-ai-tools-poo

The objective isn't to use more technology.

It's to build better systems.

Final Thoughts

What I like about GitHub is that it gives us something AI hype often doesn't:

the opportunity to inspect the work.

You can read the code.

Study the architecture.

Look at the issues.

Examine pull requests.

Run the examples.

And decide for yourself whether something is actually useful.

That's how I prefer to learn AI.

Not just by reading what people say about a technology.

By opening the repository and seeing what developers are actually building.

These seven repositories are a good starting point.

But don't just star them.

Clone one. Read the code. Build something. Break it. Fix it.

That's where the real learning begins.

About the Author

Jaideep Parashar is the Founder & Director of ReThynk AI Innovation and Research Pvt. Ltd., Six Sigma Black Belt, Lean Expert, AI Strategist, researcher, author, and keynote speaker. Through Agentic Process Excellence™, he helps organizations combine Artificial Intelligence, Lean Six Sigma, and systems thinking to build reliable, scalable, and continuously improving business operations.

Why Context Engineering Is More Important Than Prompt Engineering

Jaideep Parashar — Fri, 07 Aug 2026 05:20:40 +0000

For the past few years, prompt engineering has been one of the hottest topics in AI.

Countless tutorials have promised the "perfect prompt."

Courses have been built around writing better prompts.

Developers have spent hours refining wording to squeeze better responses from large language models.

But after building AI systems across multiple projects, I think the conversation is changing.

Prompt engineering is still important.

However, I believe context engineering is becoming even more important.

The difference may sound subtle.

In practice, it changes how we design AI applications.

Prompts Tell AI What to Do

A prompt is simply an instruction.

For example:

Generate a FastAPI CRUD application.

That's a prompt.

A better version might be:

Generate a FastAPI CRUD application.

Requirements:

Python 3.12
SQLAlchemy
Pydantic v2
JWT Authentication
Unit Tests
Docker Support

The second prompt is more specific.

It reduces ambiguity.

That's exactly why prompt engineering became so valuable.

In fact, I previously wrote The Real Reason Prompt Engineering Isn't Going Away, where I explain why better prompts continue to improve AI systems even as language models become more capable.

But modern AI applications require much more than better prompts.

Context Gives AI the Information It Needs

Imagine asking an AI assistant:

Summarize our API documentation.

Without context, the model has no documentation.

Now imagine the workflow:

User Request
↓
API Documentation
↓
GitHub Repository
↓
Coding Standards
↓
Previous Conversations
↓
LLM
↓
Response

Nothing about the prompt changed dramatically.

What changed was the context.

And that often has a much greater impact on output quality.

Modern AI Applications Run on Context

Today's AI systems rarely depend on prompts alone.

Instead, they combine information from multiple sources:

Retrieved documents
Vector databases
APIs
Tool outputs
Conversation history
User preferences
System instructions
Business rules

The model reasons over all of this information before producing a response.

That's context engineering.

Think Like a Software Engineer

Developers rarely write software by placing all their logic inside a single function.

Instead, they organize:

Modules
APIs
Databases
Configuration
Services

AI systems benefit from the same thinking.

Instead of creating one enormous prompt, we should design systems that assemble the right context automatically.

The prompt becomes only one component of a larger architecture.

Retrieval Is Context Engineering

Retrieval-Augmented Generation (RAG) is a perfect example.

Without retrieval:

Question
↓
LLM
↓
Answer

With retrieval:

Question
↓
Vector Database
↓
Relevant Documents
↓
LLM
↓
Answer

The improvement doesn't come from rewriting the prompt.

It comes from supplying better information.

MCP Is Expanding the Idea Even Further

Model Context Protocol (MCP) pushes this concept beyond documents.

Instead of retrieving only stored knowledge, AI systems can access:

GitHub repositories
Databases
File systems
APIs
Development tools

That dramatically expands the available context.

If you're exploring this direction, I recommend reading 5 MCP Servers That Changed How I Build AI Workflows, where I share the MCP servers that have had the biggest impact on my own projects.

Organized Context Beats Random Conversations

One mistake I see frequently is treating AI chats as permanent knowledge storage.

Useful prompts disappear.

Examples are lost.

Architecture decisions become impossible to find.

That's why I maintain structured prompt libraries with documentation, categories, and version history.

The goal isn't simply to organise prompts.

It's to organise reusable context.

I explained my complete workflow in How I Organize 10,000+ Prompts Across Projects.

Context Makes Workflows More Reliable

One reason I emphasize workflows is that they naturally manage context.

A good workflow knows:

What information to retrieve
Which tools to call
What data to validate
What output to generate

The AI model isn't making random decisions.

It's operating inside a structured system.

That's one reason I believe workflows often create more reliable AI applications than jumping directly to autonomous agents.

I discussed this idea further in Why I Think Workflows Matter More Than Agents.

Businesses Need Context Too

This idea extends beyond software engineering.

Organizations often invest in AI before understanding their own processes.

Without operational context, AI has little foundation to build upon.

Business rules.

Approval flows.

Compliance requirements.

Documentation.

These are all forms of organizational context.

Before implementing AI at scale, it's worth assessing whether that context already exists.

I explored this in AI Process Assessment: 9 Signs Your Business Is Ready for AI.

My Perspective

I don't think prompt engineering is disappearing.

Far from it.

Prompt engineering remains one of the foundational skills for working with large language models.

But I think the industry's focus is expanding.

The question is no longer:

"How do I write a better prompt?"

It's becoming:

"How do I provide the right information at the right time?"

That's a much bigger challenge.

And it's also a much more interesting engineering problem.

Final Thoughts

The future of AI won't be determined by who writes the cleverest prompts.

It will be shaped by those who design systems that deliver the right context consistently.

Great prompts still matter.

But great context transforms AI from an impressive chatbot into a dependable software system.

As builders, our goal shouldn't be to create longer prompts.

It should be to create smarter systems that know what information an AI model needs, and when it needs it.

That's why I believe context engineering is becoming one of the most valuable skills in modern AI development.

About the Author:

Jaideep Parashar is the Founder & Director of ReThynk AI Innovation and Research Pvt. Ltd., AI Strategist, researcher, author, Six Sigma Black Belt, and Lean Expert. He writes about practical AI implementation, Agentic Process Excellence™, and building reliable AI systems that combine technical innovation with operational excellence.

Website: ReThynk AI

References:

Why I Think Workflows Matter More Than Agents

Jaideep Parashar — Fri, 31 Jul 2026 05:36:16 +0000

If you've spent any time in the AI community recently, you've probably noticed one trend.

Everything is becoming an AI agent.

Need to summarize documents?

"Build an agent."

Need customer support?

"Use multiple agents."

Need a coding assistant?

"Deploy an autonomous agent with memory, tools, planning, and self-reflection."

Agents are exciting, and they absolutely have their place.

But after building AI applications and experimenting with different architectures, I've reached a different conclusion.

I think workflows matter more than agents.

That doesn't mean agents are bad.

It means I believe too many builders start by asking, "How can I build an agent?" instead of asking, "What's the simplest workflow that solves this problem?"

That single change in thinking has improved the way I design AI systems.

Workflows Solve Problems. Agents Execute Them.

Imagine you're building an AI-powered support system.

A workflow might look like this:

User Question
↓
Retrieve Knowledge
↓
Generate Response
↓
Validate Output
↓
Send Reply

Everything is predictable.

Each step has a clear purpose.

Now compare that with a system where an autonomous agent decides:

Which tools to use
Which documents to search
Whether to call another agent
Whether to retry
Whether to re-plan

Sometimes that's exactly what's needed.

But sometimes you've introduced far more complexity than the problem requires.

Complexity Has a Cost

Every additional layer in an AI system introduces new challenges.

More prompts
More APIs
More debugging
More monitoring
More failure points

A workflow with five deterministic steps is often easier to understand than an autonomous system making dozens of decisions behind the scenes.

That's one reason I previously wrote Why I Think Most AI Agents Are Overengineered, where I discuss how many projects adopt autonomous architectures long before they've demonstrated the need for them.

For many applications, simplicity isn't a limitation.

It's an advantage.

Predictability Beats Cleverness

One of the biggest benefits of workflows is predictability.

When something goes wrong, you know exactly where to look.

Was retrieval incorrect?
Did the prompt fail?
Did the API return an error?
Did validation reject the response?

Each stage can be tested independently.

With highly autonomous agents, tracing failures often becomes much harder because decision-making is distributed across multiple planning steps.

As systems grow, observability becomes just as important as intelligence.

Good Workflows Scale Better

I've learned that scaling isn't only about handling more users.

It's also about maintaining systems over time.

A clear workflow makes it easier to:

Add new features
Replace models
Update prompts
Improve evaluation
Introduce governance

Because each component has a defined responsibility.

That's much harder when responsibilities are spread across multiple autonomous agents.

Integration Matters More Than Autonomy

One lesson that has consistently shaped my AI stack is this:

Connected systems create more value than isolated intelligence.

A workflow that integrates GitHub, APIs, databases, and language models often delivers more business value than a sophisticated agent working in isolation.

That's one reason I've invested time in Model Context Protocol (MCP). Standardized integrations reduce friction and allow workflows to interact with external systems in a reliable way.

If you're exploring this approach, 5 MCP Servers That Changed How I Build AI Workflows covers the MCP servers that have had the biggest impact on my own projects.

The Best AI Stack Supports Workflows

When I look at my own development environment, I don't think about individual tools.

I think about how they work together.

ChatGPT.
Cursor.
FastAPI.
GitHub.
MCP.
Python.

Each tool has one clear responsibility within a larger workflow.

I described this philosophy in My Personal AI Stack in 2026, where I explain why I choose tools based on integration rather than popularity.

The stack exists to support the workflow—not the other way around.

Businesses Don't Need Agents First

One mistake I see organizations make is assuming that AI success starts with deploying agents.

In reality, it usually starts much earlier.

With understanding the process.

If the underlying workflow is inefficient, autonomous agents often automate inefficiency instead of eliminating it.

That's why I believe organizations should evaluate their operational readiness before investing heavily in advanced AI architectures.

I explored this in AI Process Assessment: 9 Signs Your Business Is Ready for AI, which provides practical indicators for assessing whether a business is prepared for AI adoption.

Similarly, Why You Should Fix Your Process Before Implementing AI explains why improving the process itself often delivers greater returns than introducing new AI technologies.

When Do Agents Make Sense?

This isn't an argument against agents.

There are many scenarios where they're the right choice.

For example:

Multi-step research
Dynamic task planning
Software engineering assistants
Long-running automation
Complex orchestration across multiple tools

But I treat agents as an optimization.

Not a starting point.

I first ask:

Can a workflow solve this?
Can it remain deterministic?
Can it be monitored easily?
Can another developer maintain it?

Only when the answer becomes "no" do I consider adding autonomous behavior.

Final Thoughts

AI agents will continue to improve.

Planning will become better.

Reasoning will become stronger.

Frameworks will become easier to use.

But I don't think the future belongs to the most autonomous systems.

I think it belongs to the teams that design the best workflows.

Because workflows create clarity.

Clarity creates reliability.

And reliable systems create real business value.

Before building another agent, it may be worth asking a simpler question:

Could a well-designed workflow solve this just as effectively?

About the Author:

Website: ReThynk AI

References:

10 Python Libraries Every AI Builder Should Know

Jaideep Parashar — Fri, 24 Jul 2026 05:01:26 +0000

If you're building AI applications in 2026, choosing the right Python libraries can save you hundreds of hours of development time.

The Python ecosystem has grown rapidly over the past few years. Every week, new frameworks promise to simplify AI development, but not every library deserves a place in your toolkit.

After building AI workflows, experimenting with different architectures, and integrating multiple AI services, I've found myself returning to the same set of libraries again and again.

These aren't necessarily the newest libraries.

They're the ones that consistently help me build reliable AI applications faster.

1. FastAPI

If I could recommend only one backend framework for AI applications, it would be FastAPI.

It provides:

High performance
Automatic API documentation
Type validation
Asynchronous support
Clean architecture

Whether you're exposing LLM endpoints, building AI agents, or creating internal APIs, FastAPI makes deployment straightforward.

It's the backbone of most of my AI projects.

2. LangChain

LangChain remains one of the most popular frameworks for developing LLM-powered applications.

It's particularly useful for:

Prompt templates
Tool integration
Retrieval-Augmented Generation (RAG)
Memory
Multi-step workflows

Although I don't use every feature it offers, it's still an excellent starting point for many AI applications.

3. Pydantic

Many developers think of Pydantic as just a validation library.

I think it's much more than that.

When AI applications exchange structured data between models, APIs, databases, and services, validation becomes essential.

Pydantic keeps those interactions predictable and significantly reduces runtime errors.

4. OpenAI SDK

Regardless of which models you use, understanding the official SDK is valuable.

It simplifies:

Chat completions
Streaming responses
Function calling
Structured outputs
Embeddings

Rather than building everything from raw HTTP requests, the SDK provides a clean developer experience.

5. ChromaDB

Almost every modern AI application eventually needs semantic search.

That's where vector databases become important.

ChromaDB offers a lightweight solution that's easy to integrate while learning concepts like:

Embeddings
Similarity search
Context retrieval
Retrieval-Augmented Generation (RAG)

For prototypes and many production use cases, it's an excellent starting point.

6. Pandas

AI isn't only about language models.

Many projects still require significant data preparation before an LLM becomes useful.

Pandas remains one of the best tools for:

Cleaning datasets
Data transformation
Feature preparation
CSV processing
Exploratory analysis

A good AI workflow almost always begins with good data.

7. NumPy

Underneath many AI libraries sits NumPy.

Even if you rarely interact with it directly, understanding arrays and numerical computation makes debugging and optimization much easier.

It's one of those foundational libraries every AI developer benefits from learning.

8. SQLAlchemy

Most AI applications eventually need persistence.

Whether you're storing conversations, prompts, user profiles, or evaluation results, SQLAlchemy provides a reliable way to interact with relational databases.

Keeping business logic separate from database logic makes AI systems easier to maintain as they grow.

9. Requests

Simple.

Reliable.

Still essential.

Despite the availability of specialized SDKs, I regularly use Requests for:

REST APIs
Webhooks
Third-party integrations
Internal microservices

Almost every AI workflow communicates with another service at some point.

Requests continues to be one of the easiest ways to make that happen.

10. Rich

Not every AI application needs a graphical interface.

Many run entirely from the terminal.

Rich makes command-line applications dramatically easier to use by adding:

Beautiful tables
Progress bars
Syntax highlighting
Status indicators
Better logging

For developer tools, it's one of my favorite quality-of-life libraries.

Libraries Matter Less Than Systems

Whenever someone asks me which Python library is the "best," my answer is usually the same.

The best library is the one that fits your workflow.

A stack filled with impressive frameworks won't help if the overall architecture becomes unnecessarily complex.

That's one reason I deliberately keep my own toolkit focused. In My Personal AI Stack in 2026, I explain how I choose tools based on workflow integration rather than popularity.

Similarly, I've learned that adding more libraries or AI tools doesn't automatically increase productivity. In The Hidden Cost of Using Too Many AI Tools, I discuss why simplifying your stack often leads to better long-term results.

Open Source Is One of the Greatest Advantages of AI Development

Many of the libraries in this article thrive because of active open-source communities.

Learning how these projects are built can teach you just as much as using them.

If you're looking for high-quality repositories to explore, I previously shared 7 GitHub Repositories I Recommend to Every AI Builder, featuring projects that have influenced the way I build AI applications.

Technology Alone Doesn't Guarantee Better AI

As AI projects mature, technical decisions become only one part of success.

Process design, governance, and organizational readiness become equally important.

Before scaling an AI initiative, it's worth asking whether the underlying business processes are actually ready. I explored that idea in AI Process Assessment: 9 Signs Your Business Is Ready for AI.

As AI systems become more integrated into business operations, governance also becomes essential. AI Governance Framework: A Practical Guide for Responsible AI Implementation outlines practical principles for building AI systems that are secure, compliant, and trustworthy.

Technology helps you build AI.

Good processes and governance help you build AI that lasts.

Final Thoughts

Python continues to be the language at the heart of modern AI development.

New libraries will emerge.

Existing ones will evolve.

Some will disappear.

But the goal isn't to learn every library.

It's to understand the role each one plays within a well-designed system.

The most effective AI builders aren't those with the largest toolbox.

They're the ones who know exactly when—and why—to use each tool.

About the Author:

Jaideep Parashar is the Founder & Director of ReThynk AI Innovation and Research Pvt. Ltd., a Six Sigma Black Belt, Lean Expert, AI Strategist, researcher, author, and keynote speaker. His work focuses on helping organizations combine Artificial Intelligence, Lean Six Sigma, and systems thinking through the discipline of Agentic Process Excellence™ to build reliable, scalable, and continuously improving business operations.

Reference:

My Personal AI Stack in 2026

Jaideep Parashar — Fri, 17 Jul 2026 09:48:36 +0000

Ask ten AI developers what tools they use, and you'll probably get ten different answers.

The AI ecosystem is evolving so quickly that it's easy to believe you need every new framework, model, and application to stay productive.

I don't think that's true.

Over the past year, I've experimented with dozens of AI tools while building products, writing technical content, managing prompt libraries, and developing AI workflows. Along the way, my stack has become surprisingly simple.

It's not built around the "best" tools.

It's built around the tools that work well together.

Here's the AI stack I rely on in 2026 and, more importantly, why each tool has earned its place.

1. ChatGPT: My Primary Thinking Partner

ChatGPT is where most of my work begins.

Not because it can do everything, but because it helps me think faster.

I use it for:

Brainstorming ideas
Structuring articles
Reviewing technical concepts
Exploring architectural trade-offs
Refining prompts
Research assistance

I rarely expect the first response to be perfect.

Instead, I treat it like collaborating with a knowledgeable teammate who accelerates my thinking.

2. Cursor: My AI-Powered Development Environment

When it's time to write code, I move into Cursor.

Its strength isn't just code generation.

It's understanding the context of an entire project.

Whether I'm building a FastAPI backend, integrating APIs, or refactoring an existing codebase, having AI directly inside the editor removes a huge amount of friction.

The less I switch between applications, the more productive I become.

In fact, one of the biggest lessons I've learned is that adding more AI tools doesn't automatically improve productivity. Sometimes it has the opposite effect. I explored this idea in The Hidden Cost of Using Too Many AI Tools, where I explain why a smaller, well-integrated stack often outperforms a collection of disconnected applications.

3. GitHub: The Source of Truth

Every project eventually ends up in GitHub.

Not just source code.

I also version:

Prompt templates
Documentation
API specifications
Experiment notes
Workflow diagrams

Treating AI assets like software assets has made collaboration and maintenance much easier.

GitHub isn't simply where my code lives.

It's where my AI knowledge evolves.

If you're building AI applications, I also recommend exploring several open-source repositories that have significantly improved my own workflow. I shared my favorites in 7 GitHub Repositories I Recommend to Every AI Builder.

4. MCP: Connecting Everything Together

The biggest change in my stack this year hasn't been a new language model.

It's been adopting Model Context Protocol (MCP).

Instead of manually copying information between applications, MCP allows AI systems to interact with repositories, documentation, databases, and external services through standardized interfaces.

Rather than thinking about individual AI tools, I now think about connected workflows.

That shift has been far more valuable than upgrading from one model to another.

If you're curious about practical implementations, I recently shared 5 MCP Servers That Changed How I Build AI Workflows, covering the MCP servers that have had the greatest impact on my projects.

5. A Structured Prompt Library

One of the least exciting parts of my stack is also one of the most valuable.

A structured prompt library.

Every useful prompt eventually becomes a reusable asset.

Instead of leaving prompts buried inside chat history, I organize them into categorized libraries that can be searched, refined, and reused across projects.

This has dramatically reduced duplicated work and improved consistency.

I shared the complete system in How I Organize 10,000+ Prompts Across Projects, including the principles I use to manage large prompt collections effectively.

6. FastAPI: The Backbone of My AI Applications

Whenever I need to expose AI capabilities through APIs, FastAPI is my preferred framework.

It provides:

Excellent performance
Automatic API documentation
Type validation
Clean architecture
Easy integration with AI services

Most AI applications eventually need reliable APIs.

FastAPI has consistently delivered that reliability.

7. Simple Workflows Over Complex Architectures

One trend I've intentionally avoided is building overly complicated AI systems.

Multiple agents.
Multiple orchestration frameworks.
Multiple reasoning layers.
Sometimes they're necessary.
Often they aren't.

I've found that a simple workflow that's easy to understand, maintain, and debug usually delivers more value than an impressive architecture that's difficult to operate.

Technology should reduce complexity.

Not introduce it.

My AI Stack Isn't Fixed

One thing people often ask is:

"What's the best AI stack?"

There isn't one.

My stack changes every few months.

Tools evolve.

Models improve.

New standards emerge.

What doesn't change is the philosophy behind it.

Every tool has to earn its place.

If it creates unnecessary complexity, overlaps with another tool, or doesn't improve my workflow, it doesn't stay.

The Principle That Guides Every Tool Choice

Over the past year, I've realized something important.

Successful AI builders don't optimize for the number of tools they use.

They optimize for the quality of the system they build.

That's also true at the organizational level.

Before investing in new AI platforms, businesses should first understand whether their processes are actually ready for AI adoption. I discussed this in AI Process Assessment: 9 Signs Your Business Is Ready for AI, which outlines practical indicators that help organizations evaluate their readiness before implementing AI.

Because the best AI stack isn't the one with the most tools.

It's the one that helps you deliver consistent results with the least unnecessary complexity.

Articles Reference:

The Hidden Cost of Using Too Many AI Tools

Jaideep Parashar — Fri, 10 Jul 2026 05:35:57 +0000

Every week, a new AI tool goes viral.

"This changes everything."

"The best AI coding assistant."

"The ultimate AI agent."

"The next ChatGPT killer."

As developers and AI builders, it's tempting to install every new tool that appears on GitHub or Product Hunt.

I've done exactly that.

But after building AI systems across multiple projects and experimenting with dozens of AI tools, I realized something unexpected.

The biggest productivity problem isn't having too few AI tools.

It's having too many.

The hidden cost isn't the subscription fee.

It's the complexity you introduce into your workflow.

More Tools Don't Always Mean More Productivity

Consider a typical AI workflow.

Research → ChatGPT

Coding → Cursor

Documentation → Claude

Automation → n8n

Images → Midjourney

Version Control → GitHub

None of these tools are bad.

In fact, they're excellent.

The problem appears when every task requires switching applications, changing context, and remembering different workflows.

Every tool has:

Different shortcuts
Different prompt styles
Different capabilities
Different limitations

Those small interruptions add up.

The result is fragmented attention instead of deep work.

Every New Tool Has a Hidden Learning Cost

Installing a new AI application takes minutes.

Learning to use it effectively takes much longer.

For every new platform you need to understand:

Configuration
Prompt behavior
Strengths
Weaknesses
Integrations
Best use cases

Now imagine doing that for fifteen different AI tools.

Eventually you're spending more time learning software than solving problems.

I've learned that mastering a small number of tools often creates far more value than constantly chasing new ones.

Build a Workflow, Not a Tool Collection

One mistake I see frequently is people comparing AI tools only by features.

Questions like:

Which model is fastest?
Which has the largest context window?
Which writes better code?

Those questions matter.

But I think a more important question is:

Does this tool improve my workflow?

A slightly less capable tool that integrates perfectly into your development process is often more valuable than a cutting-edge model that creates friction every day.

Integration Is Becoming More Important Than Features

Modern AI isn't just about language models.

It's about connected systems.

For example:

GitHub
↓
MCP Server
↓
LLM
↓
FastAPI
↓
Deployment

Instead of constantly copying information between applications, AI can interact directly with repositories, databases, APIs, and development environments.

That's one reason I've become increasingly interested in Model Context Protocol (MCP).

If you're exploring MCP, I recently shared 5 MCP Servers That Changed How I Build AI Workflows, covering the servers that have had the biggest impact on my own development process.

Your Prompt Library Shouldn't Live Inside Chat History

Another hidden cost of using too many AI tools is prompt duplication.

The same prompt ends up living in:

ChatGPT
Claude
Cursor
Notes
Random Markdown files

Soon you don't know which version is current.

That's why I stopped treating prompts as conversations.

I started treating them as reusable software assets.

Today I maintain structured prompt libraries with documentation, version history, and categories.

I explained the complete system in How I Organize 10,000+ Prompts Across Projects, where I share the workflow I use to manage large prompt libraries across multiple AI initiatives.

Complexity Grows Faster Than You Expect

Let's compare two architectures.

Workflow A

LLM
↓
FastAPI
↓
GitHub
↓
Deployment

Workflow B

Three LLMs
↓
Four AI Agents
↓
Five MCP Servers
↓
Vector Database
↓
Automation Platform
↓
Monitoring
↓
Deployment

The second system isn't automatically better.

It simply has more moving parts.

Every additional dependency introduces:

Configuration
Maintenance
Updates
Monitoring
Debugging

Complexity should solve a problem.

Not become one.

That's one reason I previously argued in Why I Think Most AI Agents Are Overengineered that many builders introduce autonomous agents before proving they actually need them.

Process Comes Before Platform

One lesson has repeated itself across almost every AI project I've worked on.

Organizations spend weeks comparing AI tools.

But they spend very little time improving the underlying workflow.

That's backwards.

The process should determine the technology.

Not the other way around.

I've seen companies purchase expensive AI platforms while leaving inefficient business processes untouched.

Predictably, the results fall short of expectations.

I explored this in more detail in Why You Should Fix Your Process Before Implementing AI, where I explain why process improvement should happen before AI implementation.

If you're interested in taking that idea even further, How Lean Six Sigma AI Create Better Business Processes explores how structured improvement methodologies can strengthen AI initiatives rather than simply automate existing inefficiencies.

My Rule for Adopting a New AI Tool

Before adding any new AI application to my workflow, I ask four simple questions.

Does it solve a real problem?
Can an existing tool already do this?
Will it simplify my workflow?
Will I still be using it six months from now?

If the answer is mostly "no," I don't install it.

Missing the latest trend is usually less expensive than managing unnecessary complexity.

Final Thoughts

The AI ecosystem will continue to grow.

New models will appear.

New frameworks will launch.

New startups will promise revolutionary productivity.

That's exciting.

But I've learned that productivity doesn't come from using the most AI tools.

It comes from building the right AI system.

The builders who create lasting value won't be the ones trying every new release.

They'll be the ones who understand their workflows, organize their knowledge, and choose tools intentionally.

Sometimes the smartest productivity improvement isn't adding another AI tool.

It's removing one.

Articles Reference:

Graphics Credit: Graphics designed by Vista Liberata | visit here

What I Learned After Building AI Systems Across Multiple Brands

Jaideep Parashar — Mon, 06 Jul 2026 09:20:03 +0000

One of the biggest misconceptions about AI is that every project is unique.

At first glance, it certainly feels that way.

One project is a chatbot.

Another is an AI-powered search system.

Another automates documentation.

Another generates code.

But after building AI systems across multiple brands and initiatives, I started noticing something surprising.

The technology changes.

The business domain changes.

The users change.

The underlying principles rarely do.

Here are some of the biggest lessons I've learned.

1. AI Doesn't Fix Broken Systems

Many teams believe AI will solve operational problems.

In reality, AI usually exposes them.

If documentation is inconsistent, AI becomes inconsistent.

If data is outdated, AI produces outdated answers.

If workflows are unclear, automation becomes unreliable.

One of the biggest lessons I've learned is this:

AI amplifies the quality of your existing systems.

It rarely compensates for poor foundations.

That's why I spend far more time understanding processes than choosing models.

2. Simplicity Beats Complexity

Every new AI framework looks exciting.

Agents.

Memory.

Planning.

Reflection.

Tool calling.

Multi-agent orchestration.

I've experimented with many of these approaches, but one principle keeps proving itself.

The simplest solution that solves the problem is usually the best solution.

A straightforward workflow is often easier to:

Build
Test
Maintain
Scale
Explain

Complexity should be introduced only when it delivers clear value.

3. Prompt Libraries Are More Valuable Than Individual Prompts

When I first started using AI, I wrote prompts from scratch.

Eventually I realized I was solving the same problems repeatedly.

Now I build prompt libraries.

Instead of creating new prompts every day, I improve existing ones.

This creates consistency across projects.

If you're interested in how I manage this, I recently shared the system I use to organize more than 10,000 prompts across different projects.

The shift from individual prompts to reusable prompt assets has had a much bigger impact than switching between AI models.

4. Workflows Matter More Than Models

Every few months a new model becomes available.

Larger context windows.

Lower latency.

Better reasoning.

Those improvements are exciting.

But in production systems, I rarely see the model as the primary challenge.

The bigger questions are:

Where does data come from?
What happens after generation?
How are errors handled?
Which tools should AI call?
What should happen if a request fails?

These workflow decisions usually have a greater impact on reliability than changing models.

5. Context Is the Real Product

People often ask:

"Which AI model should we use?"

I usually ask a different question.

"What information does the model need to succeed?"

Consider this coding request:

Write a Python authentication API.

Now compare it with:

Build a FastAPI authentication service.

Requirements:

Python 3.12
JWT authentication
SQLAlchemy
Pydantic v2
Password hashing with bcrypt
Refresh tokens
Unit tests
Docker support

Same model.

Different context.

Much better output.

The difference isn't intelligence.

It's information.

6. AI Adoption Is Mostly a Human Challenge

Technology is rarely the biggest obstacle.

People are.

Successful AI projects require:

Clear communication
Shared expectations
Good documentation
Process discipline
Continuous improvement

Without these, even the most advanced AI systems struggle to deliver long-term value.

7. Documentation Is a Competitive Advantage

Every AI project generates knowledge.

Prompt patterns.

Architecture decisions.

API conventions.

Lessons learned.

Common failures.

If that knowledge isn't documented, teams repeat the same mistakes.

I've found that good documentation often improves AI projects more than adding another framework.

Knowledge compounds.

Only if it's captured.

8. Every AI Project Becomes a Software Project

Many AI prototypes begin with a single prompt.

But successful ones quickly evolve into software.

Soon you need:

APIs
Authentication
Logging
Monitoring
Testing
Version control
Deployment pipelines

At that point, software engineering practices become just as important as prompt engineering.

Treating AI applications like production software changes how you build them.

9. Continuous Improvement Beats Perfect Design

I've stopped trying to design perfect AI systems on day one.

Instead, I focus on continuous improvement.

Build.

Measure.

Learn.

Improve.

Small iterations consistently outperform large redesigns.

This mindset has made AI projects far more sustainable.

My Biggest Takeaway

Across every brand and every AI initiative, one lesson keeps repeating itself.

Success rarely comes from having the newest model.

It comes from building reliable systems around the model.

Models will continue to improve.

Frameworks will continue to evolve.

New tools will appear every month.

Strong systems remain valuable regardless of which model powers them.

That's where I now spend most of my attention.

Final Thoughts

Building AI systems across multiple projects has changed the way I think about artificial intelligence.

I no longer see AI as a collection of prompts or models.

I see it as a system made up of people, processes, data, workflows, and software.

The model is important.

But it's only one piece of the puzzle.

The builders who create lasting value won't necessarily be the ones using the newest AI model.

They'll be the ones designing the most reliable systems around it.

And I believe that's where the next generation of AI innovation will come from.