DEV Community: Jonathan Murray

Plausible Code Is the New Technical Debt

Jonathan Murray — Thu, 02 Apr 2026 02:33:26 +0000

I have a take that is going to annoy two groups of people at the same time:

The “real engineers don’t use AI” crowd
The “AI wrote my whole app” crowd

Here it is:

If AI is in your workflow, your codebase is now a human factors problem.

Not a model problem.

Not a prompt problem.

A human problem.

Because the hardest part is no longer generating code.

The hardest part is knowing what to trust, what to delete, what to keep, and what you are willing to be responsible for at 2:00 AM when prod is on fire and the person who “helped” is a chat bubble with no pager.

The new sin is not bad code. It’s unowned code.

AI makes it easy to produce code that looks plausible.

That’s the trap.

Plausible is not correct. Plausible is not maintainable. Plausible is not secure. Plausible is not even consistent with your repo.

Plausible just means your brain gets a quick dopamine hit and says: “ship it.”

So here’s the controversial thing I think we should start saying out loud:

If you did not read it, you did not write it.

If you did not write it, you do not own it.

If you do not own it, it does not belong in main.

That’s not anti-AI. That’s pro-software.

“But I can read it later”

No you won’t.

You will merge it while it’s fresh. Then a week later you will forget you even asked for it. Then three months later it will fail in a weird edge case and you will be in a code archaeology session, scrolling through a file full of polite variable names and zero intent.

AI code has a smell.

Not because it is always bad.

Because it often has no story.

Human-written code usually has fingerprints:

slightly annoying but consistent naming
weird shortcuts taken for a specific reason
comments that reflect real pain
a mental model that shows up across files

AI code often looks clean but detached, like it was written by someone who will never have to maintain it.

Which is true.

The real cost is not bugs. It’s ambiguity.

Bugs are normal. We have tests. We have monitoring. We have rollbacks.

Ambiguity is poison.

Ambiguity is when you can’t tell:

what the function is supposed to guarantee
what failure looks like
what the invariants are
why a decision was made
what tradeoff was chosen

AI generates code faster than it generates intent.

So if you are using AI and you are not also increasing clarity, you are building a repo that will eventually punish you.

The “AI pair programmer” fantasy is incomplete

Most devs use AI like a hyperactive junior.

“Write me a thing.”

It writes a thing.

You merge the thing.

That is not pairing.

Pairing is: reasoning out loud, constraints, tradeoffs, and a shared model of the system.

So the only way AI becomes a legitimate pair is if you force it to act like one.

Which means you need to change what you ask for.

Instead of: “write the code”

Ask:

“Before you write anything, tell me what you think I’m trying to do.”
“List assumptions you are making about the system.”
“Propose 2 approaches and argue for one.”
“Tell me how this fails.”
“Write tests first.”
“Show me the minimal diff that gets us there.”

If the tool cannot explain itself, it is not helping. It is performing.

A rule that saved me from shipping garbage

I started doing something that feels almost too simple:

Every AI-generated change must come with a receipt.

Not a comment block of fluff.

A receipt like:

What problem is this solving, in one sentence?
What are the inputs and outputs, explicitly?
What are the invariants?
What are the failure modes?
What tests prove it?
What did we choose not to do, and why?

If I cannot answer those, I do not merge.

Because I know what happens otherwise.

I get fast today and slow forever.

“This is just good engineering, nothing new”

Exactly.

That’s the point.

AI did not change what good engineering is.

It changed how easy it is to accidentally do bad engineering.

It lowered the effort required to create complexity.

So we need friction in the right places.

Not bureaucracy.

Friction that forces ownership.

Practical patterns (non-hype, actually usable)

Here are a few patterns that make AI helpful without letting it rot your repo:

Use it for diffs, not features

Ask for the smallest change that moves you forward, then iterate.

Make it write tests and edge cases

Not because it’s perfect, but because it will often suggest failure modes you forgot to consider.

Make it explain the code to you like you are tired

If it can’t do that, it’s too complex or too hand-wavy to merge.

Keep a “kill switch” mindset

Prefer designs you can remove in one commit if it turns out to be wrong.

Treat generated code as untrusted input

Same posture as copy-pasting from Stack Overflow, but faster and more frequent.

The part people avoid: responsibility

This is the emotional part for me.

A lot of us got into software because it felt like a clean meritocracy: you ship, it works, you win.

AI blurs the line between “I built this” and “I assembled this.”

That can mess with your identity.

So some devs swing into denial: “I don’t use it, I’m pure.”

Other devs swing into cosplay: “AI built everything, I’m 10x.”

Both are insecurity.

The mature posture is boring:

Use it. Verify it. Own it.

Your future self will thank you.

A question I want to ask the Dev.to crowd

What is your “AI code ownership” rule right now?

Do you have a hard line like “no generated code without tests” or “no generated code without a design note”?

Or are you just vibing and hoping future you figures it out?

Touching grass with my niece and nephew at the park. It’s awesome.

Jonathan Murray — Sun, 29 Mar 2026 16:43:24 +0000

Just thinking about how many times I hear “I saw this TikTok post” or “I listened to this podcast” followed by …. “And so AI is failing and it’s dumb, womp womp womp.” Or “I heard Googles going to zero.” … Maybe let’s cut down the content consumption….

Jonathan Murray — Sun, 29 Mar 2026 03:03:19 +0000

You're Not Normal. That's the Point.

Jonathan Murray — Fri, 27 Mar 2026 21:20:47 +0000

It is Friday at 5pm and you are pretending to care about that last Slack message.

But your brain is already somewhere else.

You have been thinking about that side project all week. The one you scribble architecture for during standups. The one you "accidentally" have three tabs open for right now.

Here is something most people will never understand about you: you go home after a full day of building things, and then you build more things. For fun. On purpose.

That is not normal behavior. That is superhuman behavior.

You live in a world most people do not get. Some of your friends think "API" is a type of beer. Your family describes your job as "something with computers." And yet here you are, halfway between machine learning papers and Stack Overflow at midnight, quietly building the future while everyone else is watching Netflix.

And if you are reading this right now thinking "I never finish anything" -- relax. Most shipped products started as abandoned repos that someone came back to on a random Saturday because they could not sleep.

You are not behind. You are just loading.

The difference between a side project and a startup is about 3 weekends and one mass DM to your friends that says "hey can you test something for me, it will only take 2 minutes."

It will not take 2 minutes.

Here is what I have learned watching hundreds of builders at hackathons, in Discord servers, and across dev communities: the ones who ship are not the most talented. They are the ones who start before they are ready and ask for help before they are stuck.

That is it. That is the whole playbook.

But let me say this clearly: the world needs you. Not in a corny motivational poster way. In a real way.

We are living through the biggest technology shift most people will ever see, and the majority of the population does not understand what is happening. You do. That makes you rare. Do not take that for granted, and do not shame anyone who has not caught up yet.

Bring them along. That is what superhumans do.

A lot of the weekend builders I talk to are deep into AI right now. Building agents, adding memory to chatbots, wiring up RAG pipelines, trying to make their apps actually remember context instead of starting from scratch every conversation.

That is exactly why we built Backboard. It is the infrastructure layer for AI apps -- memory, state management, model routing, RAG, tool calls -- all through one API. No stitching five tools together. No losing your conversation history every time you swap models.

Here is the weekend deal: sign up and you get free state management for life plus free dev credits to play with. No catch. No trial that expires on a Tuesday when you forgot to cancel. Just go build something, break something, and let us know what you think.

We built this for weekend builders. Your feedback is literally how we get better.

So this weekend, if you ship something, tag me. If you break something, tag me faster. And if you spend the whole weekend staring at your IDE with a blank file open, just know -- that is also part of the process.

Have fun this weekend, super devs. See you on the other side of Sunday.

We Just Shipped What OpenAI, Google, and Anthropic Have Not. Here Are 6 Updates.

Jonathan Murray — Thu, 26 Mar 2026 18:49:06 +0000

This post is a tight walkthrough of 6 updates we just shipped at Backboard.io that directly target developer pain.

And we're thrilled to support the Major League Hacking or DEV community, so much so that we're going to offer an incredible perk. We're now releasing a free state management on Backboard for life tier (limited to state management features) plus $5 in dev credits (about one free month). No catch. No expiration on the state tier, powered by MLH.

This, combined with our existing BYOK feature means that every major platform's API is now stateful for free. OpenRouter, Anthropic, OpenAI, Cohere, stateful... free... yup, LFG.

Now, the actual shipping.

The 6 Updates

Adaptive context management: truncate, summarize, reshape, automatically.
Memory tiers: Light vs Pro for cost, latency, accuracy.
New navigation + organizations + docs overhaul: faster to build, fewer dead ends.
Custom memory orchestration per assistant: natural language rules for memory.
Manual memory search via API: inspect and query what your agent stored.
Portable parallel stateful tool calling: the orchestration layer nobody else ships.

If you only read one section, read #6.

1) Adaptive Context Management (Stop Losing the Plot)

Here is the crisis: context windows are finite, and your product is not.

When the thread gets long, most agents degrade quietly. They still answer confidently, but they are missing key facts. Developers respond by doing manual hacks:

truncating old messages
building their own summarizers
re-injecting user profile facts every time
praying the important stuff stays in the window

We shipped adaptive context management so your agent can truncate, summarize, and reshape the payload automatically before it hits the model.

That means:

less token waste
fewer hallucinations caused by missing history
better performance on long-running conversations
less custom logic in your app

Docs: Backboard docs

Hook for what is next: context control is useless if memory is too expensive or too slow. That is why we shipped tiers.

2) New Memory Versions: Light vs Pro (Cost, Latency, Accuracy)

Most teams hit this moment: you want memory everywhere, then you see the bill or feel the latency.

So we shipped two memory versions:

Memory Light

about 1/10th the cost and latency of Pro
still message level
built for teams that want speed and affordability without giving up persistent behavior

Memory Pro

highest accuracy and depth
built for use cases where memory precision matters and you do not want “close enough”

You choose what matters in each product stage: ship fast with Light, graduate to Pro where needed.

Docs: Backboard docs

Hook for what is next: a good memory system still fails if teams cannot find the right knobs quickly. So we rebuilt the surface area.

3) New Navigation, Organizations, and a Docs Overhaul (So You Can Actually Ship)

This one came from user feedback, directly.

Organizations

You can now create and manage organizations in the dashboard. Teams can collaborate in a structured workspace without awkward account sharing.

New navigation

We rebuilt navigation so you can get to what matters fast:

assistants
conversations
documents
memory
keys
settings

Documentation overhaul

We made the docs significantly more detailed. More examples, clearer architecture, and fewer “wait, what do I do next?” moments.

Docs: Backboard docs

Hook for what is next: even with great docs, memory still feels like a black box unless you can control the rules. That is the next shipment.

4) Custom Memory Orchestration (Per Assistant, Natural Language)

Most platforms give you memory as a feature.
We are treating memory as a system you can design.

We shipped the ability to define custom memory rules per assistant, using natural language.

When you create an assistant, you can now pass:

custom_fact_extraction_prompt (string)

Custom memory fact extraction prompt
custom_update_memory_prompt (string)

Custom memory update decisions prompt

This is the difference between:

“my assistant stores random stuff sometimes”
and “my assistant stores exactly what I consider durable, useful signal”

Examples of what this unlocks:

a support agent that remembers plan, product, and bugs, but ignores jokes
a sales agent that remembers stakeholders, objections, and timeline, not random chatter
a recruiting agent that remembers location, comp targets, and availability, and can justify updates

Docs: Backboard docs

Hook for what is next: once you let developers write memory rules, they will ask the obvious question: what did the agent store? So we shipped search.

5) Manual Memory Search via API (Stop Guessing What Your Agent Knows)

If you have ever tried to debug memory, you know the pain:

“why is it bringing that up?”
“why did it forget that?”
“did it store the wrong fact?”

We shipped the ability to manually search memory via the API.

This is useful for:

debugging and QA
internal tooling and admin dashboards
user-facing “what I remember about you” experiences
compliance workflows where you need to inspect stored data

In other words: memory becomes queryable, not mystical.

Docs: Backboard docs

Hook for what is next: memory is only half the battle. The other half is orchestration, tool calling, and state. This is where most agents break.

6) Portable Parallel Stateful Tool Calling (The Thing Big Providers Still Do Not Offer)

This is the upgrade that changes what “agent” even means.

As of right now, no major AI provider offers portable, parallel, stateful tool calling as a first-class capability.

We do.

Here is what that actually means, in plain terms.

Parallel

Your assistant can request multiple tool calls at the same time, each with a unique tool_call_id.

If the agent needs to:

query a CRM
pull docs
check a billing system
run a calculation

It does not have to do those serially. It can do them concurrently.

Stateful

The assistant keeps the chain of reasoning intact across:

tool calls
multiple rounds
parallel branches

That state does not live in your app code. You are not rebuilding workflow state machines in your backend.

Portable

That state is not trapped inside one provider’s ecosystem.
It travels with the assistant across environments and model choices.

Loop until COMPLETED

The assistant can chain tool calls across rounds and keep going until:

status == COMPLETED

It can do multi-step work without you stitching together glue code and polling loops.

This is the difference between:

“a chat that can call one tool”
and “a system that can actually execute a workflow”

Docs: Backboard docs

Hook for what is next: if you want a fast way to try this without over-committing, we made the on-ramp free.

Free State Management for Life (Powered by MLH and DEV)

We partnered with Major League Hacking and DEV because builders need a real environment to ship in, not a 7-day trial that ends mid-project.

Through the partnership, participants get:

Free state management on Backboard for life (limited to state management features)
$5 in dev credits (roughly one free month on the full platform)

If you are building at hackathons, hack weeks, or DEV challenges, this is meant to remove friction so you can focus on shipping.

Start here: Backboard.io

Docs here: Backboard docs

Why This Matters (If You Are Building Under Pressure)

If you are in an “information crisis” building AI products, it is usually not because you cannot prompt.
It is because you are drowning in:

context limits
memory ambiguity
orchestration glue
tool call complexity
state bugs

These six shipments are us taking that burden off your plate.

If you want help picking the right memory tier, designing orchestration prompts, or validating an agent workflow, build something small and send it to us. We are optimizing for builders who ship.

Backboard.io

Docs

I’m Learning AI in Public, and I Think Developers Need to Chill a Bit

Jonathan Murray — Tue, 24 Mar 2026 14:53:30 +0000

I’ve been going hard learning AI and tech. Building, breaking stuff, rebuilding it, reading docs at weird hours, trying to connect dots faster than my brain probably wants to.

And the deeper I get, the more I realize something that feels obvious once you see it:

Developers are standing insanely close to the bleeding edge right now.

So close that it messes with your perception of what “normal” is.

You start thinking everyone else is also tracking model releases, context windows, tool calling, evals, agents, RAG, and whatever brand new thing dropped this morning.

They’re not.

Not because they’re behind. Because they have lives. Jobs. Kids. Payroll. Customers. Stress. A million tabs open that have nothing to do with GPUs.

And if we want AI to actually create value in the world, we have to stop acting like the rest of the world is stupid for not keeping up with our group chat.

The moment this got real for me

I recently onboarded my dad to HelloNash.ai.

He’s 73.

And watching him use it was honestly one of the most fulfilling moments I’ve had with this whole AI journey so far.

He started researching our ancestry, going down rabbit holes, asking questions, connecting family dots. Then he used it to study for his drone pilot license. Like, properly studying. Making sense of things. Building confidence.

This is where I need developers to hear me clearly:

That is the point.

Not dunking on someone because they do not know what a context window is.
Not flexing that you “already knew” what agents were six months ago.
Not eye-rolling when someone asks a question that feels basic to you.

The real win is watching a regular person get more capable in their own life.

And if my 73-year-old dad can jump in and learn, then we have zero excuse to be gatekeepy about this stuff.

Developers forget how early we are

The trap is you learn fast, so you assume everyone else should too.

But you’re immersed. You’re living in it. You’re surrounded by people who talk like you. Your algorithm is feeding you the same memes and the same hot takes and the same “it’s over for everyone” threads.

Most people are not in that world. They’re not dumb. They’re not lazy. They’re just not in your niche.

And honestly, good for them.

So when a non-technical person says something like:

“Wait, so is ChatGPT the same as AI?”
“Can it remember me?”
“Is this safe for my business data?”
“Why did it answer confidently and still be wrong?”

That is not an invitation to act superior.

That is an invitation to lead.

Here’s the hard truth

If you want to provide value to people, you need other people.

If you want to build a company, you need customers, partners, teammates, champions inside organizations, and people who trust you enough to try the thing.

If you want to make money, you need adoption. Not developer applause.

Which means the goal is not to sound smart.
The goal is to make other people feel smart.

Because people do not adopt tools that make them feel dumb.

My new rule: assume the person is smart, and my explanation is the bottleneck

This is the biggest shift for me.

If someone does not get what I am saying, my first move is no longer “they are not technical.”

My first move is: “ok, I explained it like trash.”

Because if I actually understand something, I should be able to explain it without turning it into a TED Talk for machine learning people.

That does not mean watering it down. It means building a ramp.

I try to do three things:

1) Start with the problem, not the tech

Nobody wakes up excited to implement RAG. They wake up frustrated that the assistant forgot what they said yesterday or hallucinated a detail that matters.

2) Give one simple mental model

Context is short-term attention. Memory is notes you can look up later. That’s enough to get moving.

3) Show a real example

Not theory. Not vibes. An example that makes someone go “ohhhh ok.”

The stadium test

I think about this a lot: could I explain what I’m building to a stadium?

Not a room full of engineers. A stadium.

If you can keep a stadium with you, you can keep a market with you.

And here is how you keep them with you, every 30 to 60 seconds:

You say the thing they’re already thinking but are scared to ask.
You give an example that feels like their life.
You tell a quick story beat, not a lecture.
You give them something they can do next.

That’s not “marketing.” That’s just respect for attention.

Developers can be accidentally intimidating

I do not think most developers are trying to be arrogant.

But the pace, the jargon, and the confidence can land as intimidating.

And the result is people stop asking questions. They nod. They pretend. Then they go back to their team and say “yeah I don’t think we’re ready for AI.”

Not because they are not ready.

Because we made them feel stupid.

That is a massive unforced error.

If you’re early, your job is education

Not education like “I’m smarter than you.”
Education like “let me bring you with me.”

Because we are in an information crisis right now. People are trying to figure out what’s real, what’s hype, what’s safe, and what’s going to break their workflow or their job.

Clarity is kindness.

And patience is not optional if you actually want this to spread.

What I’m trying to optimize for

I’m still learning. I’m still building. I still get impatient sometimes. I still catch myself about to over-explain or flex for no reason.

But I’m trying to optimize for one thing:

Make AI feel usable to normal people.

Watching my dad light up because he can research ancestry and pass a drone license exam at 73 was a reminder that this is not about being the smartest person in the room.

It’s about making more people capable.

So if you’re a developer reading this, here’s my ask:

Check the ego at the door.

Be the bridge.

Because the builders who win this era will not just be the ones who can ship.

They’ll be the ones who can translate.

If you’ve been learning AI too, what is the one concept you wish someone would explain like a human, not like a doc page?

You’re Not Behind. You’re Panicking. Here’s the Fix.

Jonathan Murray — Tue, 17 Mar 2026 16:15:05 +0000

No one tells you this part.

They tell you your 20s are “for building.”
They tell you to “move fast.”
They tell you to “take risks.”

And somehow that turns into this quiet belief:

If it doesn’t happen soon, it won’t happen at all.

That belief is gasoline.
It powers late nights.
It powers ambition.
It powers shipping.

It also powers anxiety.

Because when you’re in your 20s, time doesn’t feel like time.

It feels like a countdown.

The clock isn’t real. But the pressure is.
You don’t wake up stressed because you’re lazy.
You wake up stressed because you care.

You want the thing to work.

You want to build something that matters.
You want to prove you weren’t delusional for trying.
You want momentum before you “fall behind.”

And it’s not even always about money.

Sometimes it’s about dignity.
Sometimes it’s about not wanting to go back.
Sometimes it’s about the fear of telling people:

“Yeah… I’m still working on it.”

That sentence hits harder than failure.

Social media compresses time.
You scroll.
You see a launch post.
A thread.
A product video.
A “day one to day thirty” screenshot.

And your brain does the math in the worst way possible.

They did it in a month.
Why haven’t I done it in a month?

They got traction overnight.
Why am I still fighting for five users?

They’re younger than me.
Why do I feel late?

Here’s what social media does.

It takes someone’s highlight reel…
and turns it into your deadline.

It makes you feel like you’re not building.
You’re losing.

I watched this happen in real time.
A friend launches their business on Instagram.

It looks perfect.
The branding hits.
The comments pour in.
Thousands of likes.
Reposts.
“Congrats!”
“Big things coming!”
“Proud of you!”

It looks like the moment.

Then that night, reality shows up.

The building needs a full electrical upgrade.
Not “later.”
Now.

And suddenly the budget is wrong.
The timeline is wrong.
The plan is wrong.

Now they’re staring at a choice that a lot of ambitious people make:

Delay for six months.
Do it responsibly.
Manage cash.
Fix the foundation.

Or…

Pay 2x the price.
Rush it.
Force the launch.
Because the internet already clapped.

Because the moment already happened.

Because backing up feels like embarrassment.

That fear is real.

The fear of missing the window.
The fear of losing attention.
The fear of people realizing you’re not as far as they think.

The fear of being ordinary again.

This is the trap: confusing attention with progress.
Likes are not leverage.
Reposts are not revenue.
Hype is not infrastructure.

The internet rewards the announcement.

But your life rewards the build.

And the build is quieter.
Slower.
Less aesthetic.

The build is:

fixing what broke
rewriting what you rushed
rebuilding what you “shipped” too early
doing the unsexy work you hoped you could skip
In dev terms:

You can demo the app in a weekend.
But you can’t fake scalability.
You can’t fake security.
You can’t fake reliability.
You can’t fake unit economics.

Reality is a load test you didn’t schedule.

“Running out of time” is usually “I’m scared I won’t matter.”
Let’s name it.

A lot of 20s anxiety isn’t about time.

It’s about identity.

It’s about the fear that you’ll try hard…
and still not become who you thought you’d become.

It’s about watching other people “win” publicly…
while you grind privately.

It’s about wondering if you missed your shot because you didn’t start at 16.
Or because you didn’t go viral.
Or because you didn’t move to the right city.
Or because you picked the wrong idea.

So every day feels urgent.

Because if it doesn’t work soon…

What does that say about me?

That’s the real fear.
Not time.

The truth nobody wants: you’re not late. You’re early in the boring part.
The boring part is where businesses are actually built.

Not in the “launch.”
In the follow-through.

Not in the first spike.
In the second month when nobody cares.

Not in the big win.
In compounding growth.

You don’t need a miracle.

You need reps.

You need enough small improvements that, six months from now, you look back and barely recognize your old output.

That’s the game.

Compounding.

Expect compounding growth. Not a cinematic breakthrough.
Your brain wants the big moment.
The switch-flip.
The overnight success.

That’s a great story.
It’s also a terrible plan.

Because when your plan depends on a big win, you become fragile.

One bad week breaks you.
One slow month convinces you it’s over.
One launch without traction feels like proof you’re not good enough.

Compounding is different.

Compounding is calm.

Compounding says:

ship one improvement
talk to one customer
write one page
fix one bottleneck
make one feature actually usable
make one distribution channel actually repeatable
Then do it again.
Then again.

It’s not glamorous.

It works.

Persistence doesn’t mean panic.
Let’s be clear.

“Don’t give up” doesn’t mean “rush.”
It doesn’t mean “burn your savings to keep up with the timeline you saw on TikTok.”
It doesn’t mean “pay 2x just so you can say you launched.”

Persistence is patient violence.

It’s the willingness to stay in it.
Without needing constant proof.
Without needing applause.
Without needing the moment to be public.

Persistence is choosing the responsible timeline even when your ego wants the dramatic one.

Because the goal isn’t to look like you’re winning.

The goal is to still be here when it finally works.

If you’re in your 20s, here’s what you can do this week.
Not “someday.”
This week.

Pick one thing to compound.

One.

Make it measurable.
Make it boring.
Make it repeatable.

Examples for ambitious dev founders:

Talk to 5 users. Write down the exact words they use.
Ship 1 improvement that reduces friction by 10%.
Write 1 sales page that explains the outcome, not the features.
Build 1 distribution habit: 1 post/day for 30 days, or 10 DMs/day, or 2 calls/week.
Fix onboarding so a new user gets value in 5 minutes, not 5 hours.
Then track it.

Not vibes.
Not motivation.

Track it like you track uptime.

And do it again next week.

You’re not behind. You’re building a foundation people can’t see.
That friend with the electrical upgrade?

That’s the real entrepreneur story.

Not the likes.
Not the reposts.

The moment where you realize:

If I rush this, I might win attention…
but lose the business.

If I slow down, I might feel embarrassed…
but I might actually survive.

Your 20s are full of these choices.

Attention vs. durability.
Speed vs. stability.
Ego vs. foundation.

The winners aren’t the people who never feel the pressure.

The winners are the people who feel it…
and don’t let it drive the car.

Comfort + motivation (the part you need to hear)
If you feel like you’re running out of time, you’re not broken.

You’re ambitious.

You’re awake.

You’re trying to build a life you actually want.
And that comes with pressure.

But you are not on a deadline set by the internet.

You’re on a timeline set by reality.

Reality rewards the person who can keep showing up.

So keep going.

Not recklessly.
Not performatively.

Responsibly.
Relentlessly.
Compounding.

One week at a time.

Because you don’t need overnight success.

You need to still be building when the overnight success finally shows up.

So cool, and terrifying at the same time!!!!

Jonathan Murray — Mon, 16 Mar 2026 20:33:43 +0000

Open-Sourcing VoxCast: CPU-Only Multi-Turn Podcast Generation With Low Memory Usage

Chris King ・ Mar 16

#ai #python #opensource #machinelearning

Backboard.io 新功能: 覆盖 17,000+ 模型的自动上下文窗口管理

Jonathan Murray — Sat, 14 Mar 2026 22:14:06 +0000

Backboard 现已推出 Adaptive Context Management（自适应上下文管理），这是一套内置系统，能够在你的应用在不同上下文窗口大小的 LLM 之间切换时，自动管理对话状态。

Backboard 平台可访问 17,000+ 个模型，因此模型切换非常常见。但不同模型的上下文上限差异巨大: 在一个模型里能放下的内容，切到另一个模型可能立刻溢出。

过去这需要开发者手动处理。

现在，Adaptive Context Management 为你消除这部分负担，并且在 Backboard 中免费提供。

产品: Backboard.io
功能: Adaptive Context Management
结果: 多模型应用稳定运行，无需自己写 token 溢出处理逻辑
可用性: 已在 Backboard API 中上线
文档: https://docs.backboard.io

问题: 上下文窗口不一致会让多模型系统变脆弱

在真实应用里，“上下文”不仅仅是聊天消息，通常还包括:

系统提示词（system prompt）
最近的对话轮次
工具调用与工具返回（tool calls / tool responses）
RAG 检索上下文
Web 搜索结果
运行时元数据

如果应用一开始用的是大上下文模型，之后将请求路由到小上下文模型，总状态就可能超过新模型的上下文上限。

多数平台把这些工作交给开发者:

截断策略
优先级规则
自动总结管线
溢出处理
token 使用监控

在 多模型 架构中，这些逻辑很快就会变得复杂且易碎。

Backboard 的目标很明确: 让开发者把模型当作可互换的基础设施，而不是每次换模型都要重写状态管理。

介绍: Backboard.io 的 Adaptive Context Management

Adaptive Context Management 是 Backboard runtime 的一项能力，会自动重塑对话状态，确保始终适配目标模型的上下文窗口。

当请求被路由到一个新模型时，Backboard 会动态分配上下文预算:

20% 用于保留原始状态（raw state）
80% 通过智能总结释放空间

20% 的原始状态里保留哪些内容

Backboard 会优先保留最关键的实时输入:

系统提示词
最近消息
工具调用
RAG 结果
Web 搜索上下文

在预算内能放下的内容会直接传给模型，其余部分自动压缩。

智能总结: 会随模型切换自动调整

当需要压缩时，Backboard 会自动总结剩余对话状态，并遵循一条简单规则:

优先使用你要切换到的目标模型来生成总结
如果总结仍然放不进可用上下文，Backboard 会 回退到先前使用的更大上下文模型，生成更“高压缩率”的总结

这样可以尽可能保留关键信息，同时确保最终状态一定能塞进新模型的限制中。

整个过程都发生在 Backboard runtime 内部，无需额外开发工作。

你应该很少再触达 100% 上下文上限

由于 Adaptive Context Management 会在请求与工具调用过程中持续运行，Backboard 会在上下文耗尽之前提前重塑状态。

实际效果是: 即使在对话中途切换模型，你的应用也应该 很少真正打满上下文窗口。

Backboard 让系统保持稳定，开发者无需一直盯着 token 溢出。

可观测性: 在 Backboard msg endpoint 中查看上下文用量

Backboard 会在 msg endpoint 里直接返回上下文用量，便于开发者实时追踪。

示例响应:

"context_usage": {
  "used_tokens": 1302,
  "context_limit": 8191,
  "percent": 19.9,
  "summary_tokens": 0,
  "model": "gpt-4"
}

你可以轻松监控:

当前使用了多少 token
距离模型上限还有多远
总结产生了多少 token
当前由哪个模型在管理上下文

无需自己搭建监控与追踪系统。

免费包含在 Backboard.io 中

Adaptive Context Management 已包含在 Backboard 平台中，不需要额外配置，也不需要额外付费。

只要你在用 Backboard，它就已经在工作了。

更大的目标: 把模型当作可互换的基础设施

Backboard 的设计理念是让开发者可以一次构建，然后在大量模型之间自由路由。

前提是用户状态必须能够安全迁移。

Adaptive Context Management 让跨 17,000+ 模型的多模型编排更可靠，而 Backboard 负责:

上下文预算管理
溢出预防
自动总结
可观测性

开发者专注构建，Backboard 处理上下文。

下一步

Adaptive Context Management 已通过 Backboard API 提供。

开始使用: https://docs.backboard.io

如果你正在做多模型应用，欢迎在评论区分享你在切换哪些模型，以及你携带的状态类型（工具调用、RAG、Web 搜索、长对话等）。

Nuevo en Backboard.io: Gestión automática de la ventana de contexto en más de 17.000 modelos

Jonathan Murray — Sat, 14 Mar 2026 22:11:45 +0000

Backboard ahora incluye Adaptive Context Management, un sistema integrado que administra automáticamente el estado de la conversación cuando tu aplicación cambia entre LLMs con diferentes tamaños de ventana de contexto.

Backboard ofrece acceso a 17.000+ modelos, así que cambiar de modelo es algo común. El problema es que los límites de contexto varían mucho entre proveedores y familias de modelos. Lo que cabe en un modelo puede desbordar en otro.

Hasta ahora, los desarrolladores tenían que resolver esto a mano.

Adaptive Context Management elimina esa carga, y está incluido gratis en Backboard.

Producto: Backboard.io
Funcionalidad: Adaptive Context Management
Resultado: Apps multi modelo estables sin lógica de overflow de tokens
Disponibilidad: Ya activo en la API de Backboard
Docs: https://docs.backboard.io

Por qué las diferencias de ventana de contexto rompen las apps multi modelo

En aplicaciones reales, el “contexto” es más que mensajes. Normalmente incluye:

Prompts del sistema
Turnos recientes de conversación
Llamadas a herramientas y respuestas
Contexto de RAG
Resultados de búsqueda web
Metadatos de ejecución

Si una app inicia una sesión en un modelo con contexto grande y luego enruta una solicitud a un modelo con contexto menor, el estado total puede exceder el límite del nuevo modelo.

La mayoría de plataformas dejan lo difícil al desarrollador:

Estrategias de truncado
Reglas de priorización
Pipelines de resumen
Manejo de overflow
Tracking de uso de tokens

En un sistema multi modelo, eso se vuelve frágil rápidamente.

El objetivo de Backboard es simple: tratar los modelos como infraestructura intercambiable, sin reescribir el manejo del estado cada vez que cambias de modelo.

Presentamos Adaptive Context Management (Backboard.io)

Adaptive Context Management es una funcionalidad del runtime de Backboard que reestructura automáticamente el estado para que siempre quepa en la ventana de contexto del modelo destino.

Cuando una solicitud se enruta a un nuevo modelo, Backboard asigna dinámicamente el presupuesto del contexto:

20% reservado para estado “en crudo”
80% liberado mediante resumido inteligente

Qué se mantiene “en crudo” dentro del 20%

Backboard prioriza primero las entradas vivas más importantes:

Prompt del sistema
Mensajes recientes
Llamadas a herramientas
Resultados de RAG
Contexto de búsqueda web

Lo que quepa dentro del presupuesto de estado en crudo se pasa directamente al modelo.

Todo lo demás se comprime automáticamente.

Resumido inteligente que se adapta al cambio de modelo

Cuando hace falta compresión, Backboard resume automáticamente el resto del estado siguiendo una regla sencilla y robusta:

Primero intentamos resumir usando el modelo al que estás cambiando
Si el resumen aún no cabe, hacemos fallback al modelo anterior con mayor contexto para generar un resumen más eficiente

Esto preserva la información importante y asegura que el estado final quepa dentro del límite del nuevo modelo.

Todo ocurre dentro del runtime de Backboard, sin código adicional.

Deberías llegar rara vez al 100% del contexto

Como Adaptive Context Management corre continuamente durante solicitudes y llamadas a herramientas, Backboard reestructura el estado de forma proactiva antes de que se agote la ventana de contexto.

En la práctica, esto significa que tu app debería llegar pocas veces al límite, incluso si cambias de modelo a mitad de conversación.

Backboard mantiene el sistema estable para que no tengas que vigilar el overflow de tokens.

Visibilidad total: uso de contexto en el endpoint msg de Backboard

Backboard expone el uso de contexto para que puedas ver exactamente qué está pasando en tiempo real.

Ejemplo de respuesta:

"context_usage": {
  "used_tokens": 1302,
  "context_limit": 8191,
  "percent": 19.9,
  "summary_tokens": 0,
  "model": "gpt-4"
}

Esto facilita monitorear:

Tokens usados actualmente
Qué tan cerca estás del límite del modelo
Tokens generados por el resumido
Qué modelo está gestionando el contexto

Obtienes observabilidad sin construir tu propio sistema.

Incluido gratis en Backboard.io

Adaptive Context Management está incluido en Backboard sin costo adicional, y no requiere configuración especial.

Si ya usas Backboard, ya está funcionando.

La idea grande: modelos como infraestructura intercambiable

Backboard fue diseñado para que construyas una vez y puedas enrutar entre modelos libremente.

Eso solo funciona si el estado se mueve de forma segura con el usuario.

Adaptive Context Management es otro paso para hacer confiable la orquestación multi modelo en 17.000+ LLMs, mientras Backboard se encarga de:

Presupuestación de contexto
Prevención de overflow
Resúmenes automáticos
Observabilidad

Los desarrolladores construyen. Backboard maneja el contexto.

Próximos pasos

Adaptive Context Management ya está disponible en la API de Backboard.

Empieza aquí: https://docs.backboard.io

Si estás construyendo una app multi modelo, comenta qué modelos estás alternando y qué tipo de estado estás pasando (herramientas, RAG, búsqueda web, chats largos).

Backboard.io: Automatic Context Window Management Across 17,000+ Models

Jonathan Murray — Sat, 14 Mar 2026 22:08:31 +0000

Backboard now ships with Adaptive Context Management, a built in system that automatically manages conversation state when your application switches between LLMs with different context window sizes.

Backboard supports 17,000+ models, so model switching is normal. The problem is that context limits vary widely across providers and model families. What fits comfortably in one model can overflow the next.

Until now, developers had to handle this manually.

Adaptive Context Management removes that burden, and it is included for free with Backboard.

Product: Backboard.io
Feature: Adaptive Context Management
Outcome: Stable multi model apps without token overflow logic
Availability: Live today in the Backboard API
Docs: https://docs.backboard.io

Why context window mismatches break multi model applications

In real applications, “context” is more than chat messages. It often includes:

System prompts
Recent conversation turns
Tool calls and tool responses
RAG context
Web search results
Runtime metadata

When an app starts on a large context model and later routes a request to a smaller context model, the total state can exceed the new model’s limit.

Most platforms push the hard parts to developers:

Truncation strategies
Prioritization rules
Summarization pipelines
Overflow handling
Token usage tracking

In a multi model setup, this becomes fragile fast.

Backboard’s goal is simple: treat models as interchangeable infrastructure, without rewriting state handling every time you switch models.

Introducing Adaptive Context Management (Backboard.io)

Adaptive Context Management is a Backboard runtime feature that automatically reshapes the conversation state so it fits the target model’s context window.

When a request is routed to a new model, Backboard dynamically budgets the available context window:

20% reserved for raw state
80% freed through intelligent summarization

What stays “raw” inside the 20% budget

Backboard prioritizes the most important live inputs first:

System prompt
Recent messages
Tool calls
RAG results
Web search context

Whatever fits inside the raw state budget is passed directly to the model.

Everything else is compressed automatically.

Intelligent summarization that adapts to the model switch

When compression is required, Backboard summarizes the remaining conversation state using a simple, reliable rule:

First attempt summarization with the model you are switching to
If the summary still cannot fit, fall back to the larger previous model to generate a more efficient summary

This keeps the user’s state intact while ensuring the final request fits inside the new model’s context limit.

All of this happens automatically inside the Backboard runtime, with no extra developer code.

You should rarely hit 100% context again

Because Adaptive Context Management runs continuously during requests and tool calls, Backboard proactively reshapes state before you exhaust a context window.

In practice, this means your app should rarely hit the full limit, even when switching models mid conversation.

Backboard keeps multi model systems stable so you do not have to constantly monitor token overflow.

Full visibility: context usage in the Backboard msg endpoint

Backboard also exposes context usage directly so developers can see what is happening in real time.

Example response:

"context_usage": {
  "used_tokens": 1302,
  "context_limit": 8191,
  "percent": 19.9,
  "summary_tokens": 0,
  "model": "gpt-4"
}

This makes it easy to track:

Current token usage
How close you are to the model’s limit
Tokens introduced by summarization
Which model is currently managing context

You get visibility without building your own instrumentation.

Included for free on Backboard.io

Adaptive Context Management is included with Backboard at no additional cost, and it requires no special configuration.

If you are already using Backboard, it is already working.

The bigger idea: models as interchangeable infrastructure

Backboard was designed so developers can build once and route across models freely.

That only works if state travels safely with the user.

Adaptive Context Management is another step toward making multi model orchestration reliable across 17,000+ LLMs, while Backboard handles:

Context budgeting
Overflow prevention
Summarization
Observability

Developers focus on building. Backboard handles the context.

Next steps

Adaptive Context Management is available now through the Backboard API.

Start here: https://docs.backboard.io

If you are building a multi model app and want to share your routing strategy, comment with what models you are switching between and what kind of state you are carrying (tools, RAG, web search, long chats).