DEV Community: Jonathan Murray

Stop building what your customers ask for

Jonathan Murray — Wed, 22 Apr 2026 13:44:39 +0000

I was at a conference this week.

Bunch of stakeholders on stage. Hospital admins, big-name buyers, a couple of policy folks. The message to founders was loud and clear:

"You need to be consulting us. You need to be adapting your products to our suggestions."

And honestly? I hated it.

Not because they were completely wrong. They were half right. They were just shouting the half that was wrong.

Here's the part that's true

Building in a vacuum is how you ship things nobody uses. Founders, especially technical ones, have a real habit of deciding what the world needs from inside a Notion doc.

So yes. Talk to users. Ride along. Watch people struggle with your product. All of that.

The stakeholders aren't crazy for wanting a seat at the table.

Here's the part that breaks things

"Listen to us" slowly turns into "do what we say."

And that's where it gets weird.

Because every dev on earth has learned this lesson already. It's called a bug report.

A user says "the login is slow." You dig in. The login isn't slow. They're on hotel wifi and there's no loading spinner, so it feels frozen. The complaint was real. The proposed fix, "make the login faster," was useless.

Stakeholder feedback works exactly the same way.

The pain is the signal. The proposed fix is a guess. Usually a bad one.

A senior eng who shipped whatever the ticket said would get laughed out of the room. Why do we call a founder who ships whatever the customer asks for "responsive"?

Why the fix is almost always wrong

Three reasons, no mystery to any of this:

1) Stakeholders see their slice. Not the whole system. Of course their fix is local.
2) They imagine solutions inside the workflow they already have. Which is often the exact workflow you're trying to change.
3) The thing that would actually solve the problem doesn't exist in their vocabulary yet. That's kind of your job.

When a cardiologist says "add a button that auto-generates the referral letter," the real signal is referrals are friction. The button might be the worst possible version of the fix. Maybe the letter shouldn't exist. Maybe the referral shouldn't need a letter. That's a conversation. Not a ticket.

The receipt: healthcare AI just ran this experiment for us

For years, stakeholders told the industry they wanted "AI that can pass the medical boards."

The industry listened. Every model got tuned on USMLE-style questions. Board-exam scores became the benchmark everyone pointed at.

This month, JAMA Network Open dropped a study across 21 top LLMs (ChatGPT, Claude, Gemini, DeepSeek, Grok). Final-diagnosis accuracy on complete cases? Over 90%.

Differential diagnosis, the thing an actual doctor does all day? Failed more than 80% of the time.

The stakeholders asked for the wrong benchmark. Founders shipped it. We now have a generation of models that ace trivia and fold on reasoning.

The founders who had pushed back, the ones who said we hear you want trustworthy AI, we're not going to chase board scores to prove it, would look prescient right now. The ones who obeyed built an industry of exam-passers.

How to actually do it

When a stakeholder hands me a feature request, I try to never put it in the backlog as written. Three questions first:

1) What were they trying to do when they felt the pain?
2) What's the actual friction, stripped of their proposed fix?
3) What would "solved" feel like, regardless of how it gets built?

Rule of thumb: if a stakeholder ask fits neatly into a Jira ticket, I haven't translated it yet.

Back to the conference

I get why the stakeholders were on that stage. They've been burned by founders who ignored them. They want to be heard.

But "heard" is not the same as "obeyed." And founders who treat customer feedback as a spec instead of a bug report end up building slightly nicer versions of the thing that already isn't working.

Listen obsessively.
Obey selectively.
And be willing to tell the room that the button they're asking for isn't the thing they actually need.

That's not arrogance. That's the job.

What's a piece of stakeholder feedback you took literally and regretted? Or one you translated into something better and it worked?

🙏🏻🙏🏻🙏🏻🙏🏻💪🏻💪🏻💪🏻💪🏻

Jonathan Murray — Tue, 21 Apr 2026 18:47:22 +0000

Ranjan Dailata

Apr 21

Building Conversational Intelligence with Backboard: Turning Conversations into a Living Intelligence System

#ai #machinelearning #nlp #productivity

Comments

4 min read

Two Days, Two Hacks: The Lovable Disclosure and the Pattern Nobody Wants to Talk About

Jonathan Murray — Mon, 20 Apr 2026 18:14:55 +0000

Yesterday I wrote about the Vercel incident and walked through why you need to rotate your "non-sensitive" environment variables today. I thought that would be the week's security post.

Then I woke up to @weezerOSINT's disclosure about Lovable, and now I am starting to wonder if someone out there is just running an end-to-end test on the mythos of the modern AI-dev stack.

Two days. Two incidents. Totally different root causes. Same uncomfortable conclusion.

What dropped

The short version: security researcher @weezerOSINT made a free Lovable account and was able to read other users' source code, database credentials, AI chat histories, and customer data. Any free account. Every project created before November 2025.

The screenshot making the rounds shows a response from api.lovable.dev/GetProjectMessagesOutputBody.json with another user's prompts, AI reasoning traces, task lists, and project IDs sitting there in plain JSON. The bug is Broken Object Level Authorization on Lovable's own platform API, not the more familiar "the generated app shipped without Supabase RLS" story we got in February.

The part that actually made me set my coffee down: the report was filed through Lovable's bug bounty program 48 days ago, marked as a duplicate of an earlier informative report, and left open. At the time of the disclosure it reportedly still worked.

Forty. Eight. Days.

Why this one hits different

The February Lovable wave was a story about generated apps. The takeaway was "audit the output" — a thing developers already know how to do, at least in principle. You could imagine a fix: better defaults, RLS on by default in the scaffolds, a linter that yells at you when a table is public.

This one is a story about the platform itself. The thing you trusted to hold your code, your keys, your customer data — the control plane, not the output — had a missing auth check on a production API endpoint for at least seven weeks after someone told them about it.

Stack this next to the Vercel situation and a pattern starts to emerge. In the Vercel case, the breach came through a third-party AI tool that had been granted a Workspace OAuth scope that went further than anyone audited. In the Lovable case, it is the platform's own API failing to check "is this caller allowed to see this object." Different failure modes, same underlying theme: the trust boundaries in the AI-assisted-dev stack are drawn with marker, and the marker is washing off in the rain.

The vibe-coding angle

Here is the thing that will keep me up tonight. When you vibe-code an app, you do not type process.env.STRIPE_KEY into a .env file and move on. You paste the key into the chat so the AI can wire it up. You paste the database URL into the chat to fix a schema bug. You paste a sample customer record into the chat to get the types right.

Every one of those messages lives in the project's chat history. The disclosed endpoint returned chat histories. So it is not just "your generated app is exposed" — it is "every secret you ever mentioned in a conversation with Lovable is sitting in a JSON response that any free account could fetch."

If you have built on Lovable, go read your own chat history right now, with the eyes of an attacker. Search for sk-, postgres://, Bearer, anything that looks like a secret. Every match is a key to rotate at the source. Not rename. Rotate. Revoke at the provider and reissue.

What I actually think is going on

I do not think someone is literally targeting the AI-dev ecosystem on a two-day schedule for dramatic effect. What I think is happening is that this category of tools grew very fast, shipped a lot of features, pointed their best engineers at the next feature rather than the last one, and is now discovering that "trust boundaries" is a feature that does not show up in a demo.

The vibe-coding productivity is real. I still use these tools. I will still use them next week. But I am going to stop pretending that a platform saying "secure by default" counts for anything until I see a disclosure track record that backs it up. Forty-eight days on a report with the title "Broken Object Level Authorization on Lovable API leads to unauthorized access to user data and project source code" is, to use a technical term, a lot.

If you are shipping on Lovable right now

Short version, because I already wrote the long version yesterday for Vercel and the shape is the same:

Rotate anything a Lovable project ever touched. Revoke at the upstream provider, not just in the Lovable dashboard. Audit your chat histories for pasted secrets. Turn on RLS on every Supabase table while you are in there. If personal data was exposed, talk to a lawyer today about your disclosure obligations, because "we used an AI app builder" is not going to hold up in front of a regulator.

Two days. Two hacks. Maybe it is the start of a trend, maybe it is the week from hell, maybe someone really is testing the mythos. Either way, rotate your keys and get back to building.

Source for the disclosure: @weezerOSINT on X. If you have audited a Lovable project in the last day and found something worth sharing, the comments are open.

My co-founder is just being honest in this post. ;)

Jonathan Murray — Mon, 20 Apr 2026 18:09:14 +0000

Robert Imbeault

Apr 20

I Think Therefore I Am… A Big Pain in the A$$

#ai #llm #developers #reasoning

Comments 1

3 min read

Anyone working on applications for Recursive Language Models? #discussion #rlm

Jonathan Murray — Mon, 20 Apr 2026 16:34:38 +0000

Vercel Hack: Why You Need to Rotate Your "Non-Sensitive" Environment Variables Today

Jonathan Murray — Mon, 20 Apr 2026 02:49:24 +0000

If you deploy on Vercel, todays headlines about a security incident might have caused some stress.

I know firsthand how disruptive supply chain alerts can be. Take a deep breath.

We are going to separate the noise from the facts and focus on the practical steps you can take today to secure your infrastructure.

Here is a straightforward guide to protecting your applications.

What Actually Happened

Before we jump into the steps, here are the verified facts:

The Root Cause: Vercel confirmed unauthorized access to internal systems via a compromised third-party AI tool with a Google Workspace OAuth integration.
The Exposure: Environment variables marked as "Sensitive" remained encrypted and protected. However, standard or non-sensitive environment variables were likely exposed to the attacker.
The Claims: A threat actor using the name ShinyHunters claims to be selling Vercel data. Vercel is actively handling the situation and their core services remain online.

Because non-sensitive variables were likely exposed, your immediate priority is auditing and rotating your credentials.

Step-by-Step Remediation Guide

Step 1: Audit Your Vercel Environment Variables

Log into your Vercel dashboard and review the environment variables for every active project. You are looking for anything that was not explicitly marked with the "Sensitive" flag. Pay close attention to:

Database connection strings (Postgres, MongoDB, Redis)
Third-party API keys (Stripe, SendGrid, OpenAI)
Authentication secrets and JWT keys

Step 2: Revoke Upstream Credentials

If you find a secret stored as a non-sensitive variable, changing it in Vercel is not enough. You must invalidate the compromised key at the source.

Go to the service provider (AWS, Supabase, Stripe, etc.).
Revoke or delete the old credential entirely.
Generate a brand new credential.

Step 3: Update and Flag as Sensitive

Take your newly generated keys and update them in your Vercel projects. When you do this, make absolutely sure you check the box to mark the variable as "Sensitive". This ensures the value is encrypted at rest and hidden from the dashboard UI going forward.

Step 4: Audit Your OAuth Integrations

Since this breach originated from a compromised Workspace app, use this opportunity to clean up your own team integrations.

Review your GitHub organization settings and remove unrecognized OAuth apps.
Check your Google Workspace integrations.
Revoke access for any third-party tools your team no longer uses.

Step 5: Monitor Your Logs

Keep a close eye on your application and database logs over the next few days. Look for unfamiliar IP addresses accessing your database or unexpected spikes in API usage. These are clear indicators that a leaked key might be in use.

Moving Forward

Security incidents are stressful, but handling them methodically is your best defense. By rotating your exposed keys and locking down your variables, you close the door on the immediate risks. Run through the checklist, secure your workspace, and get back to building.

Love to see the @backboard.io builds coming through! Great job Ranjan

Jonathan Murray — Sun, 19 Apr 2026 13:56:44 +0000

Ranjan Dailata

Apr 19

Building a Smarter Hiring Engine: AI Recruiter with RAG, Memory & Web Search

#devchallenge #weekendchallenge #ai #python

Comments 4

6 min read

Embarrassment is cheap. Token spend isn't.

Jonathan Murray — Fri, 17 Apr 2026 20:17:12 +0000

I was in a meeting today.

The team was walking me through a new feature. I was nodding. I'd used the word "endpoint" correctly twice. I was feeling sharp.

Too sharp.

Because my brain... a peaceful place where every feature is shaped like the last feature that worked... decided: oh, this is probably another markdown file.

It was not another markdown file.

It was parallel multi-agent recursive language model creation.
I didn't know that yet. I leaned back. I smiled. I said it.

"Should be quick, eh?"

Silence. Then laughter. Not polite laughter. Not boss-is-trying laughter. The full kind. The kind that's been building up for a while.

And I was fine with it.

Actually I was more than fine. Embarrassment is an underexplored emotion in founder life. The best version of me is the one who stays in the room after saying something dumb — not the one who stops asking questions to protect the illusion.

The lead engineer didn't laugh. He looked at me the way doctors look at patients who have just confidently explained that their cold is probably bacterial.

"It's not quick."

"Oh. Why?"

He explained. This was theoretical. There was one research paper on it. One. If we pulled it off, we'd be doing something that hadn't been done before.

And then I asked the second dumb question. The one the first dumb question unlocks. Something about how much this was going to cost to run.

The room got quieter in a different way.

We spent the next twenty minutes on token consumption. Whether the recursion depth could be capped. Which agents actually needed to talk to which. Stuff the team would have gotten to eventually — but not in that meeting, not in that order.

Here's the thing.

"Should be quick" was the wrong thing to say. But me-saying-the-wrong-thing-out-loud turned out to be the right thing in the room. If I'd protected my pride, I'd have nodded through a plan that burned a lot of tokens.

So I'm going to keep doing it. I'm going to keep mistaking research papers for markdown files. I'm going to keep being the guy who says "should be quick" five minutes before the engineers collectively grieve.

Embarrassment is cheap. Token spend isn't.
Progress. Velocity.

Tackling the unsexy problems has been our goal, so you can build for your customers.

Jonathan Murray — Fri, 17 Apr 2026 01:14:05 +0000

Robert Imbeault

Apr 16

Why Token Counting in Multi-LLM Systems Is Harder Than You Think

#ai #llm #devtools #programming

Comments 2

2 min read

This was a big solve for us and it’s a critical item to know as a Dev. Not all tokens are the same.

Jonathan Murray — Thu, 16 Apr 2026 16:02:02 +0000

Robert Imbeault

Apr 16

Why Token Counting in Multi-LLM Systems Is Harder Than You Think

#ai #llm #devtools #programming

Comments 2

2 min read

Great piece Shakiran, and we love to see how quickly we can help Devs drive more value in their projects with state & memory! Great job!

Jonathan Murray — Tue, 14 Apr 2026 18:45:03 +0000

Shakiran Nannyombi

Apr 14

My AI Was Smart… But Useless

#ai #api #webdev #beginners

Comments 3

1 min read

Your Job Isn't Going Away. But Someone's Fundraise Depends on You Thinking It Is.

Jonathan Murray — Tue, 14 Apr 2026 15:00:56 +0000

I've been watching the AI narrative closely. Building with it. Learning in public. Talking to developers, founders, and regular people trying to figure out what's real and what's noise.

And I keep running into the same story, told the same way, by the same people:

"AI is going to replace developers. No one will have a job. AGI is around the corner."

And every single time, the person saying it is trying to raise money.

Let's talk about what's actually happening

OpenAI, Anthropic, and the other big labs are in an arms race. Not just for talent or compute. For capital. We're talking about rounds measured in billions. And to justify those valuations, they need a story that's big enough.

So what's the biggest story you can tell?

"Our product replaces high-value white collar workers."

That's the pitch. Not to you. To investors.

Here's how the math works in every pitch deck you'll never see: "Our AI replaces ten people making $150K each. That's $1.5M in value per customer. There are 500,000 companies that fit our ICP. That's a $750B TAM."

Cue the standing ovation from Sand Hill Road.

But here's the thing. That math only works if you believe the people disappear.

And I don't. (Spoiler: neither does 200 years of economic history.)

Enter Jevons Paradox

In 1865, an economist named William Stanley Jevons noticed something weird. England had just made steam engines way more efficient at burning coal. Everyone assumed coal usage would go down.

It went up. Way up.

Because when something gets cheaper and more efficient, people don't just do the same amount of it. They do more. Way more. New use cases emerge. New industries form. Demand explodes.

This isn't some obscure footnote. This is one of the most well-documented patterns in economic history. And it applies directly to what's happening with AI right now.

This has happened before. Every single time.

Let me give you a few examples that should feel familiar.

ATMs were supposed to kill bank tellers.

When ATMs rolled out in the 1970s and 80s, everyone assumed bank tellers were done. A machine that dispenses cash? Pack it up, Karen from the third window.

What actually happened: the number of bank tellers went up. ATMs made it cheaper to open bank branches, so banks opened more of them. And those branches needed people. The role shifted from counting cash to advising customers and selling financial products. The job didn't disappear. It evolved and expanded.

Spreadsheets were supposed to kill accountants.

VisiCalc and then Excel automated calculations that used to take teams of people days to complete. The fear was real. Why hire an accountant when a spreadsheet does it faster? (Turns out, because someone still needs to explain to the CEO why the spreadsheet says they're broke.)

What actually happened: the number of accountants exploded. Suddenly every small business could afford to do serious financial analysis. The demand for people who could interpret, strategize, and advise around those numbers grew far beyond what existed before. The tool didn't replace the person. It created a bigger market for the person.

Cloud computing was supposed to kill ops engineers.

"You don't need a server room anymore. You don't need sysadmins. Just put it in the cloud." That was the pitch. Somewhere, a sysadmin reading this just felt a chill.

What actually happened: DevOps became one of the fastest growing roles in tech. The infrastructure got more complex, not less. Someone still needs to architect it, secure it, optimize it, and keep it running at 3am when the pager goes off. The tools got better. The demand for people who understand them got bigger.

The internet was supposed to kill retail jobs.

E-commerce was going to make stores irrelevant. No more cashiers. No more salespeople.

What actually happened: the internet created an entirely new category of retail jobs. Fulfillment centers, logistics, customer experience, digital marketing, content creation, social media management. The U.S. has more retail-adjacent jobs now than before Amazon existed.

The pattern is always the same. The technology makes something cheaper. Cheaper means more people use it. More usage means more demand. More demand means more jobs. Different jobs, sometimes. But more of them.

Every. Single. Time.

So why does the "jobs are going away" narrative persist?

Because it's useful. Not to you. To the people raising money.

If you're an AI lab trying to justify a $100B+ valuation, the story has to be enormous. "We help people be a bit more productive" doesn't exactly make a venture capitalist reach for their checkbook. "We replace entire categories of workers" does.

It's not even that they're lying exactly. It's that the framing is self-serving. When the CEO of an AI company talks about pricing their product based on "the cost of the worker it replaces," that's not an economic insight. That's a sales pitch wearing a lab coat.

And look, I get it. VCs need big narratives to deploy big checks. Founders need those checks to build. It's how the game works. I'm not mad at it.

But we don't have to internalize their fundraising deck as our worldview. You wouldn't take career advice from a company whose business model depends on you not having a career.

The real opportunity is expansion, not replacement

Here's what I think is actually happening, and it's way more exciting than the doom narrative:

AI is about to make millions of people capable of things they couldn't do before.

Not because it replaces their skills. Because it augments them.

A marketer who couldn't write code can now build internal tools. A small business owner who couldn't afford a legal review can now get a solid first pass. A student who couldn't afford a tutor can now get one-on-one help at 2am. A solo founder who couldn't afford a team of ten can now ship like they have one.

That's not replacement. That's expansion. That's Jevons Paradox playing out in real time.

And when you expand what's possible, you don't get fewer jobs. You get new ones. Ones that don't have names yet. Ones we can't predict because they'll be created by the very people we're currently telling to be afraid.

The self-fulfilling prophecy problem

Here's what actually scares me. Not AI. The narrative around AI.

Because narratives shape behavior. If every developer believes their job is going away, they stop investing in their craft. Companies freeze hiring because "AI will handle it." Students pivot away from computer science. Organizations delay projects because they're "waiting for AI to get better."

Congratulations. We just created a recession with vibes.

And then what happens? A slowdown. Not because the technology demanded it. But because we collectively talked ourselves into it.

That's the real danger. Not that AI takes our jobs. That we give them away because we believed someone's Series C deck.

Techno-optimism isn't naive. Defeatism is.

I know "techno-optimism" gets a bad rap sometimes. People think it means ignoring problems or being blindly cheerful about technology.

That's not what I'm talking about.

I'm talking about looking at 200 years of economic history and recognizing a pattern. Every major technology wave has created more prosperity, more jobs, and more opportunity than it displaced. Not without pain. Not without transition. But the net effect has always been expansion.

The printing press didn't kill scribes and create nothing. It created an entire publishing industry, literacy movement, and eventually the modern knowledge economy. (Sorry, scribes. But also, you're welcome, everyone who can read.)

The automobile didn't just kill horse-related jobs. It created suburbs, supply chains, tourism, and an entire middle class built around manufacturing and infrastructure.

The internet didn't just kill some jobs. It created millions more. Including "influencer," which honestly no one saw coming.

AI will be the same. If we let it.

The key phrase being: if we let it.

We create the world we choose to see

This is the part I feel most strongly about.

Right now, we're at a crossroads. The technology is powerful. The potential is enormous. But the direction it goes depends on the story we tell ourselves about it.

If we collectively decide that AI is a tool for replacement, that's what it'll become. Companies will use it to cut headcount. Workers will be treated as costs to eliminate. And we'll build a smaller, meaner version of the future.

But if we collectively decide that AI is a tool for expansion, the math changes completely.

More people building. More problems being solved. More small businesses competing with big ones. More individuals with capabilities that used to require entire teams. More creativity, more experimentation, more shots on goal.

That's not wishful thinking. That's what happens every single time we make a powerful capability cheaper and more accessible. The demand curve does what it always does. It goes up.

My ask to developers

If you're reading this on dev.to, you're probably someone who builds things. Someone who has influence over how technology gets used and talked about.

So here's my ask:

Stop repeating the AI doom talking points as if they're settled science. They're not. They're marketing.

When someone at your company says "should we even hire for this role, won't AI handle it?" push back. The answer is almost always that AI will make that person more productive, not unnecessary.

When you see a headline about AGI replacing all developers, ask yourself: who benefits from me believing this? Follow the money. It usually leads to someone with a cap table, a pitch deck, and a very specific number they need you to be scared of.

And when you're building with AI, build for expansion. Build tools that make more people capable. Build products that create new possibilities instead of just automating old ones.

Because the builders who define this era won't be the ones who used AI to cut costs. They'll be the ones who used it to create things that didn't exist before.

The jobs aren't going away. They're going to multiply in ways we can't yet imagine. But only if we choose to believe that and build accordingly.

What do you think? Am I being too optimistic, or is the doom narrative really just a fundraising strategy that we've all accidentally internalized? I'd love to hear from people who are actually building with AI every day.