DEV Community: Jaideep Parashar

10 AI Terms Every Developer Should Know to Build Better Systems

Jaideep Parashar — Fri, 06 Nov 2026 16:27:19 +0000

In my last speech, I wanted the audience to leave with something they could use beyond a particular AI tool.

So I focused on how to think with AI.

While building ReThynk AI, one lesson has become central to my thinking: start with the problem. Understand what needs to happen, who needs it, and how you will know whether your solution works.

Technical knowledge becomes valuable when it helps us answer those questions.

That is why I want developers to understand these ten terms. Each gives you a way to examine your application, identify a weakness, and make a better decision.

Let us connect them through one example: building an AI customer-support assistant.

1. Context window

The context window is the amount of information a model can work with during a response, measured in tokens. Its capacity must accommodate the relevant input and generated output, subject to the model’s limits. It is different from permanent memory.

Imagine your support assistant needs the customer’s question, conversation history, and refund policy. Those compete for space alongside instructions and tool results.

A larger window gives you more room. You still need to decide what deserves that room.

2. Context engineering

Context engineering means selecting, organizing, and maintaining the information available to the model as it works. This includes instructions, documents, conversation history, and tool results.

For our assistant, loading every policy document could introduce outdated or irrelevant information. Selecting the current policy for the customer’s region gives it a more useful starting point.

My question here is simple: Have I given the system what it needs to make this particular decision?

3. Embeddings

Embeddings represent information as numerical vectors. Suitable embedding models allow us to compare text by semantic similarity, which is useful for search, clustering, and retrieval.

A customer writes, “My parcel never arrived.” Your documentation calls this a “missing delivery.” Embedding-based search can help connect the two despite their different wording.

However, a similar document can still be the wrong document. You must also consider details such as product, region, and policy date.

4. Retrieval-augmented generation, or RAG

RAG retrieves relevant information and supplies it to a model to help generate an answer. It connects generation with external sources such as documents or databases.

Our assistant could retrieve a delivery policy before explaining the available options.

That sounds straightforward, but there are two questions to investigate: did retrieval find the right information, and did the model use it correctly?

Connecting a document store is the beginning of that work.

5. Tool calling

Tool calling allows a model to request an external function using structured arguments. For custom functions, your application executes the function and returns its result to the model.

For example, the assistant might request:

get_order_status(order_id="12345")

Your application must check whether the customer can access that order before executing the request.

The model can propose an action. Your software remains responsible for enforcing permissions and validating inputs.

6. Workflows and agents

In Anthropic’s architectural distinction, workflows follow predefined code paths, while agents dynamically direct their processes and tool use. Different products may use these labels differently, so the underlying behavior matters.

A support workflow might always check the order, retrieve the policy, and draft a response.

An agent might decide which investigation to perform next based on what it discovers.

When building, I would ask how much flexibility the problem requires. A predictable process can be easier to inspect, test, and maintain.

7. Model Context Protocol, or MCP

MCP standardizes how AI applications connect with capabilities exposed by servers, including tools, resources, and prompts. Its architecture separates the host application, clients, and servers.

For our support assistant, an MCP server could expose order-search tools or policy resources.

This helps define the connection. You still need to design access controls, tool behavior, and error handling.

Understanding the protocol should help you build clearer interfaces between your AI application and the systems it uses.

8. Evaluations, or evals

Evaluations are structured checks of how a system performs on representative tasks. For a RAG application, useful dimensions include correctness, relevance, completeness, and whether the response is supported by its supplied context.

Our assistant needs test cases for missing deliveries, conflicting policies, unavailable order data, and questions it cannot answer.

My Six Sigma background makes this especially meaningful to me. Before improving a process, we need a clear definition of acceptable performance.

A convincing demonstration gives us something to investigate. Evaluation gives us evidence across cases.

9. Observability

Observability helps us understand a system’s behavior through telemetry such as traces, metrics, and logs. A trace can follow a request through multiple operations.

Suppose our assistant gives a poor answer after taking fifteen seconds. We need to discover where the time went, which documents were retrieved, and whether a tool failed.

For AI applications, I would track the relevant retrieval, model, and tool steps while protecting sensitive customer information.

We can improve more effectively when we can locate the failure.

10. Idempotency

An idempotent operation can be repeated without producing additional effects beyond the intended first operation. This matters when requests are retried after timeouts or interrupted connections.

Imagine a refund succeeds, but the response never reaches the assistant. It retries.

The system should recognize the same logical refund request and avoid issuing another payment. Implementing that requires coordination with the service performing the action.

A retry is a small technical detail until it changes someone’s account balance.

These concepts belong together.

Context engineering determines what the model sees. Retrieval supplies information. Tools connect it to actions. Workflows or agents coordinate the work. Evaluations check performance, observability helps explain behavior, and idempotency helps make retries safe.

When I speak about thinking with AI, this is part of what I mean: understanding enough of the whole system to ask better questions.

Choose one AI project you are building. Trace a single user request through it.

Where could it retrieve the wrong information, take an unauthorized action, or repeat an operation?

Share the term you want me to explore next, and the problem you are trying to solve with it.

Why developers need room to experiment, learn, and build without turning every idea into a business

Jaideep Parashar — Fri, 30 Oct 2026 06:47:41 +0000

Imagine spending your weekend building something interesting.

Maybe a small weather application.

A tool that organizes your photographs.

A website that recreates the interface of an old computer.

Or a simple Python script that solves a problem nobody else seems to care about.

You spend hours experimenting.

Something breaks.

You fix it.

You learn something new.

And finally, the project works.

You're happy.

Then someone asks:

"That's interesting. How are you planning to monetize it?"

And suddenly, a perfectly enjoyable weekend project becomes a business discussion.

What's the target market?

What's the revenue model?

How will you acquire users?

Can you scale it?

Is there an investor opportunity?

I understand these questions. I'm a founder myself.

But I've been thinking about something lately.

Why does everything we build need to become something we sell?

We Have Turned Building Into a Business Competition

There was a time when building software was also a way to explore technology.

You learned HTML because you wanted to create a website.

You experimented with Python because you were curious about automation.

You built a game because you enjoyed playing games.

You created a small tool because something bothered you and you wanted to fix it.

Not every project needed customers.

Not every experiment needed a market.

Not every repository needed thousands of stars.

Sometimes, the project existed for one reason.

You wanted to see whether you could build it.

But the conversation around software development has changed.

Today, we frequently hear:

Build in public.

Launch an MVP.

Find paying users.

Create recurring revenue.

Turn your skills into a business.

There's nothing wrong with any of these ideas.

In fact, I believe they're valuable when you're intentionally building a company.

The problem begins when we start applying the same expectations to every experiment.

A Side Project Has a Different Job

A startup exists to create value for customers through a sustainable business.

A side project doesn't necessarily have that responsibility.

It might exist to help you learn.

To explore an unfamiliar technology.

To understand how something works.

To test an unusual idea.

Or simply to enjoy the process of creating something.

Consider someone building a tiny operating system as a learning exercise.

It probably won't compete with Linux or Windows.

Does that mean the project has failed?

Of course not.

The developer might learn more about memory management, process scheduling, and hardware than they would from months of watching tutorials.

Or consider someone building a small application that visualizes sorting algorithms.

There are already hundreds of similar tools.

From a business perspective, the idea might appear unoriginal.

From a learning perspective, it could be incredibly valuable.

A project's value isn't always measured by how many people will pay for it.

Sometimes its value is what it teaches the person building it.

AI Has Made This Pressure Even More Interesting

AI has reduced many of the barriers to creating software.

You can prototype an idea faster.

Generate boilerplate.

Explore unfamiliar frameworks.

Build interfaces.

Experiment with APIs.

That's wonderful.

But there's a strange consequence.

Because building has become easier, the pressure to produce something commercially useful can become even greater.

Why build a small experiment when you could launch an application?

Why learn a framework when you could create a SaaS product?

Why spend time exploring an idea when you could turn it into a business?

I think this misses something important.

Just because technology makes an opportunity possible doesn't mean we have to pursue it.

We should be able to experiment without having to justify every hour through a potential financial return.

Otherwise, curiosity slowly turns into another performance target.

Sometimes the Most Interesting Projects Are Completely Impractical

Think about the projects developers enjoy sharing.

Someone creates a programming language for fun.

Someone builds a robot that performs a ridiculous task.

Someone turns a terminal into a game.

Someone recreates an old interface.

Someone connects a sensor to a Raspberry Pi just to understand how it works.

These projects may not solve enormous business problems.

But they can be fascinating.

They encourage experimentation.

They teach unexpected lessons.

And sometimes they inspire other developers to try something new.

Not everything useful has to begin with a commercial purpose.

In fact, some of the most interesting ideas emerge when people are free to experiment without knowing exactly where the results will lead.

That's one reason I don't want us to lose the culture of building things simply because they seem interesting.

I Believe in Distribution. But Not Everything Needs Distribution.

This is where my perspective as a founder becomes important.

I've written before about how developers can build global influence without working at Big Tech.

I believe in sharing knowledge.

I believe in building relationships.

I believe developers should understand how to reach people with their work.

And when you're building a company, distribution is absolutely essential.

A product that nobody discovers will struggle, regardless of its technical quality.

But here's an important distinction.

A project you build for learning is not the same as a product you're building for customers.

The first doesn't need a marketing strategy.

The second probably does.

The first can succeed even if only one person uses it.

The second needs a sustainable reason to exist in the market.

Both are legitimate.

The mistake is pretending they're the same thing.

The Hidden Cost of Monetizing Every Idea

Turning an experiment into a business changes your responsibilities.

Suppose you build a small application over the weekend.

You enjoy the process.

You share it with a few friends.

Everything is simple.

Now imagine deciding to commercialize it.

Suddenly, you may need:

customer support and documentation
billing and payment systems
security and privacy considerations
reliable hosting and monitoring
maintenance and updates
marketing and customer acquisition
financial and operational planning

None of these responsibilities are inherently bad.

They're part of building a real product.

But they can fundamentally change your relationship with the project.

Something that previously gave you creative freedom can become another obligation.

And sometimes, the financial opportunity isn't large enough to justify everything that comes with it.

A side project can be successful precisely because it remains a side project.

We Shouldn't Confuse Learning With Wasted Time

Imagine a developer spending two weeks creating a small game.

They don't sell it.

They don't launch a startup.

They don't gain a large audience.

But they learn about state management, event handling, rendering, and application architecture.

Was that time wasted?

I don't think so.

The project might make them a better developer.

It might introduce them to a new field.

It might help them discover something they genuinely enjoy.

And that learning could become valuable years later in a completely different context.

Not every return on effort is immediate.

Not every useful skill can be assigned a price.

Sometimes the most valuable outcome is that you understand something today that you didn't understand yesterday.

There's Nothing Wrong With Wanting to Build a Business

I don't want this article to sound anti-startup.

Quite the opposite.

Building a business is one of the most challenging and rewarding things someone can attempt.

I know that entrepreneurship requires discipline, patience, judgment, and an enormous amount of work that happens outside the technical product.

If your intention is to create a business, you should think about customers, distribution, pricing, competition, and financial sustainability.

You should validate demand.

You should understand the market.

You should ask whether the problem is valuable enough for someone to pay to solve it.

But you don't need to apply that process to every interesting idea.

I wrote in I Think Developers Are Building Too Much Software about the importance of knowing what deserves to be built.

There's another side to that argument.

Sometimes something deserves to be built even when it has no commercial value.

Because the purpose might be learning, creativity, or enjoyment.

And those are perfectly valid reasons.

Maybe We Need Two Different Definitions of Success

For commercial products, success might mean:

Are customers using it?

Does it solve a valuable problem?

Will people pay for it?

Can the business sustain itself?

For personal projects, the questions can be different.

Did I learn something?

Did I solve an interesting challenge?

Did I enjoy building it?

Would I like to explore this technology further?

Did it make me a better thinker or developer?

We need both kinds of work in the technology community.

Commercial projects create economic opportunities.

Personal experiments create space for curiosity and discovery.

And occasionally, something built purely out of curiosity becomes a useful product.

That's wonderful when it happens.

But it doesn't need to be the expectation.

My Advice to Developers: Keep Something Just for Yourself

If you're a developer, I would encourage you to have at least one project that doesn't need to prove anything to anyone.

No business model.

No growth target.

No investor pitch.

No pressure to make it viral.

Build something because you find it fascinating.

Experiment with a language you've never used.

Recreate something from your childhood.

Build a useless little tool that makes you smile.

Explore a difficult algorithm.

Try combining two technologies that don't normally belong together.

You might discover something useful.

You might build something terrible.

You might abandon the project halfway through.

That's fine.

Not every experiment needs to become a success story.

Sometimes the freedom to fail without financial consequences is exactly what makes experimentation worthwhile.

The Best Part of Building Might Be the Building Itself

I spend a lot of time thinking about technology, business, and the future of AI.

I believe technology should solve meaningful problems.

I believe founders should think seriously about distribution and customer value.

And I believe developers should recognize the opportunities their skills create.

But I also believe we need to preserve something simple.

The joy of creating things.

Not because someone will pay us.

Not because it will improve our personal brand.

Not because an algorithm will reward us.

But because solving a problem, understanding a system, or making an idea come alive can be satisfying in its own right.

We don't have to turn every interest into income.

We don't have to turn every experiment into a product.

And we certainly don't have to turn every side project into a startup.

Sometimes you can build something, learn something, smile at what you've created, and move on.

That's not a missed business opportunity. That's a perfectly good reason to build.

AI Mistakes I Should Have Avoided as a Founder

Jaideep Parashar — Fri, 23 Oct 2026 04:46:55 +0000

When I started exploring AI seriously, I was fascinated by what it could do.

Write content.

Analyze information.

Generate code.

Build workflows.

Research markets.

Automate repetitive tasks.

Solve problems that previously required hours of human effort.

As a founder, it was difficult not to get excited.

After all, who wouldn't want to build more, move faster, and accomplish things with fewer resources?

But the longer I work with AI, the more I realize something uncomfortable.

AI makes it incredibly easy to become productive at the wrong things.

You can spend an entire day using AI and feel like you've accomplished a week's worth of work.

Ten ideas generated.

Five documents prepared.

Three workflows designed.

Two prototypes created.

But when the excitement settles, one question remains:

What actually moved the business forward?

That's the question I wish I had asked more often.

Here are seven AI mistakes I believe founders, including me, should learn to avoid.

1. Confusing AI Productivity With Business Progress

This is probably the biggest trap.

AI makes creating things feel effortless.

You can generate a business plan in minutes.

Prepare a market analysis.

Write dozens of social media posts.

Design a product roadmap.

Create an impressive presentation.

And at the end of the day, you feel incredibly productive.

But there's a problem.

Being busy with AI is not the same as building a successful business.

Consider two founders.

Founder A spends the day generating twenty marketing ideas, ten articles, and a detailed customer acquisition strategy.

Founder B spends the day speaking with three potential customers, understanding their problems, and securing one meaningful business conversation.

Who made more progress?

It depends on the business, but I would usually place greater value on what Founder B learned.

Because businesses don't grow simply because we produce more information.

They grow when we create value that someone actually wants.

My lesson: Before using AI, ask what business outcome the work is supposed to improve.

Not what AI can produce.

What the business actually needs.

2. Starting With the AI Tool Instead of the Problem

This mistake has become surprisingly common.

A new AI tool launches.

Everyone starts talking about it.

You see impressive demos.

Someone claims it can replace an entire department.

And suddenly, you start looking for ways to use it.

But think about what just happened.

You started with a solution.

Then went searching for a problem.

As a founder, I think that's the wrong order.

Imagine an organization struggling with slow customer onboarding.

One approach is to immediately introduce an AI agent.

Another is to understand the onboarding process.

Where are customers getting stuck?

Which approvals take too long?

Where is information being entered repeatedly?

Which steps genuinely require human judgment?

Perhaps AI can help.

But perhaps the real problem is an unnecessarily complicated workflow.

A better process may deliver more value than a sophisticated AI system.

This is also why I wrote Stop Building AI Agents. Start Building AI Systems.

The lesson goes beyond agents.

Technology should serve the problem. The problem should not be redesigned to justify the technology.

3. Trusting AI's Confidence More Than the Evidence

One thing AI does remarkably well is sound convincing.

Ask for a market assessment.

You may receive a detailed analysis.

Ask for a competitive strategy.

You'll get structured recommendations.

Ask whether a business idea is viable.

You might receive an encouraging explanation of its potential.

The problem is that an answer can be beautifully written and still be wrong.

This becomes dangerous when you're making founder-level decisions.

Should we enter a new market?

Should we change our pricing?

Should we invest in a particular technology?

Should we hire for a new role?

Should we build this product?

AI can help us evaluate possibilities.

But it doesn't automatically know our actual customers, financial limitations, internal capabilities, or market relationships.

A confident recommendation is not the same as reliable evidence.

I think founders should treat AI-generated business advice the same way they would treat advice from any consultant.

Ask questions.

Challenge assumptions.

Verify important information.

Understand the trade-offs.

And take responsibility for the final decision.

My lesson: Never confuse an articulate answer with a validated business decision.

4. Using AI to Create More Work Instead of Eliminating Work

This one is particularly interesting.

AI promises to reduce work.

But sometimes it does the opposite.

Let me explain.

Suppose you're managing a small company.

You introduce several AI tools.

One for research.

One for content.

One for project management.

One for automation.

One for presentations.

One for customer communication.

Initially, everything feels faster.

But gradually, you begin managing the tools themselves.

Different subscriptions.

Different interfaces.

Different workflows.

Different files.

Different outputs that need reviewing.

You saved time performing individual tasks.

But you created another layer of work coordinating the tools.

This is a mistake founders should watch carefully.

Every additional system introduces some amount of complexity.

And complexity has a cost.

Sometimes the best way to improve productivity isn't adding another AI tool.

It's removing an unnecessary task.

Before automating a process, I now prefer asking:

"Does this process need to exist at all?"

Because eliminating unnecessary work is often more valuable than automating it.

5. Believing Faster Execution Automatically Creates Competitive Advantage

AI has made execution dramatically more accessible.

That's exciting, especially for founders operating with limited resources.

You no longer need a large team to prototype every idea.

You can research faster.

Build faster.

Write faster.

Experiment faster.

But there's another side to this development.

If everyone can build faster, speed alone becomes a weaker advantage.

Imagine two startups building similar products.

Both use AI coding assistants.

Both can create working prototypes quickly.

Both have access to similar infrastructure and models.

Where does the differentiation come from?

It may come from understanding a customer problem more deeply.

Having better distribution.

Building trust.

Creating a superior experience.

Developing strong industry relationships.

Or making better product decisions.

AI can reduce the cost of execution.

It cannot automatically create customer trust or a meaningful market position.

This is why I believe founders need to think beyond productivity.

The important question isn't simply:

"How much faster can we build?"

It's:

"Why would someone choose what we're building?"

That question becomes even more important when competitors have access to the same powerful tools.

6. Forgetting That Human Relationships Still Build Businesses

As AI capabilities improve, it becomes tempting to automate every interaction.

Customer emails.

Sales outreach.

Follow-ups.

Social media conversations.

Networking messages.

Even parts of relationship management.

Some automation is genuinely helpful.

But there's something I don't want founders to overlook.

Businesses are still built on trust between people.

An AI-generated message can be grammatically perfect.

It can sound professional.

It can even be personalized.

But that doesn't mean it establishes a meaningful relationship.

Think about receiving a message from someone who clearly understands your work, references an idea you've shared, and asks a thoughtful question.

Now compare it with a polished message that could have been sent to five hundred people.

Both might be professionally written.

Only one makes you feel that someone is genuinely interested.

As a founder, I believe relationships are one of the few advantages that cannot be replicated simply by subscribing to another AI service.

AI can help us prepare.

It can help us research.

It can help us communicate more clearly.

But the intention behind the relationship must remain human.

My lesson: Use AI to support relationships, not to replace the effort required to build them.

7. Asking AI for Too Many Answers and Not Spending Enough Time Thinking

This may be the most personal lesson of all.

AI makes getting answers incredibly easy.

Have an idea?

Ask AI.

Facing a difficult decision?

Ask AI.

Need a strategy?

Ask AI.

Don't know what to do next?

Ask AI.

There's nothing inherently wrong with any of this.

The danger appears when we stop developing our own point of view.

As a founder, I don't think our most important job is collecting answers.

It's making decisions under uncertainty.

And that requires independent judgment.

AI can provide five options.

It can compare advantages and disadvantages.

It can identify risks.

It can challenge our assumptions.

But eventually, someone has to decide.

Sometimes there won't be enough information.

Sometimes the market will behave unpredictably.

Sometimes an apparently logical decision will fail.

And sometimes the unconventional decision will turn out to be the right one.

That's the reality of entrepreneurship.

I don't want AI to eliminate that responsibility.

I want it to help me become better at handling it.

One useful way to do this is to form an opinion before consulting AI.

Instead of asking:

"What should I do?"

Try:

"Here is my current reasoning. What assumptions am I missing? What evidence would prove me wrong?"

It's a small change.

But it moves AI from being an answer generator to being a tool for examining decisions.

And I think that's a much healthier relationship.

What I Would Do Differently

If I were establishing an AI-driven workflow as a founder today, I would begin with a much simpler approach.

First, identify the three most important problems affecting the business.

Not thirty.

Three.

Then examine which of those problems genuinely benefit from AI.

For each one, I would define:

The outcome: What should improve?
The baseline: How well are we doing today?
The approach: What is the simplest useful solution?
The human role: Who remains responsible for the decision?
The measurement: How will we know whether it helped?

Only then would I begin selecting tools and building workflows.

For example, if the problem is slow customer research, the objective shouldn't be generating fifty research reports every week.

It should be improving the quality and speed of decisions made using that research.

If the problem is customer support, the goal shouldn't be increasing the number of AI-generated responses.

It should be helping customers resolve issues accurately and efficiently.

And if the problem is content marketing, the objective shouldn't be publishing as many articles as possible.

It should be reaching the right audience, earning trust, and generating meaningful conversations.

These distinctions may sound obvious.

But AI's ability to produce so much so quickly makes them surprisingly easy to forget.

The Founder Still Has to Be the Founder

Here's something I believe strongly.

AI can be an extraordinary assistant.

It can help us think.

Research.

Create.

Analyze.

Build.

Experiment.

And sometimes accomplish things that would previously have been beyond our resources.

But it cannot take ownership of our company.

It cannot fully understand the weight of every decision.

It cannot personally build trust with our customers.

It cannot assume responsibility when a strategic bet fails.

And it cannot decide what kind of company we ultimately want to create.

Those responsibilities remain with the founder.

The more powerful AI becomes, the more important it is to remember that distinction.

The Biggest Mistake Would Be Learning Nothing

I don't regret exploring AI.

I don't regret experimenting with new tools.

And I certainly don't believe founders should avoid taking risks with emerging technology.

Experimentation is how we discover opportunities.

But experimentation should teach us something.

If a tool doesn't improve the business, we should be willing to stop using it.

If a workflow creates unnecessary complexity, we should simplify it.

If an AI-generated recommendation doesn't survive scrutiny, we should reject it.

And if an entire project begins drifting away from the actual customer problem, we should have the courage to reconsider it.

That's not being anti-AI.

That's being responsible for the business.

The more I think about entrepreneurship in the AI era, the more I come back to one conclusion:

AI can help founders do more. But knowing what deserves to be done is still the founder's job.

And perhaps that's the biggest lesson of all.

The goal isn't to build an AI-powered company simply because AI is available.

The goal is to build a valuable company and use AI wherever it genuinely helps.

Because at the end of the day, customers don't care how many AI tools we use.

They care whether we solve their problems.

And no amount of automation can replace that responsibility.

A question for fellow founders and builders:

What's one mistake you've made while using AI to build a product, run a business, or manage your work?

Was it trusting the output too much, adopting too many tools, building something nobody needed—or something completely different?

I'd love to learn from your experience.

Your Dashboard Is Green. Your Users Are Still Unhappy.

Jaideep Parashar — Fri, 16 Oct 2026 13:42:51 +0000

Imagine getting a message from a customer:

"Your application isn't working."

You open your monitoring dashboard.

Server uptime: 99.99%.

API response time: 120 milliseconds.

Error rate: 0.1%.

CPU usage: normal.

Database connections: healthy.

Everything is green.

So you respond:

"Our systems are working normally."

But the customer is still unable to complete their task.

And now you have an interesting problem.

Your monitoring system says everything is fine. Your user says nothing is fine.

Who is right?

I think this reveals something we don't discuss enough in software engineering.

A system can be technically healthy and still be completely unsuccessful.

We Measure What Is Easy to Measure

Software engineering has become remarkably good at collecting metrics.

We measure:

uptime
latency
throughput
error rates
memory consumption
CPU utilization
database performance
deployment frequency
test coverage

These are important measurements.

They help engineers understand how software behaves.

But they don't necessarily tell us whether the software is achieving its purpose.

Consider an online shopping application.

The homepage loads.

The search API responds.

The product database works.

The checkout service is available.

But customers cannot complete their purchases because a confusing validation message prevents them from entering their delivery address.

From the infrastructure perspective, almost everything might look healthy.

From the customer perspective, the application is broken.

The system is available. The outcome is unavailable.

That's a very different failure.

The Problem With Green Dashboards

A green dashboard creates confidence.

Sometimes deserved confidence.

Sometimes false confidence.

Imagine a monitoring panel showing:

Service Health

API Uptime 99.99%
Avg. Latency 120ms
Error Rate 0.10%
CPU Usage 42%
Database Healthy

Overall Status: GREEN

Now imagine another dashboard:

User Outcomes

Checkout Completion 61%
Payment Retries High
Search Abandonment Rising
Failed User Journeys Rising

Overall Status: WARNING

Both dashboards can describe the same application.

Neither is necessarily wrong.

They're answering different questions.

The first asks:

"Is the infrastructure operating?"

The second asks:

"Can users accomplish what they came here to do?"

We need both.

The mistake is treating the first as proof of the second.

A Successful API Call Can Still Be a Failed Experience

This is one of the most interesting distinctions in modern software.

Consider an API:

@app.get("/recommendations")
def get_recommendations():
    return {
        "status": "success",
        "recommendations": []
    }

Technically, the API works.

It returns a valid response.

The HTTP status is 200.

No exception occurs.

Your monitoring system may count this as a successful request.

But if the user was expecting useful recommendations, the response might represent a product failure.

This doesn't mean an empty list is always wrong. Sometimes there genuinely are no suitable recommendations.

It means technical success and useful success are different concepts.

The application needs a way to distinguish them.

And that distinction cannot always be inferred from the HTTP status code.

This Gets More Complicated With AI

Now let's introduce an AI system.

Imagine a customer-support assistant.

It responds to every request.

Its average response time is excellent.

The model API rarely fails.

Token usage is within budget.

All technical indicators look good.

But customers keep receiving answers that are polite, grammatically correct, and completely unhelpful.

The system is functioning.

The model is responding.

The workflow is completing.

Yet the customer is frustrated.

This is why measuring an AI application only through latency, availability, and cost is insufficient.

We also need to understand things like:

Did the response answer the question?
Was it factually supported?
Did the system follow the required process?
Did the customer achieve their intended outcome?
Was human intervention required?
Did the interaction create another problem?

Some of these require carefully designed evaluation datasets, human review, or validated automated checks.

You cannot simply install a monitoring library and expect it to understand customer satisfaction.

Observability tells you what happened. Evaluation helps you determine whether it was good enough.

Both matter.

Sometimes Our Metrics Reward the Wrong Behavior

Here's an uncomfortable thought.

What if our measurements are not just missing problems?

What if they're encouraging them?

Imagine a development team being evaluated mainly on the number of features delivered.

Naturally, the team becomes very good at shipping features.

More releases.

More pull requests.

More completed tickets.

But perhaps the application becomes increasingly difficult to use.

Maybe customers only needed three improvements, while the team delivered thirty features.

The delivery metrics look impressive.

The product becomes worse.

The same thing can happen with AI.

If we reward a system for answering questions quickly, it may produce fast but incomplete responses.

If we optimize only for reducing human involvement, we may discourage necessary escalation.

If we optimize solely for low cost, we may sacrifice quality.

This is not an argument against metrics.

It's an argument for understanding what a metric actually represents.

When a measurement becomes a target, we need to be careful about what behavior it encourages.

The Missing Layer: Outcome Observability

I think software teams need to pay more attention to what we might call outcome observability.

Traditional observability helps us understand the internal state of a system through signals such as logs, metrics, and traces.

Outcome observability extends the question.

Instead of looking only at whether components operated correctly, we also look at whether important user journeys succeeded.

Consider an application that processes invoices.

We could measure:

Technical metrics

API latency
processing errors
queue depth
database availability

Workflow metrics

invoices successfully processed
invoices requiring manual correction
duplicate submissions
processing delays

Outcome metrics

invoices correctly finalized
time from submission to approval
correction costs
percentage of users completing the process without assistance

The three layers answer different questions.

Infrastructure
↓
Is the system operational?

Workflow
↓
Is the process functioning?

Outcome
↓
Is the user achieving the goal?

The key is to connect these layers instead of monitoring them separately.

The Question That Changes Everything

Before designing a dashboard, I think we should ask:

"What does success look like from the user's perspective?"

Not the developer's perspective.

Not the infrastructure team's perspective.

Not the product manager's perspective.

The user's.

If you're building a payment system, success isn't simply returning HTTP 200.

It's helping authorized customers complete payments correctly and safely.

If you're building an educational platform, success isn't simply counting videos played.

It's helping people learn.

If you're building an AI assistant, success isn't merely generating an answer.

It's helping someone accomplish a task reliably.

Once that outcome is clear, we can work backward.

What events would indicate success?

What events would indicate failure?

What should we measure?

Which measurements are merely proxies?

And what important failures might still remain invisible?

These questions are just as important as choosing a monitoring tool.

But Outcomes Are Harder to Measure

There is a reason engineering teams rely heavily on technical metrics.

They're relatively straightforward.

A server is available or it isn't.

A request takes 100 milliseconds or 500 milliseconds.

A test passes or fails.

Human outcomes are messier.

Did the user abandon checkout because of a bug?

Because the delivery price was too high?

Because they changed their mind?

Because the interface was confusing?

We cannot assume that every abandoned checkout represents a software failure.

A decline in conversion could also reflect pricing, seasonality, or changing customer demand.

That's why outcome metrics need interpretation.

Sometimes they require user research.

Sometimes controlled experiments.

Sometimes investigating individual journeys.

Sometimes the best question isn't:

"What does the dashboard say?"

But:

"What happened to the people represented by these numbers?"

A Better Way to Investigate Production Problems

Suppose a customer reports a failed transaction.

Instead of checking only whether the server was healthy, we can trace the journey:

User starts checkout
↓
Address validation
↓
Cart confirmation
↓
Payment authorization
↓
Order creation
↓
Confirmation delivered

Which stage failed?

Did the user receive a meaningful explanation?

Was the payment authorized but the order never created?

Was the order created but the confirmation never delivered?

Could the user safely retry?

These are workflow questions.

And they often reveal problems that infrastructure health metrics cannot.

This is one reason I believe systems thinking matters so much in software development.

The value of the application comes from the complete experience, not from individual components operating in isolation.

AI Makes the Measurement Problem More Urgent

AI-generated functionality introduces another challenge.

Traditional software often follows explicit logic.

AI systems can produce plausible outputs that are still incorrect.

A chatbot can confidently give the wrong answer.

A coding assistant can generate code that passes a superficial check but violates a requirement.

A document-processing system can extract the wrong number while returning a perfectly valid JSON object.

The request succeeds.

The output format is correct.

The result is wrong.

We need evaluation methods that go beyond asking whether the application ran successfully.

This may include reference-based tests, checking factual support, measuring task completion, and reviewing samples of real-world failures with appropriate privacy protections.

No single metric can capture the entire quality of a complex AI system.

The objective is to build enough evidence to make better decisions.

Maybe We Should Stop Celebrating Green So Quickly

I like dashboards.

I like monitoring.

I like measurable engineering.

But I'm becoming increasingly cautious about what a green status actually means.

Green should mean:

"The conditions we're monitoring are within acceptable limits."

It shouldn't automatically mean:

"Everything is fine."

Those are different statements.

A green dashboard is useful evidence.

It is not a complete description of reality.

And perhaps that's one of the most important lessons software engineers can learn as our systems become more complex.

We don't just need better software monitoring. We need better definitions of success.

The Real Question Isn't Whether Your System Works

It's whether your system works for the people it was built to serve.

A fast application that frustrates users isn't necessarily a good application.

A highly available service that produces unusable results isn't necessarily successful.

An AI model that responds to every request isn't necessarily helpful.

And a dashboard full of green indicators doesn't mean every important problem has been solved.

Sometimes the most dangerous failure is the one we never thought to measure.

So the next time every indicator is green, I think we should ask one more question:

"What could still be going wrong that this dashboard would never show us?"

That question might teach us more than another dozen monitoring widgets.

Have you ever worked on a system where all the technical metrics looked healthy, but users were still struggling? What did your dashboards miss?

Want More:

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

The Next Interesting AI App Might Not Have a Screen

Jaideep Parashar — Fri, 09 Oct 2026 03:03:13 +0000

For years, we've been building technology around screens.

Websites.

Mobile apps.

Dashboards.

Chatbots.

AI assistants.

Almost every new software idea seems to follow the same pattern:

Build an interface. Wait for a human to interact with it. Return a result.

But I've been thinking about something different.

What if some of the most interesting applications of AI don't need us to open an app at all?

What if software could understand what was happening around it?

What if it could respond to physical conditions?

What if it could work without an internet connection?

And what if the interface wasn't a screen, but the world itself?

I think that's where software development starts becoming particularly interesting.

We Have Spent Decades Teaching Humans to Use Computers

Think about how we interact with technology today.

You want to check the temperature.

You open an app.

You want to control your lights.

You open another app.

You want to monitor your energy consumption.

You open a dashboard.

You want to understand why a machine stopped working.

You check a monitoring system.

The common assumption is that humans must continually interact with software to obtain information or initiate actions.

But consider a different possibility.

A system that monitors temperature, humidity, energy consumption, and occupancy.

Instead of waiting for someone to open a dashboard, it identifies an unusual pattern and takes an appropriate, authorized action.

No application needs to be opened.

No prompt needs to be written.

The software simply performs its intended function.

Of course, humans may still need an interface for configuration, exceptions, and oversight.

But the interface is no longer the center of the experience.

The outcome is.

The Physical World Is a Very Different Programming Environment

A traditional web application works with relatively structured inputs.

A user clicks a button.

Submits a form.

Uploads a file.

Makes an API request.

Physical systems have a much messier relationship with data.

A sensor can malfunction.

A microphone can capture background noise.

A camera can be obstructed.

A device can lose connectivity.

A battery can run low.

A motor can fail.

Two identical devices can behave differently under different environmental conditions.

And unlike a software bug that produces an incorrect message, a physical-system failure may affect something outside the computer.

That changes how we approach engineering.

The physical world doesn't care whether your demo worked perfectly.

It cares whether the system behaves reliably under real conditions.

AI Is Only One Part of the System

Imagine a small device designed to monitor unusual sounds in an industrial environment.

Its job is to identify patterns that might indicate a machine needs inspection.

A simplified architecture might look like this:

Microphone / Sensor
↓
Signal Processing
↓
Local ML Model
↓
Confidence & Rule Checks
↓
Decision Logic
↓
Alert / Human Inspection
↓
Feedback & Monitoring

Notice something interesting?

The AI model is only one component.

We still need:

reliable sensors
useful signal processing
appropriate confidence thresholds
sensible decision rules
failure handling
logging
security
human oversight

A model might detect an unusual sound correctly.

But if the microphone is defective, the system can still fail.

The intelligence of the model doesn't eliminate the need for engineering.

This is closely related to an idea I explored in Stop Building AI Agents. Start Building AI Systems.

The complete system matters more than any individual intelligent component.

What Happens When the Internet Disappears?

This is one of my favorite questions to ask about connected technology.

Does the application still work when the internet doesn't?

For many applications, losing connectivity is inconvenient.

For some physical systems, it can be a fundamental design problem.

Imagine a smart agricultural device monitoring soil conditions in a remote location. Imagine an AI powered device for eldercare add helps get optimum care in the old age. To build DIY AI ElderCare Programme

If every reading must travel to a cloud server before the system can make a basic decision, connectivity becomes part of the critical path.

But what if the device could process data locally?

It could:

Read the sensor.
Validate the measurement.
Evaluate a predefined rule or local model.
Trigger a permitted action.
Store the result.
Synchronize with the cloud when connectivity returns.

The cloud remains useful for fleet management, updates, historical analysis, and heavier computation.

But the essential function no longer depends entirely on it.

This is one reason I find edge computing fascinating.

It changes where decisions can happen.

Not Everything Needs an AI Model

Here's where I want to challenge the excitement around intelligent devices.

Suppose we want a system to switch on a fan when a room becomes too hot.

Do we need an LLM?

A neural network?

An autonomous agent?

Probably not.

A simple rule might be enough:

def should_start_fan(temperature, threshold=30): return temperature > threshold

That is understandable, testable, and predictable.

For a real controller, we'd also want hysteresis, sensor validation, and safe behavior when readings are unavailable.

Now imagine the system must predict equipment deterioration using several changing signals.

A machine-learning model may become useful.

The important distinction is this:

Use AI when the problem requires capabilities that simpler techniques cannot adequately provide.

Otherwise, we're adding complexity because the technology is available.

Not because the problem requires it.

The Next Interface Might Be a Conversation

Not every screenless system needs to operate autonomously.

Some might use voice.

Some might use gestures.

Some might respond to environmental signals.

And some might combine several forms of interaction.

Imagine a technician working on a machine.

Instead of stopping to open a manual on a tablet, the technician could ask:

"What does this warning pattern mean?"

A suitable system might combine a spoken question with equipment documentation and live diagnostic readings.

It could provide an explanation without requiring the technician to navigate a traditional application.

That's a different approach to interface design.

But it introduces engineering challenges too.

What happens when speech recognition fails?

What happens in a noisy environment?

What if two people speak at once?

What if the system misunderstands a safety-critical instruction?

The answer cannot simply be:

"Use a better model."

We need reliable interaction design, confirmation mechanisms, access controls, and safe failure behavior.

Hardware Makes Software Engineers Think Differently

There is a particular discipline that physical systems force upon us.

You cannot assume unlimited compute.

You cannot assume continuous connectivity.

You cannot assume perfect inputs.

You cannot assume a user will always be present to correct an error.

You may have to work within strict limits on:

power consumption
memory
processing capacity
response time
network availability
physical size
maintenance requirements

These constraints are not necessarily disadvantages.

They force us to ask better questions.

Does this computation need to happen locally?

Can we reduce the model size?

Can the system operate with intermittent connectivity?

What happens if a sensor provides incorrect data?

What is the safest action when the system is uncertain?

These are the kinds of questions that make technology engineering interesting beyond the software interface.

The Real Opportunity Is in Combining Technologies

I don't believe the next wave of useful applications will come from AI alone.

It will come from combinations.

AI + Sensors

Systems that interpret environmental and operational data.

AI + Robotics

Machines that can perceive conditions and perform carefully controlled physical tasks.

AI + Edge Computing

Applications that process important information closer to where it is generated.

AI + IoT

Connected devices that move beyond collecting data to helping interpret and act on it.

AI + Traditional Software

Reliable workflows where probabilistic models are used only where they add value.

These combinations are more interesting to me than simply adding another chatbot interface to an existing product.

But they are also harder.

Because when technology touches the physical world, reliability, maintenance, usability, and safety become part of the product, not optional features.

Maybe We've Been Asking the Wrong Question

For years, software teams have often begun with:

"What app should we build?"

With AI, that sometimes becomes:

"What AI feature should we add?"

Or:

"What agent should we create?"

I think we should start with a different question:

"What useful outcome should happen, and what is the simplest reliable system that can make it happen?"

Sometimes the answer will be a website.

Sometimes it will be a mobile application.

Sometimes it will be an API.

Sometimes it will be a basic automation rule.

And sometimes it will be a small device quietly performing its job in the background.

This connects to another idea I've explored: Why I Think Workflows Matter More Than Agents.

Technology should fit the problem.

We shouldn't reshape every problem to fit whichever technology is currently popular.

The Most Interesting Software Might Be the Software We Barely Notice

When technology works well, something interesting happens.

We stop thinking about it.

A good thermostat doesn't require our constant attention.

A well-designed monitoring system doesn't need someone watching a dashboard every second.

A reliable automation system doesn't need to demonstrate how intelligent it is.

It simply works within the limits it was designed for.

That doesn't mean screens will disappear.

Or that every device will become intelligent.

Or that every physical process should be automated.

But I think it represents an important shift in how we imagine software.

For a long time, we built systems that waited for humans to tell them what to do.

Increasingly, we can build systems that observe conditions, process information, and provide useful assistance within carefully defined boundaries.

The challenge is no longer just making software intelligent.

It's making intelligence useful in the real world.

And perhaps the next genuinely interesting AI application won't be another website, chatbot, or dashboard.

Perhaps it will be a small device with a sensor, a modest processor, a carefully chosen model, and one very specific job.

No spectacular interface.

No unnecessary complexity.

Just a system solving a real problem.

What do you think? Are we entering an era where the most interesting software won't necessarily live on our screens?

Want More:

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

I Think We Confuse Clean Code With Good Code

Jaideep Parashar — Fri, 02 Oct 2026 13:50:20 +0000

I've seen beautifully organized code that was difficult to understand.

I've also seen ugly-looking code that solved a complicated problem surprisingly well.

That made me wonder:

Are we sometimes confusing clean code with good code?

We talk a lot about clean code.

Small functions.

Meaningful names.

Design patterns.

Abstractions.

DRY principles.

Consistent formatting.

Well-organized files.

All of these things matter.

But there is a problem.

You can follow every clean-code principle and still build something that nobody understands.

Because clean code and clear code are not necessarily the same thing.

Clean Code Can Still Hide the Problem

Imagine opening a project and finding this:

services/
├── adapters/
├── factories/
├── strategies/
├── repositories/
├── handlers/
├── managers/
├── providers/
└── utilities/

Everything looks organized.

Every class has a name.

Every responsibility appears to have its own abstraction.

The code reviewer might even say:

"This is nicely structured."

But then you try to answer a simple question:

"What happens when a user clicks this button?"

And suddenly you're jumping through eight files.

The code is clean.

The architecture is organized.

But the system is difficult to understand.

That's the distinction I think we often miss.

However, in my last post, "I Think AI Is Making Coding Easier and Learning Harder", I emphasised how AI is making coding easier.

Clear Code Answers "Why?"

Clean code often focuses on how the code is written.

Clear code also focuses on why the code exists.

Consider this:

if user.age >= 18: allow_access()

It's simple.

It's readable.

But imagine the actual business rule is:

Users can access the feature if they are 18 or older, have completed identity verification, and are not currently suspended.

Now we might write:

if ( user.age >= 18 and user.identity_verified and not user.suspended ): allow_access()

That's still relatively clear.

But six months later, someone changes the requirement.

Perhaps suspended users can now access the feature under certain conditions.

The code may remain syntactically clean.

What matters now is whether the reason behind the rule is visible.

That's where comments, documentation, tests, naming, and architecture become important.

Not to explain what the code does.

To explain why it does it.

Comments Were Never the Enemy

There is a popular idea in software development:

"Good code shouldn't need comments."

I understand where this comes from.

Bad comments are absolutely a problem.

This:

# Increment counter by 1 counter += 1

doesn't help anyone.

The code already tells us that.

But consider:

We intentionally use a 5-minute window here.
The payment provider can send duplicate webhook events during retry periods.

That's valuable.

The code cannot fully explain the reason.

The comment captures the decision.

And decisions are often more important than syntax.

This is why I don't think the goal should be:

"Write code that needs no comments."

The better goal is:

"Write code that doesn't need comments to explain what it does, but use comments when the why isn't obvious."

Abstraction Can Make Code Less Clear

Abstraction is one of the most powerful tools in software engineering.

It is also one of the easiest to overuse.

Suppose we have:

send_email(user)

That's easy to understand.

But imagine the implementation eventually becomes:

send_email()
↓
NotificationManager
↓
NotificationFactory
↓
EmailProviderResolver
↓
EmailStrategy
↓
TransportAdapter
↓
SMTPService

Every individual component might be perfectly designed.

But the original operation has disappeared beneath the architecture.

This is the abstraction paradox:

An abstraction is useful when it hides unnecessary complexity.

But too many abstractions can create a new kind of complexity:

understanding where the real work happens.

DRY Can Become Wet

One of the first principles many developers learn is:

Don't Repeat Yourself.

It's a good principle.

But I've also seen developers create complicated abstractions simply because two pieces of code looked similar.

The problem is that similarity doesn't always mean they have the same reason to exist.

Two functions can look almost identical today while representing completely different business concepts.

If we force them into one abstraction, we save a few lines of code but create a dependency between two things that may eventually evolve differently.

Now changing one behavior requires understanding the other.

We eliminated duplication.

And introduced coupling.

Sometimes a little duplication is cheaper than a lot of abstraction.

AI Makes This Problem More Interesting

This becomes particularly relevant in the age of AI-assisted coding.

AI is very good at producing code that looks professional.

It can create:

classes
interfaces
abstractions
helper functions
design patterns
error handling
documentation
tests

The resulting code can look remarkably polished.

But polished code isn't automatically good architecture.

AI doesn't always know which abstraction is worth having.

It may optimize for patterns it has seen repeatedly.

And because the generated code often looks sophisticated, developers may be less likely to question it.

This creates a new review problem.

We shouldn't only ask:

"Is this code clean?"

We should also ask:

"Did we make the system harder to understand than it needed to be?"

The Simplest Code Isn't Always the Best Code Either

I don't want to replace one extreme with another.

"Keep it simple" can become another dogma.

Sometimes complexity is necessary.

Distributed systems are complex.

Security systems are complex.

Financial software can be complex.

Operating systems are complex.

Large-scale applications are complex.

The goal isn't to eliminate complexity.

The goal is to make sure the complexity exists for a reason.

There is a huge difference between:

Necessary complexity

and

Accidental complexity

The first comes from the problem.

The second comes from how we chose to solve it.

Good engineering tries to minimize the second without pretending the first doesn't exist.

I Now Ask a Different Question During Code Review

When I look at code, I don't want to ask only:

"Is this clean?"

I want to ask:

Can I understand the main flow?

If I have to jump through ten files to understand a simple operation, something may be wrong.

Can I understand the important decisions?

Why does this condition exist?

Why is this timeout five seconds?

Why are we retrying three times?

Why are we using this database?

Can I change something safely?

If a small requirement change requires understanding the entire application, the architecture may be hiding too much.

Can a new developer understand it?

This is one of my favorite tests.

Not:

"Can the person eventually figure it out?"

But:

"Can they build the right mental model without needing the original author beside them?"

That's a much higher standard.

Code Is Communication

We often think of programming as communicating with computers.

That's only half the job.

We're also communicating with the next developer.

And sometimes that developer is us six months later.

The computer doesn't care whether the architecture is intuitive.

It executes instructions.

Humans have to maintain the system.

That's why readability matters.

But readability isn't simply about formatting.

It's about reducing the mental effort required to understand a system.

A beautifully formatted maze is still a maze.

The Best Code Might Be Boring

I increasingly like boring code.

A function that does one obvious thing.

A straightforward database query.

A small number of dependencies.

A simple API.

A clear data flow.

A comment explaining an unusual decision.

A test showing an important business rule.

Nothing clever.

Nothing impressive.

Just understandable.

That kind of code rarely gets celebrated.

Nobody posts:

"Look at this extremely boring function I wrote today."

But boring software can be extraordinarily valuable.

Because the people maintaining it don't have to fight it.

My New Definition of Good Code

If I had to simplify it, I'd say:

**Clean code is code that is well structured.

Clear code is code that is easy to understand.

Good code is code that solves the right problem with an appropriate amount of complexity.**

Those are three different things.

And sometimes they overlap beautifully.

But not always.

A codebase can be clean without being clear.

It can be clear without being particularly elegant.

And it can be technically imperfect while still being the right solution for the problem.

That's why I don't think software engineering should be a competition to produce the prettiest code.

The objective is to build software that people can understand, change, operate, and trust.

Maybe We Need Fewer Rules

Software engineering has accumulated an enormous number of principles.

SOLID.

DRY.

KISS.

YAGNI.

Design patterns.

Clean architecture.

Domain-driven design.

Microservices.

Event-driven architecture.

Functional programming.

Object-oriented programming.

All of these ideas can be useful.

But principles are tools.

They aren't laws of physics.

The moment a principle starts making the software harder to understand, we should be willing to question whether we're applying it correctly.

That's probably one of the most important engineering skills:

Knowing when a good rule has become a bad decision.

The Question I Want to Leave You With

The next time you review a piece of code, don't ask only:

"Is this clean?"

Ask:

"Can I understand why this exists?"

And then ask something even more important:

"Did we make this more complicated than the problem required?"

Because the best code isn't necessarily the code with the most elegant abstractions.

It isn't necessarily the code with the fewest lines.

And it certainly isn't the code that looks the most impressive.

Sometimes the best code is simply the code that makes the next developer say:

"Okay. I understand."

And perhaps that's a better definition of clean code than we usually give it.

Want More:

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

I Think AI Is Making Coding Easier and Learning Harder

Jaideep Parashar — Fri, 25 Sep 2026 03:57:07 +0000

I can write code faster today than I could a few years ago.

AI can explain an unfamiliar library.

It can generate a function.

It can suggest a fix.

It can write SQL.

It can help debug an error.

It can even explain the code it just generated.

From a productivity perspective, this is incredible.

But I've started thinking about a different question:

What happens to the learning process when the difficult part of coding becomes optional?

I don't think AI is making developers less capable.

But I do think it has created a new risk:

We can now become productive before we become good.

And those are not the same thing.

The Struggle Was Part of the Learning

Think about how we traditionally learned programming.

You wrote something.

It didn't work.

You read the error.

You searched for an explanation.

You tried something else.

It failed again.

You read documentation.

You changed the code.

Eventually, it worked.

That process was frustrating.

But something important was happening during those frustrating hours.

You were building a mental model.

You were learning why the system behaved the way it did.

You weren't simply learning the answer.

You were learning how to arrive at the answer.

AI changes that equation.

Today, you can paste the error into an AI assistant and get a possible explanation almost immediately.

That's useful.

But it also means you can skip several steps of the learning process.

And sometimes those skipped steps were the most valuable ones.

The Dangerous Part Isn't AI

I don't think the problem is AI itself.

The problem is how we use it.

There is a big difference between:

"Explain why this error is happening."

and:

"Fix this."

The first can teach you something.

The second can simply remove the obstacle.

Both can get you moving again.

But they don't necessarily produce the same learning.

This distinction becomes even more important when you're learning something new.

If I already understand Python and ask AI to help me optimize a piece of Python code, that's one thing.

If I'm learning Python and ask AI to write every function I don't understand, that's very different.

In the second case, I may finish the project without actually learning how I built it.

Productivity Can Hide the Learning Gap

This is where things get interesting.

Imagine two developers learning the same technology.

Developer A spends three hours struggling with a problem.

Developer B asks AI and solves it in ten minutes.

On the surface, Developer B has been more productive.

But what happens when the same problem appears next month?

Developer A may recognize the pattern.

Developer B may need to ask AI again.

Neither person necessarily did anything wrong.

They optimized for different things.

One optimized for completion.

The other accidentally optimized for understanding.

The problem is that modern development increasingly rewards completion.

And AI is exceptionally good at helping us complete things.

I Don't Want to Go Back to Coding Without AI

This is important.

I'm not arguing that developers should stop using AI.

That would be like saying developers should stop using debuggers because debugging used to be harder.

Tools are supposed to make us more capable.

I use AI because it genuinely makes many parts of development faster.

The goal isn't to preserve unnecessary struggle.

The goal is to preserve useful struggle.

That's a very different idea.

If I'm spending thirty minutes trying to remember a syntax detail that I could verify in ten seconds, I don't think that struggle is valuable.

But if I'm trying to understand why an architecture behaves the way it does, immediately asking AI for the answer may deprive me of an important learning opportunity.

The "Try First" Rule

I've started thinking about a simple rule:

Try first. Ask AI second.

Not always.

But often.

If I encounter a problem I believe I can solve, I give myself some time to reason about it before asking AI.

I might:

read the error
inspect the code
form a hypothesis
test the hypothesis
search the documentation
try a solution

Then I ask AI.

And something interesting happens.

The AI's answer becomes much more useful because I have a mental model of the problem.

I'm no longer asking:

"What should I do?"

I'm asking:

"Here's what I think is happening. Am I missing something?"

That is a much more powerful interaction.

AI Should Challenge Your Thinking

This is also changing how I think about prompts.

Instead of always asking AI to produce something, we can ask it to challenge us.

For example:

"Here is my approach. Find the weaknesses."

Or:

"Don't solve this yet. Give me three questions I should investigate."

Or:

"I think this is the cause of the bug. Try to disprove my hypothesis."

Or:

"Review my solution, but don't rewrite it. Tell me what I misunderstood."

These interactions keep the developer inside the reasoning loop.

AI becomes less like an answer machine and more like a thinking partner.

That's a much healthier relationship.

There Is a Difference Between Knowing and Accessing

This may become one of the biggest distinctions in AI-assisted development.

I don't need to memorize every Python method.

I don't need to remember every SQL syntax variation.

I don't need to know every framework API by heart.

AI and documentation can handle a lot of retrieval.

But I still need to understand:

What am I trying to do?

Why does this approach make sense?

What assumptions am I making?

What could go wrong?

How would I know if the result is wrong?**

Those are not simply information-retrieval problems.

They are reasoning problems.

And I don't think AI makes those skills less important.

I think it makes them more important.

The New Developer Skill Might Be Knowing When Not to Ask

There is an interesting irony here.

As AI becomes better at answering questions, the skill of asking good questions becomes more valuable.

But perhaps there is another skill:

Knowing when to answer the question yourself first.

If I ask AI everything immediately, I may become extremely efficient at retrieving answers.

But I may become less practiced at generating them.

That distinction matters.

A calculator didn't make mathematicians less intelligent.

But someone who never learns basic arithmetic because a calculator exists has a different problem.

The tool isn't the issue.

Dependency is.

AI Can Make You a Better Developer

The same technology that creates this risk can also solve it.

AI can explain unfamiliar code.

It can give you alternative approaches.

It can challenge your assumptions.

It can create exercises.

It can act as a tutor.

It can review your implementation.

It can ask you questions instead of giving you answers.

It can help you understand why something works.

Used this way, AI doesn't replace the learning process.

It can actually accelerate it.

The difference is whether we're using AI to avoid thinking or to improve our thinking.

Maybe We Need a New Development Loop

The old loop looked something like:

Problem
↓
Think
↓
Code
↓
Test
↓
Debug
↓
Learn

AI can turn it into:

Problem
↓
Think
↓
AI assists
↓
Code
↓
Test
↓
AI challenges
↓
Human evaluates
↓
Learn

I prefer the second model.

Not because AI does more.

Because the human still does the important thinking.

The Real Risk Isn't Becoming Lazy

People often ask:

"Has AI made developers lazy?"

I'm not sure that's the most useful question.

Developers have always looked for ways to avoid unnecessary work.

That's part of engineering.

The better question is:

"Are we automating away work that was actually teaching us something?"

That's much harder.

Because some effort is waste.

And some effort is education.

The challenge is learning the difference.

I Don't Want to Become Faster at Being Wrong

This is probably the simplest way I can describe my concern.

AI can dramatically increase development speed.

But speed is not the same as progress.

If I misunderstand the problem and AI helps me implement the wrong solution in ten minutes instead of ten hours, I haven't necessarily become a better developer.

I've simply become faster at being wrong.

That's why I still want to understand the fundamentals.

I still want to read documentation.

I still want to debug.

I still want to write code without assistance sometimes.

Not because I dislike AI.

Because I want to remain capable without it.

The Goal Isn't to Code Without AI

I don't think the future belongs to developers who refuse to use AI.

And I don't think it belongs to developers who let AI do everything.

The interesting middle ground is this:

Use AI for leverage, but keep ownership of your understanding.

Let AI handle repetitive work.

Let it explain unfamiliar concepts.

Let it review your code.

Let it challenge your assumptions.

Let it help you move faster.

But occasionally close the AI window and ask yourself:

"Do I actually understand what I just built?"

If the answer is yes, you're probably using the tool well.

If the answer is no, perhaps the tool moved faster than your understanding.

And that's something worth paying attention to.

Because in the AI era, I don't think our biggest challenge will be learning how to make machines do more.

It may be learning how to make sure we continue to think while they do it.

Want More:

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

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?"