The Gap Is Widening and It’s Not Slowing Down

Brendan O’Leary wrote a piece this week titled “The AI Coding Revolution Hasn’t Started Yet“. His headline observation: most professional engineers haven’t adopted AI coding tools in any meaningful way. Not even close.

In my experience too, he’s right. I’d push it further.

I’ve been deep in this work – helping companies actually get Generative AI tooling integrated into real development workflows, not just installed, not just “evaluated,” but actually integrated. Running sessions, doing the pairing, reviewing the setups, watching teams try to navigate the gap from “we have Copilot turned on” to “we’re doing something meaningfully different with how we build software.” and what I keep seeing isn’t just that most companies haven’t started. It’s that the gap between the teams that have started and everyone else is compounding. Every week that passes, that gap doesn’t hold steady. It widens.

The Observation from the Inside

The conference Brendan was at, where he made this observation is a good one. You talk to staff engineers, architects, team leads – people who are not amateurs at this craft – and you find out they’re still in the “I’ve heard of Claude Code” phase. That’s a real data point and it matches what I’m seeing at companies I work with. More than a few times they haven’t even gotten to that point.

But here’s the wrinkle that the conference floor view doesn’t fully capture: the gap isn’t just about adoption level. It’s about trajectory. The practitioners who’ve gone deep aren’t standing still. They’re getting faster, refining workflows, building intuition about how to orchestrate agents, where to trust the output, where to keep a tighter leash, and where to let things run. They’re compounding their advantage every single week. Meanwhile, a team that’s still on “tab completion is the whole idea” isn’t sitting on a fixed baseline. They’re falling behind in a relative sense, even if their absolute productivity is unchanged.

That’s a slow-moving disaster in competitive terms.

The Questions That Tell the Story

I’ve had almost the exact same hallway conversations described. The tells are in the questions:

“Wait, so the agent actually runs the tests itself?”

“How are you keeping it from just rewriting everything it touches?”

“Our security team said no to all of this, so we haven’t tried anything.”

None of these are dumb questions. In fact, they’re the correct questions — they mean the person is starting to actually reason about agentic tooling rather than dismissing it. But they’re also questions that someone who’s been working in this space for six months has already burned through, experimented on, and formed opinions about. There’s a widening experiential gap underneath the tooling gap and that part is harder to close quickly.

Why the Lag Is Rational (But Costly)

The reasons Brendan lists for slow adoption from security lockdowns, bad early Copilot experiences, tool landscape churn, team skepticism are all real and I’ve run into every single one of them. Let me add a few more from what I’ve encountered.

The “we tried it and it wasn’t impressive” problem is particularly pernicious, because the delta between the experience of using autocomplete in 2023 and using an agentic coding workflow in 2026 is genuinely massive. But if you hit the bad experience first and walked away, you should probably revisit it now. I know demos that happen at conferences aren’t likely to convince. A well-produced YouTube video either. But get your hands dirty and use it, otherwise the lag is going to send you, or the group you work with into luddite land and made “redundant” as they say in some places (i.e. laid off, unemployed, etc).

That’s one of the core things I try to do when working with teams: get past the “is this real” phase as fast as possible by showing it working on their actual code. Because abstract capabilities don’t move people. Seeing an agent navigate through a service you wrote, flag something you’d have missed, and propose a coherent refactor in thirty seconds — that moves people.

The security lockdown problem is also real but I want to name it more precisely: what organizations actually mean when they say “we can’t use AI tools on our codebase” is usually “we haven’t yet done the work to understand what the actual risk surface is.” Which is a very different thing than a reasoned security position. It’s a deferral masquerading as a decision. And that deferral has a cost that most orgs aren’t properly accounting for on their risk register.

The Vibe Coding Trap Is Real Too

Here’s where I’ll add some nuance that doesn’t always make it into the “you should adopt this” framing: adoption without discipline is its own problem.

There’s a Stanford study that just landed – SWE-chat, (which I have a lot of frustration with how it’s often mis-interpreted, for example the comment I’ve left here the post) looking at 6,000 real coding agent sessions from open-source developers in the wild – and the numbers are sobering. Only 44% of agent-produced code makes it into commits. Vibe-coded sessions (where the agent authors virtually all the code) burn roughly 3x more tokens and dollars per committed line than collaborative sessions. And vibe-coded code introduces about 9x more security vulnerabilities per committed line than code humans write themselves.

I’ve talked about this at length in Hurting or Helping Devs and in my breakdown of the types of code changes that AI agents produce. The tools are genuinely powerful. They’re also genuinely capable of quietly reshaping a codebase into something that looks correct but behaves like it was written by an overly confident intern with root access and no fear of consequences.

The right model isn’t “hand everything to the agent.” It’s orchestration with discipline – scoped prompts, diff limits, human gatekeeping on production deployments, and a clear-eyed understanding of where agent judgment is trustworthy and where it isn’t. That’s a craft skill that takes time to develop. It can’t be skipped.

So I’m not just saying adopt. I’m saying adopt correctly with discipline, which is harder, takes longer, and requires more deliberate investment. But the teams doing it right are building a durable advantage. The teams doing it sloppily are creating technical debt at a rate that will bite them in ways that are currently hard to see.

The Compounding Problem

Here’s the thing about compounding gaps that I keep coming back to: they don’t feel urgent when you’re inside them.

If your team is shipping at more or less the same pace it shipped at a year ago, nothing feels broken. Nothing is on fire. You’re not obviously behind. The gap is invisible to you because the other side of it isn’t in your day-to-day view.

But a team that’s been running agentic workflows for six months has built intuition, muscle memory, and workflow patterns that can’t be copied in a week. They’ve figured out what to scope, what to constrain, where to trust, and where to verify. They’ve failed in some interesting ways and learned from it. They’re operating at a different surface area of the problem than a team that’s starting from scratch — even if both teams have access to the same models and tools.

That’s the part that concerns me most when I work with orgs that are still in “evaluation mode” two years into this transition. The tools aren’t the moat. The practice is the moat. And practice requires time.

The clock is running.

What Needs to Happen

Brendan is optimistic about the diffusion curve tipping soon, and I think that’s probably right. The on-ramp needs to get lower – better model-agnostic tooling, less lock-in, less requirement to reconstruct your entire workflow to get started. Those are the right levers.

But I’d add one more: organizations need someone to physically show them what the other side looks like, in their context, with their problems. Not a demo environment. Not a benchmark. Their actual code. Their actual team. That’s the thing that moves the needle from “heard about it” to “we’re doing this.”

If you’re at a company still sitting on the sidelines on this – not because of a reasoned, deliberate decision, but because it hasn’t risen to the top of the priority stack yet – I’d genuinely encourage you to treat that as a risk and a significant one at that. Not a vague future risk. A significant present, compounding one.

The teams on the other side of that gap are not slowing down.

Hurting or Helping Devs?

This video features me, a Principal Software Engineer, discussing the impact of AI on software development, the risks of “vibe coding,” and the necessary shifts in engineering practices. Adron argues that traditional manual coding is becoming obsolete and that developers must adapt to a new paradigm defined by systems thinking and AI orchestration.

Key Takeaways:

  • The Dangers of “Vibe Coding”: Adron defines “vibe coding” as the practice of relying on AI to generate code without a deep understanding of the system (0:08:31). This often leads to unmaintainable, “disposable” software—a phenomenon he calls the shinification of software—which can cause significant production issues when systems fail (0:00:46, 0:08:31).
  • Managing AI Agents: To maintain code quality, developers must:
    • Rein in Scope: Avoid open-ended prompts; instead, provide specific, well-defined architectural plans to AI agents (0:05:13, 0:06:01).
    • Diff Discipline: Enforce hard limits on diff sizes (e.g., aiming for ~50 lines) to ensure human reviewers can feasibly audit changes (0:52:37, 0:55:00).
    • Human Gatekeeping: Keep humans as the final gatekeepers for production deployments to ensure security and reliability (0:16:50, 0:57:29).
  • The Evolution of the Developer Role: The junior pipeline is changing; instead of focusing on syntax or pixel-pushing, future developers should act as systemic architects who understand how to orchestrate AI tools and manage complex workflows (0:24:05, 0:26:05).
  • The Industry Reckoning: As VC-subsidized AI adoption faces future economic corrections, companies will need to prioritize efficiency, energy production, and true orchestration over simply generating massive amounts of code (1:02:41, 1:05:00).
  • Future Predictions: Adron predicts that AI will eventually develop its own programming language optimized for machine-to-machine communication, further distancing development from manual human typing (1:09:48).

In this episode, you’ll learn:

  1. Why writing code manually means you are already too far behind.
  2. How to manage the six specific types of AI code changes.
  3. The reason Diff Discipline is the only way to survive vibe coding.

Time Sliced Segments

  • (03:14) Why the junior developer pipeline is imploding
  • (05:13) How to reign in agent scope for better results
  • (08:31) The slow creeping dread of vibe coding
  • (12:50) Moving past communication cycles with prototypes
  • (16:50) Why shipping to production needs a human gatekeeper
  • (20:20) How roles shift when agents handle the workflow
  • (24:05) Why slinging individual lines of code is over
  • (29:47) Bringing a generalist approach back to computer science
  • (34:57) Breaking down the six types of code changes
  • (41:40) Why AI optimizes for plausible output instead of correctness
  • (52:37) Enforcing diff limits to keep human reviewers sane
  • (57:29) Setting up no-fly zones for sensitive code
  • (01:02:41) The coming hundred x shock to the tech industry
  • (01:11:27) What it means to be a coder in 2026

Monday’s Greeting & Miniature Emotive Micro-rant

I always find it painful for those of us that understand the semantic, etymologic, systemic, historical, and related first principles of things that have happened in our life time. For example the origination of “DevOps” or “Agile” and know the original coining, intent, and purpose of these terms and principles.

Also the simply things like “they’re”, “their”, and “there”, “where”, “were”, and “we’re”, or the comma usage in this very statement. Not just one or two misuses of these things, but the almost gas lighting nature of entire organizations (looking at whole parts of Microsoft) trying to redefine these things into other entirely new concepts, entire parts of society just ignoring or obliviously not learning these language elements, or a confluence of all these things coming together.

But even all that gas lighting and negligent use of ideas and words, the icing that makes the shit sandwich is, when the failures of society or organizations and people to know and use these concepts and terms and words correctly, then tells you – someone who was involved or knows the concepts and word usage well – that we’re somehow elitist or out of touch or don’t know what we’re talking about.

Utterly insane and levels of hubris that I just give no care to. It is almost as bad, and annoying, and frustrating I imagine as someone writing a code library, component, application, or inventing something and then having someone else explain it back to them wrong and tell them they’re wrong. Just wild madness among some to do this.

It’s painful, but also sometimes in that later case, hilarious to watch the person correct the confidently wrong, then mic drop with, “How do I know? Cuz I created the thing!” 🤣

The lesson, I suppose, that I’m inferring in this miniature emotive micro-rant, is don’t walk through life with the hubris and confidence that the wrong have. Walk through life with humility and learn to listen, always listen, even if you are the holder of knowledge, no matter the case, and be ready to learn and also teach.

With all that said, and my miniature emotive micro-rant complete – y’all have a great day and may this Monday not be like the trope Monday’s often have! Cheers!

InterlinedList Is Live: Lists, Posts, and Markdown Finally in One Place

It’s the 73rd Day of 2026! Per my previous post, I promised updates and thus, updates delivered!

There’s a problem I’ve run into repeatedly over the years. Actually, it’s more like a pattern of problems.

I’ve got:

  • notes scattered across markdown files
  • lists living in some task app
  • social media posts written in drafts somewhere else
  • and half-finished ideas bouncing between GitHub issues, notebooks, and random documents.

Individually, each of these tools is “fine” yet fragmented and leaves ideas, messaging, and lists leaking and losing ideas to the nebulous.

That’s exactly the mess that led me to build InterlinedList.

And now it’s live: 👉 https://interlinedlist.com

What InterlinedList Actually Is

At its core, InterlinedList is a platform that ties together three things that are usually awkwardly separated:

  1. Lists
  2. Social media posting (to your other accounts too, not just on IntelinedList)
  3. Markdown documents

Each of these solves a different part of the “organize your thinking and output” problem. But the real value shows up when they’re connected.

InterlinedList brings them together into a single system.

Not another note app.
Not another scheduling tool.
Not another task manager.

Instead, it’s a workflow** platform for ideas that turn into posts, lists, and documents.

Lists That Connect to What You Do

Everyone has lists. They might be all over the place. With InterlinedList you can create your own lists, with whatever schema of columns you want.

Ideas lists.
Research lists.
Feature lists.
Writing queues.
Project breakdowns.

The problem is most list tools treat lists like dead data. You write them down, check things off, and that’s about it. InterlinedList treats lists more like launch points. A list item can become:

  • a social media post
  • a markdown document
  • a reference entry
  • a trackable idea

Instead of bouncing between five tools, the list becomes the center of gravity. Which is how most people actually work. Over time, my intent is to bring these features to be even more seamlessly connected. Eventually, there will even be options to bring together your LLMs you prefer to extend the capabilities of each of these things in your workflow.

Social Media Posting Without the Chaos

Posting to social platforms today usually looks like this:

  • Write something somewhere
  • Copy it into another platform
  • Schedule it somewhere else
  • Lose track of what you’ve already posted

InterlinedList brings posting directly into the workflow.

You can:

  • draft posts
  • schedule posts
  • organize posts into lists
  • connect posts to notes or markdown docs
  • refer to your cross-posted posts from InterlinedList (for example, see image!)
Screenshot of a social media post by Adron Hall discussing Ba Bar in University Village, featuring images of the restaurant and links to Mastodon and Blue Sky.

The goal is simple: make posting part of your idea workflow instead of a disconnected chore.

The first integrations include platforms like:

  • Mastodon
  • Bluesky

And the idea is to keep expanding that ecosystem. More to come and also open to ideas!

Markdown Documents That Fit the Workflow

If you’re like me, markdown is where the real thinking happens.

Articles. Notes. Research. Drafts. Documentation.

But markdown tools often exist in their own isolated worlds.

InterlinedList allows you to maintain markdown documents directly alongside your lists and posts, making it possible to move naturally between: writing, organizing, and publishing.

Why These Three Things Belong Together

This was the key realization. Lists, posts, and markdown aren’t separate activities. They’re three phases of the same process:

  1. Capture the idea → lists
  2. Develop the idea → markdown
  3. Share the idea → social posts

Most tools treat these as unrelated workflows. InterlinedList treats them as one continuous pipeline. Which means less context switching, less tool juggling, and far fewer lost ideas.

Early Access Offer

To kick things off an early access offer, I’m doing something simple. If you’re interested in organizing ideas, posts, and documents in one place, now’s a great time to jump in.

The first 10 users who sign up will receive a full-featured subscription account for free.

No trial. No feature restrictions. Just the full platform.

Built Because I Wanted It

Like a lot of the things I’ve built, InterlinedList started as something I wanted for myself.

I needed a place where:

  • research lists
  • post drafts
  • markdown articles
  • and publishing

could actually live in the same ecosystem.

After building it and using it, the obvious next step was to open it up so others could use it too. Let me know what you think!

With that, stay tuned, the team has a lot more coming!

** I’d add that, this is absolutely a work in progress and the team will be working to bring together more of the workflow concept and features to bridge this set of tooling together to be even more seamless.

Security Was Already a Mess. Generative AI Is About to Prove It.

I was thinking about some of the points from the Polyglot Conf list of predictions for Gen AI, titled “Second Order Effects of AI Acceleration: 22 Predictions from Polyglot Conference Vancouver“. One thing that stands out to me, and I’m sure many of you have read about the scenario, of misplaced keys, tokens, passwords and usernames, or whatever other security collateral left in a repo. It’s been such an issue orgs like AWS have setup triggers that when they find keys on the internet, they trace back and try to alert their users (i.e. if a user of theirs has stuck account keys in a repo). It’s wild how big of a problem this is.

Once you’ve spent any serious amount of time inside corporate IT, you eventually come to a slightly uncomfortable realization. Exponentially so if you focus on InfoSec or other security related things. Security, broadly speaking, is not in a particularly great state.

That might sound dramatic, but it’s not really. It is the standard modus operandi of corporate IT. The cost of really good security is too high for more corporations to focus where they should and often when some corporations focus on security they’ll often miss the forrest for the trees. There are absolutely teams doing excellent security work, so don’t get the idea I’m saying there aren’t some solid people doing the work to secure systems and environments. There are some organizations that invest heavily in it. There are people in security roles who take the mission extremely seriously and do very good engineering.

A lot of what passes for security is really just a mixture of documentation, policy, and a little bit of obscurity. Systems are complicated enough that people assume things are protected. Access is restricted mostly because people don’t know where to look. Credentials are hidden in configuration files or environment variables that nobody outside the team sees.

And that becomes the de facto security posture.

Not deliberate protection.

Just… quiet obscurity.

I’ve lost count of the number of times I’ve been pulled into a system review, or some troubleshooting session, where a secret shows up in a place it absolutely shouldn’t be. An API key sitting in a script. A database password in a config file. An environment file committed to a repository six months ago that nobody noticed.

That sort of thing happens constantly. Not out of malice. Out of convenience. But now we’ve introduced something new into the environment.

Generative AI.

More importantly though, the agentic tooling built around it. Tooling that literally takes actions on your behalf. Tools that can read entire repositories, analyze logs, scan infrastructure configuration, generate code, and help debug systems in seconds. Tools that engineers increasingly rely on as a kind of external thinking partner while they work through problems.

All that benefit is coming with AI tools. However AI doesn’t care about the secret. It’s just processing text. But the act of pasting it there matters. Because the moment that secret leaves your controlled environment, you no longer know exactly where it goes, how it’s stored, or how long it persists in the LLM.

The mental model a lot of people are using right now is wrong. They treat AI like a scratch pad or an extension of their own thoughts.

It isn’t.

The more accurate model is this: an AI tool is another resource participating in your workflow. Another staff member, effectively.

Except instead of being a person sitting at the desk next to you, it’s a system operated by someone else, running on infrastructure you don’t control, processing information you send to it. Including keys and secrets.

Once you start looking at it that way, a few things become obvious. You wouldn’t casually hand a contractor your production API keys while asking them to help debug something. You wouldn’t drop a full .env file containing service credentials into a conversation with someone who doesn’t actually need those values.

Yet that is exactly the pattern that is quietly emerging with generative AI tools. Especially among new users of said tools! Developers paste configuration files, snippets of infrastructure code, environment variables, connection strings, and logs directly into prompts because it’s the fastest way to get an answer.

It feels harmless. But secrets have a way of spreading through systems once they start moving.

The real issue here is that generative AI doesn’t create security problems. It amplifies the ones that already exist. Problems that the industry has failed (miserably might I add) at solving. If an organization already has sloppy credential management, AI just gives those credentials another place to leak. If engineers already pass secrets around informally to get work done, AI becomes another convenient channel for that behavior.

And because AI tools accelerate everything, they accelerate the consequences too. What used to take hours of searching through documentation can now happen instantly. A repository full of configuration files can be analyzed in seconds. Systems that were once opaque are now far easier to reason about.

The Takeaway (Including secrets!)

The practical takeaway here isn’t that people should stop using AI tools. That’s not realistic and frankly a career limiting maneuver at this point. The tools are genuinely useful and they’re going to become a permanent part of how software gets built.

What needs to change – desperately – is operational discipline.

Secrets should never be treated casually, and that includes interactions with generative systems. API keys, tokens, passwords, certificates, environment files, connection strings—none of those belong in prompts or screenshots or debugging sessions with external tools.

If you need to ask an AI for help, scrub the sensitive pieces first. Replace real values with placeholders. Remove anything that grants access to a system. Setup ignore for the env files and don’t let production env values (or vault values, whatever you’re using) leak into your Generative AI systems.

Treat every AI interaction the same way you would treat a conversation with another engineer outside your organization, or better yet outside the company (or Government, etc) altogether.

But not someone you hand the keys to the kingdom. Don’t give them to your AI tooling.