DEV Community: Mahima Thacker

Agent Trajectory and Convergence: Why the Path Matters in AI Agent Evals

Mahima Thacker — Tue, 07 Jul 2026 09:45:03 +0000

When evaluating AI agents, we often focus on the final answer.

Was it correct?
Was it useful?
Was it grounded?

That matters.

But for agents, there is another important question:
How did the agent get there?

This is where agent trajectory comes in.

What is an agent trajectory?

Agent trajectory means the path an agent takes before producing the final answer.

It includes the steps the agent went through, such as:

router decisions
tool calls
database lookups
retrieval steps
LLM calls
repeated actions
final response

A simple agent path may look like this:

User input
→ Router
→ Database lookup
→ Data analyzer
→ Output

A messy agent path may look like this:
User input
→ Router
→ Database lookup
→ Router
→ Data analyzer
→ Router
→ Database lookup
→ Router
→ Data analyzer
→ Output
Both paths may eventually produce the correct answer.

But they are not equally good.

The second path takes more steps, costs more, takes longer, and creates more chances for something to fail.

Why trajectory matters

Imagine a user asks:
“Show me last month’s sales trend.”

The agent may need to:

Understand the question
Choose the right database tool
Fetch the data
Analyze the result
Generate the final answer

That is a reasonable path.

But an inefficient agent may:

call the same tool multiple times
keep going back to the router
repeat the same analysis
use the wrong tool first
query the database again without need
take many steps before giving the answer

The final answer may look okay.
But the system behavior is not okay.

In production, inefficient paths matter because they increase:

latency
cost
API usage
tool calls
failure risk
debugging complexity
user wait time

This is why agent evals should evaluate both:

Output quality
+
Path quality

What is convergence?

Convergence measures how closely an agent follows the optimal path for a given query.

Simple meaning:
Is the agent reaching the answer cleanly, or is it wandering around?
If the agent takes the shortest useful path most of the time, convergence is high.

If it keeps taking unnecessary steps, convergence is lower.
A simple convergence score

One way to calculate convergence is by running the agent on similar queries and recording how many steps it takes.

Let:
N = total number of runs
S_agent,i = number of steps taken by the agent in run i
S_optimal = shortest successful path length across the runs

Then:
Convergence score =
average of min(1, S_optimal / S_agent,i)

Or written more formally:

Overall Convergence Score = (Σᵢ₌₁ᴺ min(1, S_optimal / S_agent,i)) / N

Simple example:

Assume the shortest successful path takes 5 steps.
If one agent run takes 5 steps:
score = min(1, 5 / 5) = 1

That is ideal.

If another run takes 10 steps:
score = min(1, 5 / 10) = 0.5

If another run takes 20 steps:
score = min(1, 5 / 20) = 0.25

Lower score means the agent is taking more steps than needed.
What a convergence score tells us

A convergence score helps answer:

Is the agent taking the shortest useful path?
Is it repeating unnecessary steps?
Is it using tools efficiently?
Is it getting stuck before answering?
Is it consistent across similar inputs?

This is useful because two agents may both answer correctly, but one may do it in a much cleaner way.

But convergence is not enough
Convergence should not be measured alone.

A short wrong path is not better than a longer correct path.

For example, if the agent gives a wrong answer in 3 steps, that is not good just because it was fast.

So convergence should be evaluated together with:

final answer correctness
task success
tool choice accuracy
grounding
safety
output quality Efficiency only matters after the agent is doing the right thing.

How this connects to traces

To measure trajectory and convergence, we need traces.
A trace shows what happened during an agent run.

It can show:

which steps happened
how many steps were taken
which tools were called
whether steps repeated
whether the agent made progress
where time was spent

Without traces, we only see the final answer.
With traces, we can inspect the path.

That is why observability and evals work well together.

Observability shows what happened.
Evals help decide whether it was good or bad.

Final thought

Agent evals are not only about final answers.
They are also about behavior.

A good agent should answer correctly.

But it should also take a clean, efficient, and understandable path.

That is why trajectory matters.
And that is why convergence can be a useful signal when evaluating AI agents.

How to Choose the Right Eval for an AI Agent

Mahima Thacker — Fri, 03 Jul 2026 12:05:36 +0000

When I started learning about AI agent evaluation, I thought evals were mostly about checking the final answer.

But agents are not just final-answer machines.

They are systems made of smaller parts:

router
tools
skills
memory
retrieval
final response

Each part can fail differently.

So the better question is not only:
Did the agent answer correctly?

It is also:
Which part of the agent should I evaluate, and what type of eval makes sense there?

Not every eval needs an LLM judge

This was one important thing I learned.
It is easy to think that if we are evaluating LLM systems, we should use another LLM to judge everything.

But that is not always the best choice.
Some checks are simple and deterministic.
Some checks are subjective.
Some checks need human judgment.

A good eval setup uses the right method for the right problem.

Three common eval methods

There are three common ways to evaluate LLM systems and agents:
1) Code-based evals
2) LLM-as-a-judge evals
3) Human evaluation

Let’s break them down simply.

1. Code-based evals

Code-based evals are useful when the expected behavior is clear.
For example:

did the output return valid JSON?
did the answer contain a required keyword?
did it match a regex?
did the agent call the correct tool?
did it extract the correct parameter?
did the SQL stay read-only?
did generated code run successfully?

These are easier to automate because the rules are clear.

Example:

Expected:
tool = order_status_check
order_number = 1234

Actual:
tool = order_status_check
order_number = 1234

Result:
pass
This does not need an LLM judge.

Code can check it.

2. LLM-as-a-judge evals

LLM-as-a-judge is useful when the output quality is harder to check with simple rules.

For example:

is the summary useful?
is the answer grounded in the source?
did the response answer the user’s actual question?
is the tone appropriate?
did the agent hallucinate?
is the reasoning coherent?

These are qualitative checks.
You can ask another LLM to judge the output using a clear rubric.
But this method is not perfect.

LLM judges can also make mistakes.

So it helps to use clear labels like:
correct / incorrect
grounded / not grounded
safe / unsafe
useful / not useful

Avoid vague scores like:
87% helpful
73% grounded
Discrete labels are usually easier to interpret and compare.

3. Human evaluation

Human evaluation is still important.

Especially when the task is:

high-stakes
subjective
domain-specific
safety-sensitive
tied to user trust

For example, in healthcare, legal, finance, education, or enterprise workflows, a human may need to review whether the result is actually acceptable.

Humans can also provide labels that later become part of your test dataset.

For example:
User feedback: thumbs up / thumbs down
Human label: correct / incorrect
Reviewer note: answer missed key context
This feedback can help improve future evals.

How to choose the right eval

A simple rule:

If the criteria is deterministic, use code-based evals.
If the criteria is qualitative, use LLM-as-a-judge.
If the criteria needs domain judgment, use human evaluation.

Here is a simple mental model:

Clear rule → code-based eval
Quality judgment → LLM-as-a-judge
Domain or safety judgment → human evaluation

The goal is not to use the most advanced eval.
The goal is to use the eval that gives the clearest signal.

Evaluating a router

A router decides what the agent should do next.

It may choose:
which tool to call
which workflow to run
what parameters to extract
whether to answer directly
whether more context is needed

Router evals usually check two things:
Did the router choose the right function/tool?
Did the router extract the right parameters?

Example:
User:
“Can you check the status of order #1234?”

Correct router decision:
tool = order_status_check
order_number = 1234

Wrong router decision:
tool = shipping_status_check
shipping_tracking_id = 1234

The wrong decision may look small, but it changes the whole path.
If the router fails, the rest of the agent may fail too.

That is why router evals are important.

Evaluating skills

A skill is a task the agent can perform.
For example:

database lookup
data analysis
data visualization
retrieval
summarization
code generation

Each skill may need its own eval.
For a database lookup skill, you may evaluate:

did it generate correct SQL?
did it query the right table?
did it avoid unsafe operations?
did it return the right data?

For a data analysis skill, you may evaluate:

was the calculation correct?
did it identify the right entity?
was the explanation clear?
For a visualization skill, you may evaluate:
did the generated code run?
did the chart match the user’s request?
did it use the right data?

Different skills need different checks.

The mistake: evaluating the agent as one black box
If we only evaluate the final answer, we get weak feedback.

We may only know:
The agent failed.

But we do not know why.

A better eval setup tells us:
the router chose the wrong tool
the parameter extraction failed
the retrieval step returned weak context
the SQL was invalid
the summary hallucinated
the final answer was not useful
This makes improvement easier.

You can fix the specific part that failed.

Final thought

Agent evals become more useful when we break the agent into parts.

Evaluate the router.
Evaluate the tools.
Evaluate the skills.
Evaluate the final response.
Evaluate the path.

That is how evals move from vague scoring to practical debugging.

The goal is not just to say:
This agent is good or bad.

The goal is to understand:
What failed, where it failed, and how to improve it.

Tracing AI Agents: Why Observability Matters

Mahima Thacker — Sat, 27 Jun 2026 06:44:19 +0000

When building AI agents, the final answer is only one part of the system.

The more useful question is often:
What happened before the agent gave that answer?

That is where observability comes in.

What is observability?

Observability means having visibility into what your system is doing.
For an AI agent, that means seeing:

which steps ran
which tools were called
what inputs were passed
what outputs came back
where the agent failed
where it repeated itself
whether it actually made progress

Without observability, debugging agents becomes guesswork.

You see seeing:

which steps ran
which tools were called
what inputs were passed
what outputs came back
where the agent failed

the final answer, but you do not know how the agent got there.

What is a trace?

A trace is the full path of one request through the system.
For an AI agent, a trace may look like this:
User query
→ Router
→ Tool selection
→ Tool call
→ Tool result
→ LLM step
→ Final answer

That whole journey is one trace.
It tells the story of one agent run.

What is a span?

A span is one step inside a trace.

For example, these can all be spans:

router decision
retrieval call
database query
API call
LLM call
tool execution
summarization step

Many spans together make one trace.

A simple way to remember it:
Trace = full journey
Span = one step in the journey

Why agents need traces

AI agents can fail in many places before the final answer.
For example, an agent may:

choose the wrong tool
send the wrong input to a tool
retrieve weak context
ignore the tool result
repeat the same step
get stuck in a loop
take too many steps before answering

If you only check the final answer, you may miss these problems.
The answer may look okay, but the path may still be inefficient, risky, or wrong.

What is instrumentation?

Instrumentation is the process of adding tracking points to your code.

It tells the system:
Capture this step as part of the trace.

For example, you may instrument:

the router
the tool call
the LLM call
the retrieval step
the final response

This helps collect useful data like:
start time
end time
input
output
errors
latency
metadata

Tools like OpenTelemetry and Arize Phoenix help collect and visualize these traces.

Why this helps debugging

Imagine your agent gives a bad answer.

Without traces, you may only know:
The answer was wrong.
With traces, you can ask better questions:

Did the router choose the wrong path?
Did retrieval return weak context?
Did the tool fail?
Did the LLM ignore the tool result?
Did the agent repeat steps?
Did the agent spend too much time in one part?

This gives you a clearer debugging path.
Instead of guessing, you can inspect the actual run.

Observability and evals work together

Observability tells you what happened.

Evals help you decide whether that behavior was good or bad.
For example, a trace may show:
The agent called the database tool 5 times.

An eval can help decide:
Was that useful, or was the agent stuck?

That is why traces and evals are stronger together.

Final thought

If we want to build reliable agents, we need visibility into each step.
That means:

traces
spans
instrumentation
evals
error analysis

The final answer matters. But the path matters too.

Understanding AI Agents: Routers, Tools, Memory, and Why They Need Better Evals

Mahima Thacker — Fri, 26 Jun 2026 09:44:27 +0000

As you all know, AI agents are software systems that can reason, choose tools, and take actions on behalf of a user.

They work by routing a request, using one or more tools or skills, carrying state or memory, and then producing a final answer or action.

That sounds simple, but once you start building agentic systems, you quickly realize something:

An agent is not one big magic box. It is a workflow.And every workflow has places where it can break.

A simple agent flow

A basic agent flow may look like this:
User query
→ Router
→ Tool selection
→ Tool call
→ Tool result
→ LLM reasoning
→ Final answer

The user only sees the final answer.

But the system did many things before reaching that answer.

This is why evaluating agents is harder than checking if the final response sounds good.

The main parts of an agent

Most agents have a few common parts.

1. Router

The router decides what should happen next.

It may decide:
which tool to call
which workflow to run
whether the question needs retrieval
whether the agent should ask a follow-up question
whether it can answer directly

The router can be an LLM, a rules-based system, a classifier, or a mix of these.
If the router makes a wrong decision, everything after that can go wrong too.

2. Tools or skills

A skill is a block of logic that helps the agent complete a task.
It may include:

API calls
database queries
web search
calculations
retrieval
code execution
summarization
file processing

For example, a RAG skill might look like this:
embed query
→ search vector database
→ retrieve context
→ call LLM with retrieved context

A tool may work perfectly on its own, but the agent can still use it incorrectly.

That is why we need to evaluate not only the tool, but also how the agent chooses and uses the tool.

3. Memory and state

Memory helps the agent remember previous context.
State helps different parts of the agent share information during execution.

This can include:

chat history
retrieved context
configuration values
previous tool outputs
intermediate decisions
execution steps

Memory is powerful, but it can also create problems.
If the memory contains outdated, irrelevant, or confusing context, the agent may make poor decisions.

Example: data analysis agent

Imagine a data analysis agent.
The user asks:
“Show me sales trends from last month.”

The agent may need to:

Understand the request
Choose the database tool
Generate the right query
Fetch the data
Analyze the result
Create a summary
Maybe generate a chart

The final answer may look fine. But the path may still be wrong.

The agent may have queried the wrong table.

It may have used incomplete data.
It may have ignored a tool result.
It may have repeated the same step.
It may have generated a confident answer from a weak context.

This is the problem with only checking final answers.
What can go wrong?

A few common failures:

wrong tool selected
tool called with wrong input
weak retrieval context
invalid query
repeated tool calls
loop without progress
hallucinated summary
poor final response
correct answer but inefficient path

This is why agent evals need to be more granular.
Evaluate the components

Instead of asking only:
“Is the final answer correct?”
We should also ask:

Router eval
Did the agent choose the right path?
Tool eval
Did it call the right tool with the right input?
Retrieval eval
Did it use relevant context?
Memory eval
Did memory help, or did it confuse the agent?
Path eval
Did the agent avoid loops and unnecessary repeated steps?
Response eval
Was the final answer useful, grounded, and clear?

Why traces matter

Traces show what actually happened during the agent run.

A good trace can show:

router decision
selected tool
tool input
tool output
step count
retries
repeated steps
final answer

Without traces, debugging agents is mostly guesswork.
You see the final answer, but not the path.
And for agents, the path matters.

Final thought

AI agents are workflows.
Workflows need visibility.
If we want agents to become reliable, we need more than prompts.

We need:

traces
evals
error analysis
component-level checks
path-level debugging
better developer tooling

That is what I’m exploring more through projects like LoopGuard and Supabase Agent Eval Kit.

Still learning, but this area feels important.

Why AI Agents Need Both Tests and Traces

Mahima Thacker — Thu, 25 Jun 2026 12:11:44 +0000

I’ve been learning more about evaluating AI agents recently, and one thing clicked for me:

For agents, checking the final answer is not enough.
You also need to evaluate the path the agent took.

Traditional software is usually easier to test because it is more deterministic.

If you give a function the same input, you usually expect the same output.

same input → same expected output

That makes unit tests and integration tests easier to write.
But LLM-based systems are different.

The same input can produce different outputs. The agent may use tools, memory, retrieval, prompts, and multiple reasoning steps before giving a final answer.

So the question is not only:
Did the agent answer correctly?

It is also:
How did the agent reach that answer?

A simple example: data analyzer agent

Imagine you are building a data analyzer agent.

The user asks:
“What was our revenue growth last month?”

The agent may need to:

Understand the user’s request
Choose the right tool
Query the right database table
Analyze the result
Summarize the answer
Remember previous context if needed

The final answer might look correct. But the path may still be wrong.
Maybe the agent queried the wrong table.

Maybe it used weak context.
Maybe it ignored a tool result.
Maybe it repeated the same step multiple times.
Maybe it got stuck in a loop before answering.

This is why agent evaluation is different.

Output evaluation is not enough

Most people start by evaluating the final output.
That is useful.

You can ask:

Is the answer correct?
Is the answer grounded?
Did the agent hallucinate?
Did it answer the user’s question?
Was the response useful?

But for agents, this only shows part of the picture.
An agent can produce a correct-looking answer after taking a bad path.

And in production, that bad path matters.
It can increase cost, latency, risk, and user confusion.

You need to evaluate the path too.

For an AI agent, the path includes things like:

which tool it selected
what input it passed to the tool
what the tool returned
whether it retried
whether it repeated itself
whether it made progress
whether it used the right context

This is where traces become important.

A trace shows what actually happened inside the agent workflow.
Without traces, debugging agents becomes guesswork.

You see the final answer, but you don’t know what happened before that.

Error analysis for agents

In machine learning, error analysis means observing, isolating, and diagnosing mistakes made by a model.

For agentic workflows, error analysis applies to the whole system.
Not just the final LLM response.

For example:

The router selected the wrong tool
The retrieval step returned irrelevant context
The agent queried the wrong database table
The tool call failed, but the agent continued confidently
The agent repeated the same action without progress
The final answer was acceptable, but the workflow was inefficient

These are system-level failures.

You cannot catch them by only reading the final answer.

Different parts need different evals

One eval cannot check everything.

A router decision, tool call, retrieval step, summary, and final answer may all need different checks.

1) Code-based evals

Code-based evals are useful when the expected behavior is clear.

For example:

Did the agent call the right tool?
Did it return valid JSON?
Did it stay within the expected number of steps?
Did it avoid unsafe operations?
Did the API response match the expected schema?

These are easier to automate.

2) LLM-as-a-judge

LLM-as-a-judge is useful when quality is harder to check with code.

For example:

Is the summary useful?
Is the answer grounded in the source?
Did it answer the actual user question?
Is the response coherent?
Did it hallucinate?

This is useful for subjective outputs, but it should still be used carefully.

3) Human evaluation

Human evaluation still matters.
Especially for:
high-stakes workflows
domain-specific tasks
safety-sensitive outputs
tone and usefulness
ambiguous answers

Sometimes the best evaluator is still a person who understands the real user and context.

Tests tell us if something passed

Tests are important.
They help us check whether the agent behaves correctly on known examples.

For example:

Question: “Show me total revenue for May”
Expected tool: run_sql_query
Expected behaviour: query revenue table
Expected output: grounded answer with a number

This gives us a way to catch regressions.

If we change the prompt, model, tool schema, or agent logic, we can run the same eval again and see what changed.

Traces show us what happened

Traces are equally important.
They tell us the story of the run.
For example:
User query
→ Router decision
→ Tool selected
→ Tool input
→ Tool output
→ Agent reasoning step
→ Final answer

A trace helps us see where things went wrong.

Maybe the router failed.
Maybe the tool returned bad data.
Maybe the LLM ignored the tool result.
Maybe the agent looped.
Maybe the answer was fine, but the path was too expensive.
Tests and traces work better together.

The main lesson

AI agents need both:
Tests to check expected behavior.
Traces to understand actual behavior.

Tests tell us whether something passed or failed.
Traces show us what happened.

Together, they make agents easier to debug, improve, and trust.

That is the direction I’m exploring more through projects like LoopGuard and Supabase Agent Eval Kit.

I’m still learning, but this area feels important because agents are not just prompt-in, answer-out systems. They are workflows.

And workflows need visibility.

AI Is Not Killing DevRel. It Is Making It 10x Bigger - My DevRel Uni Cohort 7 Reflection

Mahima Thacker — Wed, 03 Jun 2026 11:38:09 +0000

That is the one line I am taking with me after finishing DevRel Uni Cohort 7.

Before this cohort, I had a lot of questions in my head.

Will AI replace DevRel/other roles?
Are docs still important?
Do communities still matter?
What even is my role in all of this?

Five sessions later, I have answers.

And honestly, my whole way of thinking has shifted.

So let me share what I learned, what surprised me, and what I am taking forward.

TL;DR: All 5 Sessions in One Place

Session 1 - Bianca: The core of DevRel (sensemaking, storytelling, distribution, feedback loops) stays the same. But the audience, docs, content, and community are all changing because of AI.

Session 2 - Nader Dabit: Do not lock yourself into one title. Become a technologist. Keep learning, keep building, keep moving. The safest thing in tech is being adaptable.

Session 3 — Patrick Skinner: Speed without systems is chaos. Build a Brainlifting habit — learn daily, document what works, and keep your knowledge system alive.

Session 4 — Hassan El Mghari: Developer Experience is not enough anymore. Agent Experience is the new frontier. Your docs need to be readable by humans AND AI agents.

Session 5 — Francesco Andreolí: DevRel is becoming more important, not less. GEO is the new SEO. Build systems that help both humans and agents grow your ecosystem.

One big theme connects all of them:

DevRel in the age of AI is not about doing less. It is about doing more, with better systems, for a bigger audience that now includes AI agents and LLMs.

> So the real skill is simple: be adaptable.

What Actually Changed for Me

Here is what shifted in my head:

1. My audience is not just developers anymore.
It is developers, founders, students, non-coders, and AI agents too. That changes everything about how I write, teach, and build.

2. Docs are not just for humans.
If ChatGPT or Claude cannot understand my docs, my product loses. Writing for LLMs is now part of the job. GEO (Generative Engine Optimization) is real.

3. I do not need to pick one identity forever.
Nader's line, "become a technologist", — broke something open for me. I was so worried about choosing the "right" path. Now I just want to keep learning and stay adaptable.

4. Speed is not the goal. Systems are.
Patrick's session hit hard. AI can make me 10x faster. But without systems for learning, documenting, and reviewing, I am just creating chaos faster.

5. Trust is still human.

This is the part that gave me peace. Sensemaking is human. Storytelling is human. Community is human. AI cannot replace any of that. It can only scale it.

What Surprised Me Most

Honestly? How much the human part of DevRel still matters.
I thought the whole cohort would be about new tools, new workflows, and new automations.

And yes, we covered all of that.

But every single mentor - Bianca, Nader, Patrick, Hassan, Francesco kept coming back to the same thing:

Taste. Judgment. Trust. Community.
You cannot automate those.
You can only build them by showing up, being honest, and helping people.
That surprised me. In a good way.

Two Sessions That Stuck With Me

Every session was valuable. But two of them keep playing in my head.
Nader's session on navigating a tech career.
Nader did not just give career advice. He gave a way of thinking about a career.

The line that stayed with me was: become a technologist.

Not a frontend developer. Not a DevRel. Not a content creator. A technologist.
Someone who learns what is needed, builds across domains, and adapts as the industry moves.

That reframe took the pressure off picking the "right" path. Because in tech, there is no right path. There is only the next move.

He also talked about how careers are not straight lines. They look messy in the moment. They only make sense looking back.

That gave me permission to experiment without needing a guaranteed outcome at every step.

Hassan's session on building apps and Agent Experience.
Hassan did not just talk about AI. He showed how he actually builds with it, coding agents, demo apps, documentation bots, internal tools, and automations.
It was not a theory. It was real workflows from someone shipping every week.

But the part that stuck was this:
He is not just building apps for users. He is building apps that help people learn, ship, and explore a product faster — with AI inside the workflow.

And the bigger idea, Agent Experience, changed how I think about my own work.
If a developer reads my docs, that is one user.
If an AI agent reads my docs and recommends my product to hundreds of developers, that is leverage.
So now I am not just asking, "Is my doc clear for a human?"
I am also asking, "Can an agent understand it well enough to actually act on it?"
That is a new lens. And it is hard to unsee once you see it.

How AI Changed The Way I Build and Learn

I was already using AI before this cohort.
So the shift was not "I started using AI."
It was "I started thinking about AI differently."
Before, I used AI to help me build.
Now, I also build for AI.
That is a small switch in words. But a big switch in mindset.

A few habits I picked up during the cohort:

I write docs that work for humans first, but I also check if an AI agent can understand them.
I think about how my content shows up in ChatGPT, Claude, and other AI tools, not just Google.
I build systems around my AI workflow, not just speed.
I treat AI as part of my audience, not just my toolkit.

AI does not give me ideas. It helps me move faster on the ideas I already have.
But the bigger unlock from this cohort was realising AI is also a reader, a learner, and a distributor of my work.
That changes everything.

What I Built During the Cohort

This cohort also pushed me to ship.
I worked on DriftGuard, a developer tool that came from a simple frustration:
SDK docs often drift from the actual code.
A docs example works at one point, then the SDK changes, and nobody notices until a developer tries it and it breaks.
That is painful.
So I shipped the first version of DriftGuard to npm.

npm install --save-dev @driftguardjs/cli

The idea is simple.
You point it at your SDK, snapshot once, and commit the baseline. Then every PR can check for broken doc snippets, removed exports, or changed signatures.

If something drifts, DriftGuard can fail the check and show the file and line where the issue happened.

It is still early, but building this during the cohort helped me connect the sessions to a real problem.
Because DevRel is not only about explaining things better.
It is also about reducing friction for developers.
And that is what I want DriftGuard to help with.

What I Am Taking Forward

A few things I am committing to after this cohort:

Build in public. Even when it feels small. Even when I am not an expert.
Write for both humans and agents. Every doc, every post, every README.
Build a learning loop. Learn, build, share, get feedback, repeat.
Keep my network warm. Not transactional. Just real.
Stop waiting to feel "ready." Move when the window opens.
Treat every day like Day 1.

Thank You, DevRel Uni

A huge thank you to Bianca and the entire DevRel Uni team for putting this together.

You did not just teach us frameworks.
You brought in mentors who have actually done the work.

And you created a space where we could ask honest questions and meet honest people.

I met so many incredible builders in this cohort.
People I know I will stay in touch with for a long time.
That alone made the whole thing worth it.
And to every mentor — Bianca, Nader, Patrick, Hassan, and Francesco, thank you for being so generous with your time and your truth.

If You Are Reading This

If you are even a little bit curious about DevRel, AI, or building developer ecosystems, join the next DevRel Uni Cohort.

You will not just learn frameworks.
You will meet your people.
And in the age of AI, that is the most valuable thing you can do.

The fundamentals of DevRel are not changing.
The tools are just getting 10x more powerful.

So learn AI.
Use it.
And become better at helping people build.

See you in the next chapter!

DriftGuard: catching when your code quietly breaks your docs

Mahima Thacker — Wed, 03 Jun 2026 09:36:49 +0000

if you've ever shipped an SDK update and then, three weeks later, a GitHub issue lands saying "the README example doesn't work," you'll recognize this problem.
The code changed. The docs didn't. Users hit broken snippets. You only find out from the angry messages.

I built DriftGuard because I kept seeing this in Web3 SDKs - contracts get upgraded, the TypeScript SDK evolves, but the docs and example apps lag behind. By the time someone reports it, a dozen users have already been confused.

What it is

DriftGuard is a CLI + GitHub Action that detects "drift" - when changes in one layer of your project break another layer. It runs in CI on every pull request and posts inline annotations at the exact line that broke.

It's not a doc generator like Mintlify. It doesn't write docs for you. It just makes sure the docs you already have stay accurate.

contracts ─┐
SDK ─┼─▶ DriftGuard ─▶ ✓ no drift PR passes
docs ─┤ ✗ drift found PR fails with file:line
demos ─┘

Who it's for

DevRel engineers maintaining SDK docs and example apps
SDK maintainers who ship breaking changes occasionally
Web3 teams with contracts + SDK + docs + demo repos to keep in sync
If your project has a public API and docs that show how to use it, DriftGuard probably helps.

What it actually checks

Four layers, all deterministic — no AI guessing:

1) Solidity contracts: Function/event added or removed, mutability tightened, parameter type changes

2) TypeScript SDK: Exports added/removed, signature changes, kind changes (function → class)

3)Docs: TypeScript code blocks in .md/.mdx get re-type-checked against the current SDK

4) Demos Optional: runs install + test in real demo projects to catch runtime drift

When a check fails, you get a GitHub annotation right at the file:line in the PR diff. The same finding appears in the workflow summary as Markdown and in a SARIF report for GitHub's code-scanning tab.

How it works

Two steps:

1) Snapshot — run driftguard snapshot once. It captures your contracts, SDK exports, and doc snippets in a normalized JSON file. Commit it.

2) Check — on every PR, driftguard check recomputes the same shapes and diffs against the committed snapshot. Differences become findings.
The snapshot is the approval mechanism. If you intentionally change your SDK signature, you re-run driftguard snapshot to update the baseline. The next check passes.

For doc snippets, the validation step is the interesting part. Each TypeScript code block in your README gets compiled against your current SDK using a path-mapped ts-morph Project. If your SDK changes a signature, the snippet that calls the old shape stops compiling — and the check fails at the line of the snippet in the markdown file.

Quick start

npm install --save-dev @driftguardjs/cli
npx driftguard init # writes a starter config (auto-detects what's in your project)
npx driftguard snapshot # captures the baseline
git add .driftguard/snapshot.json driftguard.config.ts
git commit -m "add driftguard"

Add to your CI workflow:

- uses: mahimathacker/driftguard@v0
  with:
    mode: check

That's the whole setup.

What I learned building it

Dogfooding catches bugs nothing else does. The first time I ran DriftGuard against its own repo, it produced 1500-character unreadable diffs — Zod schemas were expanding into huge inferred types. The code was correct. The output was unusable in a PR comment. No test would've caught this. I had to run the tool against itself to feel what a real user feels.

Bundling complex libraries doesn't always work. I spent two hours trying to bundle the GitHub Action into a single JavaScript file. Two libraries the tool uses (ts-morph and jiti) do runtime dynamic loading that no bundler can package cleanly. Eventually I gave up and made the action just install the CLI from npm at runtime. The simpler approach turned out to be the right one.

How AI shaped the workflow:

AI was fast at two specific things:

Architecture decisions before they became regrets — content-hash IDs for doc snippets (instead of line numbers, which break when you add a paragraph above), lenient-by-default snapshots (so users can adopt the tool without first fixing every broken example), syntactic types over inferred types in the diff output.

Diagnosing CI output — when a test PR didn't render annotations as expected, AI immediately pointed at "GitHub requires repo-relative paths, not absolute." That alone saved an hour of reading docs.
What AI didn't decide: when to stop polishing and ship. When to abandon the bundling path. What counts as a v0.1.0 blocker versus a v0.1.x polish item. Those judgment calls stayed with me.

Where to find it

npm: https://www.npmjs.com/package/@driftguardjs/cli
GitHub: https://github.com/mahimathacker/driftguard

Built as part of DevRel Uni Cohort 7. Next on the roadmap: Solidity snippet validation, AI-suggested fixes for broken snippets, and an MCP server so coding agents can query "what would break if I change X?" before they make the change.

If you try it on your own SDK, I'd love to hear what breaks first — issues or DMs both work.

You Changed One Line and Called It a Migration. Opus 4.8 Has Other Plans.

Mahima Thacker — Fri, 29 May 2026 11:25:25 +0000

What actually changes in your backend when you move from Claude Opus 4.7 to 4.8, the 9 things the benchmark screenshots don't tell you.

Most of us ran the same play this week: open the config, swap claude-opus-4-7 for claude-opus-4-8, redeploy, see the request come back 200, move on.

The API contract didn't break, so it felt finished. It wasn't.

Anthropic's migration guide says code that ran on 4.7 keeps running on 4.8 with no changes, and that's true, but it's a statement about the request format, not about behavior.

Your output lengths, token bills, tool-call counts, retries, and where your agent decides to stop can all shift without a single error code.

So for anyone running Opus in production, 4.8 reads less like a "smarter model" headline and more like a list of changed defaults you should check before trusting it with real traffic.

Here's that list:

1. What "no breaking changes" actually covers

It covers the call succeeding. That's about it.
The same prompt can come back longer or shorter, spend more or fewer thinking tokens, call tools more or less often, and cost more or less per request, all while returning 200. If the only thing you checked after the swap is that the endpoint still responds, you haven't really tested the upgrade yet.

2. The effort default quietly dropped from xhigh to high

This is the one most likely to catch you, and almost nobody's mentioning it.

On Opus 4.7 the default effort was xhigh. On 4.8 it's high, on every surface, API and Claude Code included. If you upgrade and change nothing, your high-autonomy and coding agents may now reason less by default than they did the day before.

It's not a regression. high is Anthropic's chosen balance of quality and cost, and they recommend setting xhigh yourself for coding and agentic work. But it's still a behavior change riding along inside a "no breaking changes" release, and the only way you'll notice is by looking.

Two things worth knowing when you set it:

effort goes in output_config, not inside thinking. Put it in the wrong place and you get a validation error rather than a silent fallback.

xhigh isn't new in 4.8. It shipped with 4.7, where it was the default. The change in 4.8 is that you now have to ask for it.

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,                    # leave room to think + act
    output_config={"effort": "xhigh"},   # not inside `thinking`
    messages=[...],
)

The levels run low, medium, high (default), xhigh, max. Use xhigh for coding and long-running agents, step down to medium or low for cheap simple calls, and reach for max only when your own evals show it buys you something over xhigh, since it spends tokens with no ceiling.

3. Adaptive thinking is something you turn on

A common misread is that 4.8 "thinks adaptively now" out of the box. It doesn't. Adaptive thinking is a mode you enable with thinking: {type: "adaptive"}, and it's off until you set it. Once it's on, the model decides per turn whether a step needs real reasoning or a direct answer.

This matters because agent loops mix trivial steps and hard ones. "Read this file" and "refactor this module under these three constraints" don't deserve the same thinking budget, and without adaptive thinking you were often paying for deep reasoning on the trivial steps anyway. With it enabled, 4.8 wastes fewer thinking tokens than 4.7 did at the same effort level.

At high (the default) and max, the model will almost always think. At lower levels it may skip thinking on easy turns. Effort and adaptive thinking are separate knobs that interact, so it's worth setting both deliberately rather than leaving one on its default.

4. 1M context is the default.

That's not a reason to stop retrieving.
Opus 4.8 serves the full 1M-token window by default now, with no beta header and no long-context surcharge. If your client still sends an old context-window beta header for backward compatibility, you can drop it.

What the bigger window doesn't fix: noisy retrieval, duplicate files, stale context, sloppy chunking, missing citations, slow prompts, or a bill that quietly tripled because you started stuffing whole repos into every call.

5. The change you'll actually feel is tool behaviour

If there's one capability improvement to care about, it's this.

Anthropic calls out two things in 4.8: better tool triggering (the model is less likely to skip a tool call the task needed, which some 4.7 users ran into) and better compaction handling (long agentic runs stay on task with fewer derailments after the context gets compacted).

In practice, production agents don't usually fail because the model is dumb. They fail like this:

it should have read the file, but guessed
it should have run the tests, but skipped them
it should have called the API, but assumed the result
it had the constraint earlier in the session, then drifted off it

4.8 is aimed at that class of failure. For agent systems, raw intelligence was rarely the limiting factor. Picking the right tool, calling it at the right moment, using the result, and not losing the thread after compaction is most of what decides whether the thing works, and that's hard to read off a benchmark table but easy to feel in a long session.

6. System messages mid-conversation

Opus 4.8 accepts role: "system" messages placed immediately after a user turn in the messages array (there are placement rules). Earlier models, 4.7 included, rejected that with a 400.

It looks minor and it isn't, because it gives you a way to re-steer a running agent without rebuilding the whole prompt history. The agent is halfway through a refactor, tests start failing, your harness drops in a system entry like "fix the failing tests before continuing," and the agent adjusts.

Since you're not rewriting earlier turns, you keep your prompt-cache hits. Use the top-level system field for instructions that apply from the start, and in-array system messages for course corrections during the run.

7. Prompt caching now works for shorter prompts

The minimum cacheable prompt length on 4.8 dropped to 1,024 tokens, down from 4.7's higher threshold. Prompts that were too short to cache before will cache now, with no code change.

It's worth a few minutes to split the stable parts of your prompt from the dynamic ones so the cache actually earns its keep:

stable, cache it: system prompt, tool definitions, repo map, schemas, policy text
dynamic, don't: the user's question, retrieved chunks, latest tool output

Easy to skip in a demo, expensive to skip in production.

8. Same sticker price, different real cost

Standard pricing is unchanged from 4.7: $5 / $25 per million input/output tokens. But the sticker price isn't the bill. What you actually pay depends on effort level, context size, output length, tool calls, retries, cache hits, and batch usage.

There's also fast mode (research preview, Claude API, speed: "fast"): up to about 2.5x the output tokens per second from the same model, at $10 / $50 per million. Worth being precise here, because it's easy to misread: fast mode is a premium, roughly 2x the standard rate, not a discount. It's only cheaper compared to fast mode on the older 4.6/4.7 models, which ran $30 / $150.

The honest framing is that fast mode finally costs something reasonable for latency-critical paths, not that it got cheap.

The real cost decision is routing: which requests need 4.8, which can go to a smaller model, which run in batch, which justify fast mode.

9. Don't let "new model, must be better" replace your evals

This is the part I'd argue for hardest, and the rest of this post is why. Each change above is a thing to actually measure on your own workload before you trust 4.8 with production traffic:

The effort drop (§2): compare your hardest agent task at high vs xhigh. If you upgraded and left the default, did reasoning depth or token use quietly fall?

tool triggering (§5): count skipped-but-needed tool calls across your agent traces, 4.7 vs 4.8. This is the one most likely to have improved, so it's the one worth proving.

caching (§7): did your cache hit-rate change now that the floor is 1,024 tokens?

cost and latency (§8): track output tokens, tool-call counts, retries, and p95, and watch which direction each moved.

The question isn't whether 4.8 is better in the abstract. It's whether it's better for your workload under your cost and latency budget, and that's the one your evals can answer.

Bottom line

For casual chat, 4.8 just feels like a slightly better Claude. For anyone building agents, coding tools, RAG, or automation, the interesting changes aren't in the headline number.

They're in the defaults and primitives: opt-in adaptive thinking, the effort default moving back to high,fewer skipped tool calls, calmer long-running agents, 1M context by default, mid-conversation system messages, a lower cache floor, and fast-mode pricing that makes more sense than it used to.

So treat the model swap as the first step, not the whole job. Re-set xhigh for your agents before you forget, re-baseline your prompt caching, and run your evals before you flip production over, not after the bill shows up.

If you've already done the 4.7 to 4.8 move and hit something I didn't list here, leave it in the comments. The silent-default stuff is usually what you only find out the hard way.

Sources: Anthropic's Opus 4.8 migration guide, the Effort and Adaptive Thinking API docs, and the Opus 4.8 announcement (May 28, 2026).

Decentralized Finance Part 4: Real World Assets Meet DeFi

Mahima Thacker — Fri, 29 May 2026 08:40:19 +0000

What if you could earn rent from a house you don’t own, in a country you’ve never been to, using an app on your phone?

That’s the power of real-world assets in DeFi.

What Are Real World Assets (RWA)?

Real World Assets are things that exist outside the blockchain.

Examples:

Houses
Company shares
Government bonds
Invoices
Art or collectibles

These things are now being linked to DeFi through tokenization.

This means creating a digital version of a real asset, which can then be traded or used inside smart contracts.

Why Should We Care?

Tokenized real world assets open up new investment opportunities, making high-value assets more accessible to everyone. They bring much-needed liquidity to traditionally hard-to-sell assets, allowing for quicker transactions. The transparency and security of blockchain technology reduce fraud and build trust. Plus, integrating RWAs with DeFi creates innovative financial products and services, building a more inclusive, efficient, and transparent financial system for all, and more...

RWA Needs an On-Chain Connection

Real world assets live outside the blockchain.

To use them inside DeFi, we need a way to connect them to smart contracts.

This means creating a bridge between the physical world and the digital one.

Someone needs to verify the asset, hold it safely, and create a digital version of it on-chain.

That digital token is what DeFi apps can then use for trading, lending, borrowing, or earning.

Without this connection, real-world assets cannot interact with DeFi tools. The token must reflect the real thing clearly and must be backed by trust.

You Can Make These TODAY!

The exciting part is that tokenizing real-world assets isn't just for big corporations or tech gurus. With the right platforms and knowledge, individuals and businesses can also participate in creating these digital representations of physical assets today. The process generally involves a few key steps.

First, the real-world asset needs to be legally verified and appraised to determine its value and ownership. This is a crucial step to ensure that the digital token accurately reflects the physical asset. Once verified, the asset is then 'tokenized' on a blockchain.

This means a smart contract is created that represents the asset, and digital tokens are issued. These tokens can then be bought, sold, or traded on various blockchain platforms. While it might sound complex, many platforms are emerging that simplify this process, making it more accessible for a wider audience. This means that the potential for bringing real-world value onto the blockchain is immense, and it's happening right now, opening up new avenues for investment and ownership.

Key Benefits of RWA + DeFi

1. New Investment Opportunities: Tokenized real-world assets make high-value assets (like real estate, art, etc.) more accessible to everyone, lowering the barrier to entry for investments.
Increased Liquidity: Traditionally illiquid assets can be bought and sold almost instantly on a global market, allowing for quicker transactions and easier access to asset value.
Enhanced Transparency and Security: Blockchain technology ensures that every transaction is recorded on an immutable ledger, reducing fraud and increasing trust in asset ownership and transfer.
Innovative Financial Products: The integration of RWAs with DeFi platforms enables new financial services, such as using tokenized real estate as collateral for loans or participating in decentralized exchanges with real-world backed assets.

Popular RWA Projects in DeFi

Centrifuge - Brings real-world loans (like invoices) to DeFi

Goldfinch - Offers loans to real businesses in emerging markets

Maple - Lets institutions borrow on-chain

Ondo - Tokenizes US Treasuries for yield

Challenges to Watch:

Legal rules are not clear yet
Need for trusted middlemen to hold the real asset
Hard to scale across countries
Price feeds and real-world data must be accurate
Final Thoughts

Real World Assets will bring real growth to DeFi.

They connect blockchain to the world we live in.

And they give DeFi a chance to solve real problems, not just trade tokens.

Decentralized Finance Part 3: The Complete Guide to Stablecoins

Mahima Thacker — Fri, 29 May 2026 07:19:31 +0000

The Problem That Started It All

Imagine you bought a cup of coffee with Bitcoin six months ago. Back then, it cost you 0.0001 BTC. Today, that same amount of Bitcoin could buy you either half a cup or three cups, depending on Bitcoin's wild price swings. But if you paid with dollars six months ago and pay with dollars today, you'd pay roughly the same amount. This is the fundamental problem that stablecoins solve.

What Are Stablecoins?

Most people think stablecoins are simply "non-volatile crypto assets." This definition is wrong.

The correct definition: A stablecoin is a crypto asset whose buying power fluctuates very little relative to the rest of the market.

The keyword here is "buying power." It's not about price stability, it's about purchasing power stability. A stablecoin should let you buy roughly the same amount of goods today as you could yesterday, next week, or next month.

Why Do We Care About Stablecoins?

Money serves three critical functions, and understanding these explains why stablecoins matter:

1. Store of Value

Money should preserve your wealth over time. When you save money in a bank or invest in stocks, you expect it to maintain its purchasing power. Volatile assets like Bitcoin fail at this because your wealth can disappear overnight.

2. Unit of Account

Money should help us measure how valuable something is. We price Bitcoin in dollars, not the other way around, because Bitcoin's constant price changes make it a poor measuring stick. Nobody wants to price their business in Bitcoin when it could be worth 50% less tomorrow.

3. Medium of Exchange

Money should facilitate transactions. While you can technically buy groceries with Bitcoin, most people won't because they don't want to spend an asset that might double in value next week.

The Web3 Money Problem: Ethereum works great as a store of value and medium of exchange, but fails as a unit of account due to its volatile nature. We need Web3 money that can do all three functions reliably

Categories and Properties of Stablecoins

1. Relative Stability: Pegged/Anchored or Floating

Pegged Stablecoins: These are tied to another asset's value. Most popular stablecoins fall into this category:

Tether (USDT): 1 USDT = 1 USD

USD Coin (USDC): 1 USDC = 1 USD

Floating Stablecoins: These maintain stable buying power without being tied to any specific asset. Think of it this way: if you could buy 10 apples with 10 dollars five years ago, but today you can only buy 5 apples with 10 dollars due to inflation, a floating stablecoin would adjust so you can still buy 10 apples with the same amount.

Anchored Stablecoins: These are pegged to a specific reference point that moves over time. Think of it like measuring ocean levels, where the anchor point itself changes but the relationship remains stable.

2. Stability Method: Governed vs Algorithmic

This refers to who or what controls the minting and burning of stablecoins to maintain their peg.

Governed Stablecoins: Humans or organizations decide when to create or destroy tokens. These are typically centralized:

A government entity

A company (like Circle for USDC)

A decentralized autonomous organization (DAO)

Algorithmic Stablecoins: Smart contracts automatically mint and burn tokens based on predetermined rules. No human intervention required:

DAI (partially algorithmic)

FRAX

RAI

UST (failed example)

3. Collateral Type: Endogenous vs Exogenous

This describes what backs the stablecoin's value.

Exogenous Collateral: Backed by assets outside the stablecoin's ecosystem:

USDC is backed by US dollars

DAI is backed by ETH, USDC, and other external assets

If these stablecoins fail, their underlying collateral (dollars, ETH) continues to exist and function.

Endogenous Collateral: Backed by assets within the same ecosystem:

UST was backed by LUNA tokens

If UST failed, LUNA would fail too (which actually happened)

The relationship creates a reflexive loop where the stablecoin and its collateral depend on each other for value.

The Endogenous Dilemma

Endogenous collateral sounds risky, so why use it at all?

The Answer: Capital Efficiency

With exogenous stablecoins like USDC, you need to over-collateralize. To mint $100 worth of DAI, you might need to deposit $150 worth of ETH. This ties up a lot of capital.

Endogenous stablecoins can theoretically operate with zero external collateral because they're backed by their own ecosystem. This makes them highly capital efficient but also highly risky.

Summary of Popular Stablecoins

Check out these visuals to understand how some of the most well-known stablecoins are built and how they work

(DAI StableCoin)

(USDC StableCoin)

(RAI StableCoin)

What Stablecoins Really Do

Beyond just maintaining stable value, stablecoins serve as:

Financial Infrastructure: They enable DeFi protocols to function with predictable unit pricing.

Bridge Between Traditional and Crypto: They allow seamless movement between fiat and crypto worlds.

Yield Generation: Many stablecoins can be staked or lent to earn interest.

Global Access: They provide dollar-equivalent access to people in countries with unstable currencies.

Which Stablecoins Are Good?

For Safety and Reliability:

USDC: Highly regulated, transparent reserves

DAI: Decentralized, over-collateralized, battle-tested

For Innovation:

RAI: Truly algorithmic, not pegged to fiat

FRAX: Hybrid model balancing efficiency and stability

Trade-offs to Consider:

Centralized stablecoins (USDC) offer stability but can be frozen or regulated

Decentralized stablecoins (DAI, RAI) offer censorship resistance but may have slight fees and complexity

Algorithmic stablecoins offer capital efficiency but carry higher risks

The Future of Stablecoins

The stablecoin landscape continues evolving as projects balance three competing priorities:

Stability - Maintaining purchasing power

Decentralization - Avoiding central points of failure

Capital Efficiency - Maximizing utility of locked assets

The most successful stablecoins will likely be those that find the optimal balance between these three factors while serving the core functions of money in the digital age.

Before you use or build with stablecoins, take the time to understand how they’re designed. The more you know, the better decisions you’ll make in the Web3 world.

Decentralized Finance Part 2: Money Markets

Mahima Thacker — Fri, 29 May 2026 07:10:24 +0000

Banks have controlled lending and borrowing for centuries. They decide who gets loans, set the interest rates, and hold all the power. If your credit score isn't perfect or you don't have the right paperwork, you're out of luck.

DeFi Money Markets flip this system completely upside down.

No credit checks. No paperwork. No waiting weeks for approval.

Just deposit your crypto as collateral, and borrow instantly. The smart contract handles everything else.

What Are DeFi Money Markets?

DeFi money markets are lending platforms built on smart contracts.

They allow users to:

Lend crypto and earn interest - Deposit your tokens and get paid for lending them out

Borrow crypto and pay interest - Put up collateral and borrow different tokens

The most popular platforms include Aave, Compound, and others.

But here’s the catch:

You can’t borrow unless you first deposit something valuable.

This is called collateral.

Traditional Borrowing vs DeFi

In traditional loans, you get money based on:

Your salary

Credit score

Personal background

In DeFi, none of that matters.

The only thing that matters is how much you deposit as collateral.

How Collateral-Based Borrowing Works

The Collateral System

In DeFi, collateral is your security deposit. It's like leaving your car keys with a friend when you borrow their bike. If you don't return the bike, they keep your keys.

Here's a simple example:

You deposit 1,000 USDC as collateral

You can then borrow 800 DAI (or ETH worth $800)

You can't borrow more than you deposited

Your collateral stays locked until you repay the loan

DeFi Money Markets Glossary

Collateral

The crypto you deposit as security to borrow other tokens. If you deposit 1 ETH to a protocol, your collateral is 1 ETH.

Loan-to-Value (LTV) Ratio

LTV determines how much you can borrow compared to your collateral value. It's expressed as a percentage.

Example with 75% LTV:

You deposit 1 ETH worth $1,000 as collateral

You can borrow up to 0.75 ETH worth of other tokens (or $750 worth)

The protocol keeps 25% as a safety buffer

Different tokens have different LTV ratios based on their stability and risk.

The Liquidation Threshold

Liquidation happens when your borrowed amount becomes too risky compared to your collateral. It's the protocol's way of protecting itself and other users.

Common triggers:

Your collateral drops in value (ETH price falls)

Your borrowed asset rises in value (borrowed token pumps)

You borrow too close to your limit

How Liquidation Works

When you cross the liquidation threshold:

Liquidators step in - These are users who "buy" your debt

You pay a penalty - Usually 5-10% of your collateral value

Your collateral gets sold - To cover the borrowed amount

You keep the rest - Any remaining collateral after paying debt and penalty

The warning system: Most protocols show you a "health factor" that warns you before liquidation happens.

Annual Percentage Yield (APY)

The yearly return on your investment, including compound interest. If you earn 10% APY, your money grows by 10% over one year with compounding.

Annual Percentage Rate (APR)

The yearly cost of borrowing without compound interest. If you pay 8% APR, you pay 8% interest over one year on the original loan amount.

Receipt Token

A special token you receive when depositing into a protocol. It's like a receipt that proves you deposited funds. These tokens are minted when you deposit and burned when you withdraw.

Reserve/Underlying Asset

The actual token you deposited into the protocol. For example, if you deposit ETH into AAVE, WETH is the underlying token, and you receive aWETH receipt tokens.

Key Benefits of DeFi Money Markets

For Lenders:

Earn passive income on idle crypto

No minimum deposit requirements

Withdraw anytime (subject to liquidity)

Transparent interest rates

For Borrowers:

No credit checks or paperwork

Instant loan approval

Keep your crypto exposure while borrowing

Access to leverage trading strategies

Popular DeFi Money Market Protocols

AAVE: The largest lending protocol with innovative features like flash loans and rate switching.

Compound: Pioneer in DeFi lending with simple, reliable mechanics.

MakerDAO: Focused on DAI stablecoin creation through collateralized debt positions.

Conclusion

DeFi money markets represent a fundamental shift in how we think about lending and borrowing. They remove gatekeepers, reduce costs, and provide global access to financial services.

The power is now in your hands. No banker can reject your loan application. No credit agency can block your access. Just you, your crypto, and the smart contract.

But with great power comes great responsibility. Understanding collateral, liquidation, and risk management is essential before diving in

Decentralized Finance Part 1: Understanding DEXs and AMMs

Mahima Thacker — Fri, 29 May 2026 07:05:57 +0000

A few years ago, if you wanted to buy or sell crypto, you had to go through a central exchange. You'd sign up, verify your identity, and trust the platform to keep your money safe.

Then came Decentralized Exchanges (DEXs), a new way to trade crypto without giving up control.

No sign-ups. No middlemen. No waiting for someone on the other side.

Just you, a wallet, and a smart contract.

This is the revolutionary promise of Decentralized Finance (DeFi), where smart contracts handle everything automatically. Today, we'll explore the foundation of DeFi: Decentralized Exchanges (DEXs) and the magic behind them

What is a Decentralized Exchange (DEX)?

A Decentralized Exchange (DEX) lets you trade one token for another, directly from your wallet. There’s no company holding your money. Instead, smart contracts handle everything.

You connect your wallet. You choose what you want to swap. And the trade happens instantly.

How Does a DEX Actually Work?

Let's break down the key components that make DEXs possible:

1. Liquidity Pools

A liquidity pool is like a jar filled with two tokens. For example:

50 ETH and

10,000 DAI

People add their tokens to these pools. These people are called liquidity providers, and they earn small fees from every trade that happens.

2. Swapping

You want to swap your DAI for ETH?

The smart contract pulls ETH from the pool and adds your DAI to it.

The price changes based on how much you take and how much you give.

3. Automated Market Maker (AMM): The Price Calculator

Here's where it gets interesting. Instead of matching you with another trader (like in traditional markets), an AMM uses a mathematical formula to determine prices instantly. It's like having a calculator that always knows the fair price based on how much of each token is in the pool.

4. Small Fees, Big Rewards

Every trade pays a small fee (typically 0.3%). This fee gets distributed among all the people who provided liquidity to that pool. It's like getting a cut of every transaction just for helping keep the marketplace running.

Understanding Liquidity and Why It Matters

What is Liquidity? Liquidity is simply having enough tokens in a pool to make trading smooth and efficient. Think of it like having enough cash in your wallet to buy coffee without needing to break a $100 bill.

Why Do We Need It? Without enough liquidity, strange things happen:

Trades become slow and expensive

Prices swing wildly with small purchases

Large trades become nearly impossible

Who Benefits?

Traders get fast, reliable swaps

Liquidity providers earn passive income from fees

The entire ecosystem stays healthy and functional

Examples of Popular DEXs

PancakeSwap - Built on Binance Smart Chain. Fast and great for beginners.

SushiSwap - Available on many chains. It rewards people who add liquidity.

There are many more. Each one has its own pools, tokens, and features.

DEX vs CEX: Choose Your Adventure

Centralized Exchange (CEX):

Requires account creation and identity verification

Company holds your funds

Easy to use with familiar interfaces

Customer support available

Decentralized Exchange (DEX):

No signup required

You always control your funds

More privacy and anonymity

Full responsibility for your own security

The Bottom Line: Want complete control and privacy? Go with a DEX. Prefer simplicity and support? Choose a CEX.

How Automated Market Makers Work

An Automated Market Maker (AMM) is a smart contract that lets you swap tokens without needing someone else on the other side.

Let’s Break Down the Formula

X × Y = K
X = Amount of Token 1 in the pool
Y = Amount of Token 2 in the pool
K = A constant number that never changes

Think of K as the pool's "balance point." No matter how much trading happens, the formula ensures X × Y always equals K.

A Real-World Example

Let's say we have a pool with:

50 ETH (Token 1)
10,000 DAI (Token 2)
K = 50 × 10,000 = 500,000

Now imagine you want to buy 1 ETH using DAI.

After your trade:

ETH remaining = 49 (you took 1 ETH out)
To keep K = 500,000, we need: 49 × Y = 500,000
Y = 500,000 ÷ 49 = 10,204.08 DAI

Since the pool started with 10,000 DAI and needs 10,204.08 DAI after your trade, you must add 204.08 DAI to buy 1 ETH.

The price was calculated automatically by the formula, not by a person!

Why Prices Change as You Trade:

Here's where it gets interesting. The more ETH you try to buy, the more DAI you need to add to keep K constant. This makes each additional ETH more expensive.

Example:

Buying 1 ETH costs ~204 DAI

Buying 2 ETH would cost even more per ETH

Buying 10 ETH would be extremely expensive per ETH

This price increase is called "slippage," and it's completely normal in AMMs. It prevents any single person from draining the entire pool

This price jump is called slippage, the more you buy, the more you pay.

AMM vs Order Book

Order Book (used by CEX): Buyers and sellers agree on a price

AMM (used by DEX): The price is decided by a formula

In AMMs, you don’t wait for someone to match your trade.

The pool is always ready, the formula handles everything.

Key Takeaways

DEXs eliminate middlemen - You trade directly through smart contracts

Liquidity pools are the foundation - They provide the tokens needed for smooth trading

AMMs use simple math - The X × Y = K formula determines all prices

Everyone benefits - Traders get instant swaps, providers earn fees

You stay in control - Your funds never leave your wallet

In Part 2, we'll explore money markets