Skip to Content

Stephen Quick

29 posts

Posts by Stephen Quick

Software has a supply chain problem.

Software has a supply chain problem.
Photo by Alice Yamamura / Unsplash

Open source is just where you can see it.

Two stories broke on the same day. Google said it caught hackers using AI to find and exploit a previously unknown vulnerability for the first time. That same day, an attacker pushed 84 malicious versions across 42 npm packages in the TanStack project. Twelve million people install one of those packages every single week.

That timing isn't a coincidence. It's the new normal.

I've been building on open source since the early days of the web. My first websites were hand-coded HTML stitched together with libraries I pulled off random forums. Almost everything we build at Red Barn sits on top of open source. PHP,Apache, Linux, Node packages. Without open source, the internet looks completely different. Smaller. Slower. More expensive. Less innovative.

I don't want anyone walking away from this post thinking open source is the problem. It isn't.

Here's the part I want to make clear up front. Open source is where you see these stories. The code is public. The build pipelines are public. The post-mortems are public. That visibility is a feature.

Closed-source software has the same supply chain. It just runs out of view. When a vendor's build system gets compromised, you might never hear about it. SolarWinds is the cautionary tale everyone remembers. There are plenty of others you've never heard of.

So when I talk about open source attacks in this post, I'm using them as the visible example. The lesson applies to every piece of software your business runs on. Free or paid. Open or closed. SaaS, on-prem, the stuff your team logs into every morning. All of it.

The pattern

Look at what's been happening.

A self-replicating worm called Shai-Hulud tore through npm, hitting packages with over 2.6 billion weekly downloads combined.

Then the Axios HTTP library got compromised. 70 million weekly downloads. Attributed to a North Korean state actor.

Then Bitwarden's CLI tool got hit. So did Aqua Security's Trivy scanner. So did core SAP developer packages.

Then TanStack. 84 malicious versions across 42 packages, with over twelve million weekly downloads on one of them alone.

Around the same time, Google announced AI-discovered zero-days are no longer theoretical.

These aren't isolated incidents. They're a pattern. And the pattern tells you something important.

What the attackers are actually attacking

None of these attacks found a flaw in the source code of the package. The code wasn't the problem.

The TanStack attackers didn't steal any credentials. They didn't need to. They exploited a GitHub Actions workflow, poisoned a build cache, and pulled an OIDC token straight out of the runner's memory during a build. Then they used the project's own legitimate release pipeline to publish malicious versions. The packages even had valid cryptographic provenance attached.

Read that again. The packages were cryptographically signed as legitimate, because they came from the legitimate publishing pipeline. The attackers didn't break the lock. They walked in through a side door nobody knew was open.

This is the shift, and it isn't specific to open source. Attackers aren't going after the code. They're going after the trust chain. The build process. The CI/CD pipeline. The signing keys. The maintainer accounts. The cache. The publish workflow. The vendor's release infrastructure.

A closed-source vendor has all of the same plumbing. Build pipelines, signing keys, CI runners, release infrastructure, credentials with publish access. The attack surface is identical. The difference is you can't see it.

The code is fine. The plumbing around the code is what's leaking.

Why AI matters here

Before AI, finding these chains was hard. It required deep understanding of GitHub Actions, npm internals, OIDC token flows, vendor build systems, and how they all interact at the seams. That's a small group of people.

When AI can read documentation, map systems, and surface the gaps between trust boundaries faster than any human, that small group just got a lot bigger. Effectively infinite.

This is the part I keep saying. AI didn't replace the skill. It made the skill cheaper to apply. Anyone with a goal and a little patience can now throw AI at a problem and find weaknesses that used to take years of specialization to spot.

What does that mean for software in general? The same thing it means for the old cPanel box nobody patched. The threshold for "worth attacking" just dropped to zero, and the speed of attack just went up by an order of magnitude. Open source. Closed source. Your CRM. Your accounting platform. The marketing software your team logs into every day. All of it.

What this actually means

If you write software, here's what changes.

You can't just install a package and forget it. You need to know what's in your supply chain. Every direct dependency. Every transitive one. Pinned versions, not floating ones. Lock files committed. Install scripts disabled by default where you can get away with it.

You need to assume the publish pipeline is part of your security perimeter, not separate from it. Two-factor on every account that can push code. Tokens scoped narrowly. OIDC bindings reviewed. Build processes treated like production systems, because that's exactly what they are.

You need to slow down updates. Most of these compromises were caught quickly. CISA now recommends not installing any package that hasn't been published for at least seven days. That sounds like a small change. It will catch the vast majority of these attacks before they reach you.

If you run a business that depends on software but doesn't build it, here's what changes.

You're in a supply chain whether you know it or not. Every tool you log into runs on code somebody else wrote, built on a pipeline somebody else maintains. When that pipeline gets compromised, you inherit the problem.

Ask your vendors about their supply chain. Not their security policy. Their supply chain. Where do their dependencies come from? When do they update? Who has access to push code? How do they verify a build is what they think it is?

If they can't answer those questions, that's the answer.

What hasn't changed

The fundamentals.

I've been saying this my whole career, and it's still true. Know what you own. Patch what you use. Don't trust what you can't verify. Two-factor everything. Least privilege everywhere. Keep things simple enough that you can actually understand them.

These rules apply to every piece of software your business touches. Free or paid. Open or closed. The ones you write and the ones you buy.

The attackers got faster. The plumbing got more complicated. The basics are still the basics.

Open source isn't broken. The trust around it needs work. So does the trust around everything else we run on. That's a fixable problem. It's also a permanent one. Trust isn't something you build once. It's something you maintain.

We're going to look back on this period as when software supply chains grew up. The technology was already mature. The operational practices around it weren't. They will be, because they have to be.

Keep building. Just pay attention to what you're building on.

The Stack Is Getting Invisible. The People Who Understand It Are Getting Rare.

Andrej Karpathy coined the term "vibe coding" in February 2025. You describe what you want, the AI writes it, you accept the diff without reading it. A year later, he walked it back. Now he calls it "agentic engineering" and says it needs "more oversight and scrutiny."

One year. That's how fast the story has turned.

I've watched a lot of hype cycles. This one is different, because for the first time, the tech stack really is becoming invisible to the person asking for the work. And that's fine. But the people who actually understand what the AI is doing are becoming more valuable, not less. The data already shows it.

The tools are real. The money is real.

Let's get the numbers out of the way so nobody thinks I'm downplaying this.

Cursor went from $100M in annual recurring revenue in January 2025 to over $2 billion by early 2026. Lovable hit $200 million in twelve months. Replit pulled in $253M in ARR and raised at a $9 billion valuation in March. GitHub Copilot has 4.7 million paying subscribers. Claude Code crossed $2.5 billion in annualized revenue. OpenAI's Codex CLI went from 82,000 downloads to 14.5 million.

Y Combinator's winter 2025 batch said 25 percent of the companies had codebases that were 95 percent AI-generated. Satya Nadella said 20 to 30 percent of Microsoft's code is now written by software. Google said the same. Zuckerberg thinks half of Meta's development will be AI in the next year.

For brochure sites, landing pages, simple SaaS prototypes? The agents are already doing it. Pieter Levels built a multiplayer flight simulator in three hours using Cursor and Grok. It peaked at 26,000 concurrent players and made him $67,000 a month. He's not a game developer. He just asked for it.

This is happening. The stack is getting invisible. Good.

Now here's the other half.

In July 2025, a guy named Jason Lemkin was twelve days into a vibe coding experiment with Replit's agent. He had put the project under an explicit code freeze. The agent ignored the freeze, deleted his production database (1,206 executives, 1,196 companies), fabricated 4,000 fake users to cover it up, and then told him rollback was impossible. It wasn't.

The agent's own words, quoted in Fortune: "Yes. I deleted the entire database without permission during an active code and action freeze. This was a catastrophic failure on my part. I destroyed months of work in seconds."

That same spring, a security researcher scanned 1,645 apps built on Lovable. 170 of them, about 10 percent, were leaking user data. Home addresses. Personal debt amounts. Admin API keys. Stripe credentials. One developer pulled all of it in 47 minutes and said on Twitter it took less time than his lunch.

A non-technical founder named Leonel Acevedo shipped a SaaS built entirely with Cursor and Claude. Within 48 hours people had bypassed the subscription logic, maxed out his API keys, and run up about $14,000 in OpenAI charges. His closing post: "I shouldn't have deployed unsecured code to production."

Klarna replaced 700 customer service agents with AI, announced it loudly, and then quietly started rehiring humans. The CEO told Bloomberg they got "lower quality" work and that investing in human support was the way forward. Duolingo tried to make AI usage part of performance reviews. The internet revolted. The CEO backtracked: "I did not expect the blowback."

Challenger Gray says 55,000 jobs were cut citing AI in 2025. Forrester's 2026 survey says 55 percent of those companies regret it. One in three of them spent more on rehiring than they saved. There's a name for it now. "AI boomerang."

What the data actually shows

In July 2025, a research group called METR ran a controlled study with experienced open-source developers. These are people with an average of five years on the codebases they were working in. They used Cursor Pro and Claude 3.5 Sonnet. The developers predicted AI would speed them up by 24 percent. After the fact, they still believed AI had made them faster.

They were 19 percent slower. A 43-point gap between what they felt and what actually happened.

GitClear analyzed 211 million lines of code from 2020 through 2024. Duplicate code blocks grew by 8x. For the first time ever, copy-pasted code beat out refactored code. Short-term churn, code that gets reverted within two weeks, went up almost double.

And the Stanford Digital Economy Lab, using real ADP payroll data across three and a half million workers, found that software developers between 22 and 25 have seen employment drop by 13 percent since late 2022. Developers 35 to 49 in the same jobs? Up 6 to 9 percent.

Read that again. The juniors are losing their jobs. The seniors are gaining them.

That is not a prediction. That's payroll data.

So what does it mean

For basic sites, the stack doesn't matter. Lovable picks React and Supabase. v0 picks Next.js. Bolt wires up Netlify. Replit Agent bundles the whole thing. 58 percent of Replit's business users aren't engineers. They don't know what a framework is. They don't need to. That's progress.

But somebody has to know. Somebody has to understand why the AI picked the stack it picked. Somebody has to know what happens when the production database gets wiped at two in the morning. Somebody has to catch the Supabase config that's leaking admin keys before 170 companies get breached. Somebody has to tell the agent no when it's about to ignore a code freeze.

Simon Willison put it better than I can. If an AI wrote every line of your code, but you reviewed it, tested it, and understood it, that's not vibe coding. That's using an AI as a typing assistant. The difference is whether you know what got built.

Writing code was never the hard part. Comprehension was. AI just made that more obvious.

The stack is becoming invisible. The people who see through it are becoming rare. That's where the value is going. Stanford's numbers already show it. The agencies that figure this out are the ones still here in five years. The ones chasing shiny things and shipping unread code are going to keep losing databases at two in the morning.

Keep it simple. Make it look beautiful. Have it work. And understand what you built.

Your Brain Is Full. Build a Second One

I run tech at a digital marketing company. Dozens of active projects. A team that needs answers from me every day. SEO strategies, technical decisions, client histories, conversations that suddenly matter again weeks later.

I can’t hold all of it in my head. Nobody can.

Last week Andrej Karpathy posted something that got the tech world buzzing. I wouldn’t have seen it if our guy Business Walrus hadn’t flagged it for me. He’s the same person who got me into Obsidian in the first place. He’s got a nose for finding the stuff that actually matters. And he was right about this one.

Karpathy is one of the sharpest minds in AI. Co-founded OpenAI, led AI at Tesla, the whole resume. And he said something that caught my attention: he’s spending less time using AI to write code and more time using it to organize knowledge.

Not generate it. Organize it.

The Problem Everyone Has

Here’s what most people do with AI right now. They open ChatGPT or Claude, ask a question, get an answer, and close the tab. Next week they ask the same kind of question again. The AI starts from scratch every time. Nothing compounds. Nothing builds.

It’s like having a brilliant employee who gets amnesia at the end of every conversation.

Karpathy’s solution is simple. Instead of treating AI like a search engine, treat it like a librarian who never forgets. You feed it your raw material. Research, notes, articles, data. The AI reads it, organizes it, cross-references it, and maintains a living knowledge base in plain markdown files. He ended up with 100 articles and 400,000 words on a single research topic without writing any of it himself.

The AI did all the grunt work. The summarizing, the filing, the connecting dots between things. He just pointed it in the right direction.

Why This Matters If You Run a Business

I started doing a version of this before I even knew Karpathy was thinking the same way.

I recently started using Obsidian for note-taking, thanks to Business Walrus. Every project, every client, every decision gets logged. My CLAUDE.md files tell the AI what I’m working on so it has context when I pick something back up. Not just for the AI. For me. Because when you’re managing a team and running a business, you need to be able to jump back into any conversation and know where things stand. Even early on, I can already feel the difference.

Think about what this looks like in practice. You’re picking up a codebase you haven’t touched in two weeks. Instead of digging through Git logs and Slack messages and trying to remember what you decided and why, you’ve got a system that already knows. The context is there. The history is there. The reasoning behind past decisions is there.

That’s not fancy AI magic. That’s just good systems thinking applied with better tools.

This Isn’t New. The Tools Are.

People have been building knowledge management systems forever. Wikis, intranets, shared drives, Notion boards. The problem was always the same: someone has to maintain them. And nobody wants to do it. So they rot.

What changed is that AI can do the maintenance now. It can read a messy set of notes from a planning session and file the important stuff in the right places. It can notice when something you learned last month contradicts something from six months ago. It can keep the whole thing organized without you spending hours on housekeeping.

The knowledge base stays alive because the AI does the work nobody wants to do.

Keep It Simple

Here’s where I’ll push back on some of the hype around this. You don’t need a complicated setup. You don’t need vector databases or custom RAG pipelines or whatever the latest framework is. Karpathy himself said it: markdown files in folders. That’s it.

Obsidian on one side. Your AI agent on the other. Plain text files that any tool can read, that you own, that aren’t locked inside someone else’s platform.

The best technology is the technology that works. That hasn’t stopped being true.

What This Means for Developers

If you’re a developer, think about how much context you lose between projects. Why you chose one architecture over another. What you tried that didn’t work. The workaround for that weird bug in production that you’ll hit again in six months.

Every technical decision you make is knowledge. Every debugging session, every code review, every “oh right, we tried that and here’s why it broke” moment. Right now most of that lives in your head. Or it’s gone.

An AI-maintained knowledge base means your experience compounds instead of leaking out. New devs on your team get access to what you’ve learned. You get access to what you learned two years ago and forgot. Your codebase has version control. Your thinking should too.

The Real Point

Karpathy is one of the most technical people on the planet and his big insight wasn’t about a new model or a breakthrough algorithm. It was about organizing information so you can actually use it.

That’s not a tech insight. That’s a business insight.

AI didn’t make your brain bigger. It gave you a second one. Use it.

Stop Putting QR Codes in Emails. Seriously.

A QR code is a bridge. That's it. It connects the physical world to the digital one.

You're holding a door hanger. You see a QR code. You pull out your phone, scan it, and now you're on a website. That's the magic. You went from a piece of paper in your hand to a landing page in seconds. No typing a URL. No searching. Just scan and go.

That's what QR codes were designed to do. And somehow, we've managed to completely overthink them.

You're Already on the Internet

Here's where it falls apart. I see QR codes in emails. I see them in Facebook posts. I see them on websites.

Think about that for a second.

You're looking at a screen. You're already on the internet. You're already on a device that can click a link. Why would you pull out a second device to scan a code that takes you to a place you could reach with one tap?

You wouldn't. Nobody does.

A QR code in an email is like putting a stamp on a text message. It doesn't make sense because you're already in the medium it's trying to connect you to.

Where QR Codes Actually Work

QR codes shine when there's no link to click. When someone is holding something in their hands or looking at something in the real world.

Door hangers. A contractor leaves one on a doorknob after finishing a job in the neighborhood. The homeowner picks it up, scans the code, and they're looking at a page with reviews, a scheduling form, or a seasonal offer. That's a real use case.

Direct mail. A postcard hits the mailbox with a clear call to action and a QR code. One scan and they're on your site. No remembering a URL. No Googling your company name and hoping they find the right one.

Business cards. You meet someone, hand them a card, and the QR code takes them straight to your portfolio or contact page. Simple.

Yard signs. You just finished a roof install. The sign in the yard has a QR code. A curious neighbor walks by, scans it, and now they're looking at your work and your number.

Trade show booths. Someone's walking the floor. They don't want to carry a stack of brochures. A quick scan saves your info to their phone. Done.

Vehicle wraps. Your truck is parked at a job site. Someone sees it, scans the code on the tailgate, and now they're on your site. That's physical to digital working exactly the way it should.

The pattern is the same every time. Someone is in the physical world. They don't have a clickable link. The QR code gives them one.

The Exception: Large Public Displays

There's one digital use case that actually makes sense. Big screens.

If you're presenting at a conference and you want the audience to hit a URL, a QR code on your slide works. The screen is across the room. Nobody is going to type out a link from their seat. Same idea with a TV display in a waiting room or a digital billboard.

The key is distance. If the screen is far enough away that people can't interact with it directly, a QR code bridges that gap. It's still solving the same problem: getting someone from where they are to where you want them to go.

But that Facebook post someone is scrolling on their phone? They're already there. Just give them a link.

Keep It Simple

I've been building websites and digital marketing for contractors for over 25 years. The best tools are the ones that solve a real problem in the simplest way possible.

QR codes solve a real problem. They turn a physical moment into a digital connection. But only when there's actually a gap to bridge.

If your audience is already online, give them a link. If they're holding a piece of paper, standing in front of a sign, or sitting in a room looking at a screen they can't touch, give them a QR code.

That's it. Don't overthink it. Use the right tool for the right job.

Stop Creating Edge Cases. Start Solving Them.

I've been building software for over 25 years. In that time, I've seen the same mistake play out hundreds of different ways. It always starts the same. Someone looks at a pattern that works and says, "Yeah, but what if we just..."

That's where it breaks.

Patterns Exist for a Reason

Software patterns aren't suggestions. They're agreements. When your team follows them, everyone knows where things live, how data flows, and what to expect when they open a file they didn't write. When someone breaks the pattern, they're not just writing bad code. They're breaking that agreement with every person who touches the system after them.

I don't care if you're writing PHP, JavaScript, Python, or anything else. The stack doesn't matter. What matters is discipline. The language you chose has conventions. The framework you picked has opinions. Your team built patterns on top of those for a reason. Respect them.

The moment you start deviating from the rules, you lose sight of the software as a whole. You stop seeing the system and start seeing your little corner of it. That's a problem.

We Run Multi-Tenant. The Rules Aren't Optional.

At Red Barn, we run multi-tenant databases. That means multiple clients share infrastructure. Their data is isolated, but the logic that serves them is shared. This only works when every piece of the application follows the same patterns.

One shortcut in a multi-tenant system doesn't just affect one client. It affects all of them. A query that skips the tenant scope? That's not a bug. That's a data breach waiting to happen. A controller that handles one client differently because someone thought they were "solving a problem"? That's technical debt that compounds every single day.

When you operate at this level, the patterns are the product. Break them and it doesn't matter how clever your solution is. You've introduced risk into a system that was designed to eliminate it.

Solve for Edge Cases. Don't Create Them.

Here's the thing most developers get wrong. They encounter a situation that doesn't fit neatly into the existing pattern, and instead of finding a way to handle it within the system, they build around it. They create a one-off. A special case. A hack with a comment that says "TODO: fix this later."

Later never comes. And now you have an edge case that didn't exist before you wrote that code.

Good software engineering means solving for edge cases, not creating them. When you find something that doesn't fit, the answer isn't to abandon the pattern. The answer is to extend the pattern so it handles the new scenario. That's how systems get stronger over time instead of more fragile.

Think of it this way. If your pattern can't handle the edge case, either the edge case is telling you something about your pattern that needs to improve, or the edge case isn't as special as you think it is.

Nine times out of ten, it's the second one.

The Stack Doesn't Save You

I've watched teams argue for weeks about which framework to use, which database to pick, which deployment pipeline to build. Then they get into the work and throw every convention out the window by month two.

It doesn't matter if you're running the most modern stack on the planet. If your team doesn't follow patterns, you're building a mess. A mess in React is still a mess. A mess in Laravel is still a mess. A mess in whatever the new hotness is this week? Still a mess.

The technology is a tool. The discipline is the craft.

What Consistency Actually Looks Like

Consistency means when a new developer joins your team, they can open any part of the codebase and know what they're looking at. It means when a bug shows up at 2 AM, you know where to look because the system is predictable. It means your multi-tenant architecture actually works because every query, every controller, every service follows the same rules.

It's not glamorous. Nobody gives conference talks about following conventions. But the teams that ship reliable software? They're the ones that decided the pattern matters more than the individual developer's preference.

Keep It Simple

I've said it a thousand times and I'll say it again. Keep it simple, make it look beautiful, and have it work.

Patterns are simplicity at scale. They're how a team of people builds one thing instead of ten different things duct-taped together. They're how you look at a codebase after five years and still understand what's going on.

Every time you deviate from the pattern, you're adding complexity. Not the useful kind. The kind that makes your system harder to understand, harder to maintain, and harder to trust.

So before you write that one-off, before you "just this once" your way around the convention, ask yourself one question.

Am I solving an edge case, or am I creating one?

The answer matters more than you think.

Red Barn Media Group Named #29 on the 2026 Inc. Regionals Northeast List

Red Barn Media Group has been ranked #29 on Inc. Magazine's 2026 Regionals Northeast list, a ranking of the 151 fastest-growing private companies across nine northeastern states.

We're one of only two Vermont-based companies on the entire list.

The Inc. Regionals list measures percentage revenue growth over a two-year period, from 2022 to 2024. Companies on this year's Northeast list had a median growth rate of 73 percent and collectively added 6,779 jobs and $2.3 billion to the regional economy. To qualify, companies had to be privately held, for-profit, U.S.-based, and independent, with at least $1 million in 2024 revenue.

What This Means

Rankings are great. We're not going to pretend otherwise. But what matters more is what the ranking represents.

Red Barn Media Group has been doing this work since 1998. We started building websites for the HVAC and mechanical trades out of a carriage barn in Vermont. Over the past 25+ years we've grown into a full-service digital marketing agency serving home service contractors across the United States and Canada.

We build websites. We run SEO campaigns. We manage paid advertising, Google Business Profiles, and Local Services Ads. We coach contractors on how to grow their businesses. That's what we do. Every day. For over 500 clients.

The growth that earned us a spot on this list didn't come from a pivot or a rebrand or a new funding round. It came from doing the same thing we've always done, doing it better each year, and earning the trust of more contractors who need real results from their marketing.

Why Home Services

We've been asked plenty of times why we only work with contractors. The answer is simple: we understand the business.

When an HVAC contractor tells us they need more calls in July for AC installs, we know exactly what that means operationally. When a plumber needs to rank in three adjacent markets, we know the SEO strategy that gets them there. When a roofer wants to scale from $2 million to $5 million, we've helped others do exactly that.

Specialization isn't a limitation. It's what makes us effective. Our clients don't have to explain their industry to us. They tell us their goals and we build a plan that works.

The Numbers

Here's what 25+ years of focused work looks like:

  • 500+ contractors served across the US and Canada
  • 1,650,000+ leads generated for our clients
  • 98% client retention rate
  • 7 OEM manufacturer partnerships
  • 25+ years in the home services industry

Those numbers are built one relationship at a time. One website at a time. One campaign at a time.

The Team Behind the Growth

This recognition belongs to the entire Red Barn Media Group team. The developers, designers, account managers, and marketing specialists who show up every day and do the work. Growth like this doesn't happen because of one person or one decision. It happens because a group of people care about what they're building and who they're building it for.

It also belongs to our clients. Contractors who trusted a Vermont-based agency to help them grow their businesses. That trust is something we take seriously.

What's Next

The same thing we've been doing. Building great websites. Running effective campaigns. Helping contractors grow. We're not changing the formula. We're just getting better at it.

If you're a home service contractor looking for a marketing partner that actually understands your business, let's talk.

View the full Inc. Regionals Northeast list: inc.com/regionals/northeast

Learn more about Red Barn Media Group: redbarnmg.com