Category: AI & AI Tooling

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

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.

Additive vs. Mutative vs. Destructive Code Changes (and Why AI Agents Love the Wrong One at 2:13AM)

There’s a particular kind of pain that only software developers know.

Not the “production is down” kind of pain.

Not the “we deployed on Friday” kind of pain.

No, I mean the slow creeping dread of pulling the latest changes, running the tests, and realizing the codebase has been “improved” in a way that feels like someone rearranged your entire kitchen… but left all the knives on the floor.

And lately, this pain has been supercharged by AI tooling. Cursor, Claude, Copilot, Gemini, ChatGPT-driven agents, whatever your poison is this week, all share a similar behavioral pattern:

They can produce a stunning amount of output at an impressive speed… while quietly reshaping your system into something that looks correct but behaves like an alien artifact from a parallel universe.

The reason is simple: AI agents don’t “change code” the way humans do. They don’t naturally respect boundaries unless you explicitly enforce them. They operate like an overly enthusiastic intern with root access and no fear of consequences. To understand why this happens, we need to talk about the different types of code changes, and how AI tooling tends to drift toward the most dangerous ones.

So let’s name the beasts.

The Four (Actually Six) Types of Code Changes

Continue reading “Additive vs. Mutative vs. Destructive Code Changes (and Why AI Agents Love the Wrong One at 2:13AM)” →

AI Is Forcing Docs To Finally Grow Up

For years we talked a big game about documentation being “a product” (which I just wrote about yesterday right here) but let’s be honest, most of the industry never treated it that way. Docs were usually the afterthought stapled onto the release cycle, the box to tick for PMs, the chore no one wanted but everyone relied on. Then generative AI rolled in and quietly exposed just how brittle most documentation is. Suddenly the docs that were just barely acceptable for humans became completely useless for LLMs. That gap is now forcing organizations to rethink how docs get written, structured, published, and maintained.

The shift is subtle but fundamental. We’re no longer writing solely for people and search engines. We’re writing for people, search engines, and AI models that read differently than humans but still need clarity, structure, and semantic meaning to deliver accurate results. This new audience doesn’t replace human readers, it simply demands higher quality and tighter consistency. In the process, it pushes documentation to finally become the product we always claimed it was.

Why AI Is Changing How We Write Docs

AI assistants (tooling/agents/whatever) like ChatGPT and Claude don’t “browse” docs. They parse it. They consume it through embeddings or retrieval systems. They chunk it. They analyze the relationships between sentences, headings, bullets, and examples. When a user asks a question to an LLM, the model is leaning heavily on how well that documentation was written, how well it was structured, and how easily it can be transformed into a correct semantic representation.

When the docs are good, AI becomes the ultimate just-in-time guide. When the docs are sparse, meandering, inconsistent, or buried in PDFs, AI either hallucinate its way forward or simply fails. The AI lens exposes what humans have tolerated for years.

That is why companies are starting to optimize docs not only for readers and SEO crawlers, but for vector databases, RAG pipelines, and automated summarizers. The end result benefits everyone. Better structured content helps AI perform better and human readers navigate faster. AI becomes a multiplier for great doc systems and a harsh critic for bad ones.

What Makes Great Modern Documentation Now

Modern documentation can’t just be readable. It has to be machine digestible, SEO friendly, and human friendly at the same time. After picking through dozens of doc systems and tearing apart patterns in both good and terrible documentation, here is what consistently shows up in the good stuff.

The Criteria

  1. Clear, hierarchical structure using consistent headings
  2. Small, semantically meaningful chunks that can be indexed cleanly
  3. Realistic examples, not toy snippets
  4. Explicit pathfinding: quickstart, deeper guides, reference, troubleshooting
  5. Direct language without fluff
  6. Predictable URLs and logical navigation trees
  7. Copy-pastable awexamples that actually work
  8. Strong inbound and outbound linking
  9. No PDF dumping ground
  10. Schema, config, API, and CLI references that are complete, not partial
  11. Contextual explanations right next to code samples
  12. Versioning that doesn’t break links every release
  13. Upgrade guides that don’t pretend breaking changes are rare
  14. A single authoritative source of truth instead of fractured side systems
  15. Accessible to LLMs: consistent formatting, predictable patterns, clean text, no wild markdown gymnastics

Nothing magical here. Most teams already know these rules. AI just stops letting you ignore them.

Five Examples Of Documentation That Nails It

Below are five strong documentation ecosystems. Each one does something particularly well and gives AI models enough structure to be genuinely useful when parsing or answering questions. I’ll break down why each works and how it maps to the criteria above.

1. Stripe API Docs

https://stripe.com/docs/api

Stripe has been the gold standard for a while. Even after dozens of competitors tried to clone the style, Stripe still leads because they iterate constantly and keep everything ruthlessly consistent.

Why it’s great
• Every endpoint is its own semantic block. LLMs love that.
• Request and response examples are always complete, never partial.
• Navigation is predictable and deep linking is stable.
• They pair conceptual docs, quickstarts, and reference material without overlap.
• All examples are real world and cross language.

How it maps to the criteria
• Structured headings and deep linking check 1, 6, and 12.
• Chunking and semantic units check 2 and 15.
• Real examples and direct language check 3 and 5.
• Pathfinding is excellent which checks 4.
• Copy-pasteable working examples check 7.

2. MDN Web Docs

https://developer.mozilla.org

MDN has decades of content, but it’s shockingly consistent, well-maintained, and semantically structured. It’s one of the best corpora for training and grounding AI models in web fundamentals.

Why it’s great
• Long history yet content stays current.
• Clear separation of reference vs guides vs tutorials.
• Canonical examples for everything the web platform offers.
• Clean, predictable markdown structure across thousands of pages.

How it maps
• Nearly perfect hierarchy and predictable formatting check 1 and 15.
• Chunked explanations with immediately adjacent examples check 2 and 11.
• Stable URLs for almost everything check 6 and 12.
• Strong pathfinding check 4.

3. HashiCorp Terraform Docs

https://developer.hashicorp.com/terraform/docs

Terraform’s documentation is extremely structured which makes it exceptionally machine readable.

Why it’s great
• Providers, resources, and data sources follow identical templates.
• Every argument and attribute is listed with exact behavior.
• Examples aren’t fluff, they reflect real infrastructure patterns.
• Cross linking between providers and core Terraform concepts is tight.

How it maps
• The template system hits 1, 2, 6, 10, 11, and 15.
• Cross linking and clear navigation cover 8.
• Complete reference material covers 10.
• Realistic examples check 3 and 7.

4. Kubernetes Documentation

https://kubernetes.io/docs/home

Kubernetes docs are huge, maybe too huge, but they’re structured well enough that LLMs and humans can still navigate them without losing their minds.

Why it’s great
• Strong concept guides and operator manuals.
• Structured task pages with prerequisites and step-by-step clarity.
• Reference pages built from source-of-truth schemas.
• Thoughtful linking between concepts and tasks.

How it maps
• Strong hierarchy and navigation hit 1 and 6.
• Machine readable chunks via consistent template patterns hit 2 and 15.
• Clear examples and commands check 3 and 7.
• Having both reference and conceptual breakdowns checks 4, 10, and 11.

5. Supabase Docs

https://supabase.com/docs

Supabase’s docs are modern, developer-focused, and written with obvious attention to how AI and search engines consume content. They basically optimized for RAG without ever claiming they did.

Why it’s great
• APIs, client libraries, schema definitions, and guides all interlink tightly.
• Clear quickstarts that become progressively more advanced.
• Rich examples spanning REST, RPC, SQL, and client SDKs.
• Consistent layouts across different product surfaces.

How it maps
• Strong pathfinding and multi-surface linking check 4 and 8.
• Full reference material checks 10.
• Predictable structure and formatting check 1 and 15.
• Example-rich guides check 3, 7, and 11.

Documentation Is Finally Being Treated As A Real Product

The interesting thing is that AI didn’t magically fix documentation. It simply raised expectations. Companies now need their documentation to be clean, complete, structured, predictable, link-friendly, example-rich, and semantically coherent because that is the only way AI can navigate it and support users in meaningful ways. This pressure is good. It forces consistency. It rewards clarity. It makes the entire documentation discipline more rigorous.

The companies that embrace this will have far better support funnels, drastically fewer user frustrations, higher product adoption, and an ecosystem that AI can actually help with instead of stumbling through. The ones that don’t will keep wondering why users stay confused and why their AI chatbots give terrible answers.

Documentation has always been a product. AI is just the first thing that has held us accountable to that truth.

Polyglot Conference Vancouver 2025: Real Talk About AI, Industry Hubris, and the Art of Unconferencing

Just got back from another incredible Polyglot Conference in Vancouver, and I’m still processing everything that went down. There’s something magical about this event – it’s not your typical conference with polished presentations and vendor booth nonsense. It’s an unconference, which means the real magic happens in the conversations, the debates, and the genuine human connections that form when you put a room full of smart, opinionated developers together and let them talk about what actually matters.

The People Make the Conference

It was excellent to meet so many new people and catch up with friends I’ve not gotten to see in some time! This is what makes Polyglot special – it’s not just about the content, it’s about the community. I found myself in conversations with developers from startups to enterprise, from different countries and backgrounds, all bringing their unique perspectives to the table.

There’s something refreshing about being in a room where everyone is there because they genuinely want to be there, not because their company sent them or because they’re trying to sell something. The conversations flow naturally, the questions are real, and the debates are substantive. No one’s trying to impress anyone with buzzwords or corporate speak (Albeit we’ll often laugh our asses off at the nonsense of Corp speak and marketecture).

I caught up with folks I hadn’t seen since before the pandemic, met new faces who are doing interesting work, and had those serendipitous hallway conversations that often lead to the most valuable insights. The kind of conversations where you’re still talking an hour later, completely forgetting that there’s a scheduled session happening somewhere else.

The Unconference Format: Getting to the Heart of Things

The sessions were, as always with an Unconference jam packed with content and when we dove in we got to the heart of the topics real quick. This is the beauty of the unconference format – there’s no time for fluff or corporate posturing. People show up with real problems, real experiences, and real opinions, and we get straight to the point.

Unlike traditional conferences where you sit through 45-minute presentations that could have been 15-minute talks, unconference sessions are dynamic and responsive. Someone brings up a topic, the group decides if it’s worth exploring, and then we dive deep. If the conversation isn’t going anywhere, we pivot. If it’s getting interesting, we keep going. The format respects everyone’s time and intelligence.

The sessions I participated in covered everything from microservices architecture to team dynamics in the face of agentic AI tooling, from introspecting databases with AI tooling to the future of programming languages in the face of AI tooling. But the most compelling discussions were around AI – not the hype, not the marketing, but the real-world implications of what we’re building and how it’s changing our industry – for better or worse – and there’s a lot of expectation it’s bring a lot of the later.

Coping with AI: The Real Talk

Some of the talks included coping with AI, and just the general insanity that surrounds the technology and the hubris of the industry right now. This is where things got really interesting, because we weren’t talking about AI in the abstract or as some distant future possibility. We were talking about it as a present reality that’s already reshaping how we work, think, and build software.

The “coping with AI” discussion was particularly revealing. We’re not talking about how to use AI tools effectively – that’s the easy part. We’re talking about how to maintain our sanity and professional integrity in an industry that’s gone completely off the rails with AI hype and magical thinking.

The Insanity of AI Hype

The insanity surrounding AI right now is breathtaking. Every company is trying to cram AI into every product, whether it makes sense or not. We’re seeing AI-powered toasters and AI-enhanced paper clips, things that have boolean operation where they’re burning through tokens to make a yes or no decision. Utter madness on that front, that’s like half a tree burned up, a windmill rotation, or a chunk or two of coal just to flip a light switch! The technology has become a solution in search of problems, and the industry is happy to oblige with increasingly absurd use cases.

But the real insanity isn’t the over-application of the technology – it’s the way we’re talking about it. AI is being positioned as the solution to every problem, the answer to every question, the future of everything. It’s not just a tool, it’s become a religion. And like any religion, it’s creating true believers who can’t see the limitations, the risks, or the unintended consequences. Maybe “cult” should be added to the “religion” moniker?

The conversations at Polyglot were refreshing because they cut through this hype. We talked about the real limitations of AI, the actual problems it creates (holy bananas there are a lot of them), and the genuine challenges of working with these systems in production. No one was trying to sell anyone on the latest AI miracle – we were trying to understand what’s actually happening and how to deal with it. Simply put, what’s our day to day action plan to mitigate these problems and what are we doing when the hubris and house of cards comes crumbling down? After all, much of the world’s economy is hinged on AI becoming all the things! Nuts!

The Hubris of the Industry

The hubris of the industry right now is staggering. We’re building systems that we don’t fully understand, deploying them at scale, and then acting surprised when they don’t work as expected. The confidence with which people make claims about AI capabilities is matched only by the lack of evidence supporting those claims.

I heard stories from developers who are being asked to implement AI solutions that don’t make technical sense, from managers who think AI can replace human judgment, and from executives who believe that throwing more AI at a problem will automatically make it better. The disconnect between what AI can actually do and what people think it can do is enormous.

The hubris extends beyond just the technology to the way we’re thinking about the future. There’s this assumption that AI will solve all our problems, that it will make us more productive, that it will create a better world. But we’re not asking the hard questions about what we’re actually building, who it serves, and what the long-term consequences might be.

The Real Challenges

The real challenges of working with AI aren’t technical – they’re human. How do you maintain code quality when your team is generating code they don’t fully understand? How do you make architectural decisions when the tools can generate solutions faster than you can evaluate them? How do you maintain professional standards when the industry is racing to the bottom in terms of quality and sustainability?

These are the questions that kept coming up in our discussions. Not “how do I use ChatGPT to write better code” but “how do I maintain my professional integrity in an environment where AI is being used to cut corners and avoid hard thinking?”

The conversations were honest and sometimes uncomfortable. People shared stories of being pressured to use AI in ways that didn’t make sense, of watching their colleagues become dependent on tools they didn’t understand, and of struggling to maintain quality standards in an environment that prioritizes speed over everything else.

The Path Forward

The most valuable part of these discussions wasn’t just identifying the problems – it was exploring potential solutions. How do we maintain our professional standards while embracing the benefits of AI? How do we educate our teams and our organizations about the real capabilities and limitations of these tools? How do we build systems that are both powerful and maintainable?

The consensus seemed to be that we need to be more thoughtful about how we integrate AI into our work. Not as a replacement for human judgment, but as a tool that augments our capabilities. Not as a way to avoid hard problems, but as a way to tackle them more effectively.

We also need to be more honest about the limitations and risks. The industry’s tendency to oversell AI capabilities is creating unrealistic expectations and dangerous dependencies. We need to have more conversations about what AI can’t do, what it shouldn’t do, and what the consequences might be when it’s used inappropriately.

The Value of Real Conversation

What struck me most about these discussions was how different they were from the typical AI conversations you hear at other conferences. There was no posturing, no trying to impress anyone with the latest buzzwords, no corporate speak about “digital transformation” or “AI-first strategies“.

Instead, we had real conversations about real problems with real people who are dealing with these issues every day. People shared their failures as well as their successes, their concerns as well as their optimism, their questions as well as their answers.

This is the value of the unconference format and the Polyglot community. It creates a space where people can be honest about what’s actually happening, where they can ask the hard questions, and where they can explore ideas without the pressure to conform to industry narratives or corporate agendas.

Looking Ahead

As I reflect on the conference, I’m struck by how much the industry has changed since the last time I was at Polyglot. AI has gone from being a niche topic to dominating every conversation. The questions we’re asking have shifted from “what is AI?” to “how do we live with AI?” and “how do we maintain our humanity in an AI-driven world?”

The conversations at Polyglot give me hope that we can navigate this transition thoughtfully. Not by rejecting AI or embracing it uncritically, but by engaging with it honestly and maintaining our professional standards and human values.

The industry needs more spaces like this – places where people can have real conversations about real problems without the hype, the marketing, or the corporate agenda getting in the way. Places where we can explore the hard questions and work together to find better answers.

The Takeaway

The biggest takeaway from Polyglot this year is that we’re at a critical juncture. The AI revolution isn’t coming – it’s here. And the choices we make now about how we integrate these tools into our work, our teams, and our industry will shape the future of software development for decades to come.

We can either let the hype and hubris drive us toward a future where software becomes disposable, quality becomes optional, and human judgment becomes obsolete. Or we can choose a different path – one where AI augments our capabilities without replacing our humanity, where we maintain our professional standards while embracing new tools, and where we build systems that are both powerful and sustainable.

The conversations at Polyglot suggest that there are people in the industry who are choosing the latter path. People who are thinking critically about AI, asking the hard questions, and working to build a future that serves human needs rather than corporate interests.

That gives me hope. And it makes me even more committed to being part of these conversations, to asking the hard questions, and to working with others who are trying to build a better future for our industry.

The Polyglot (Un)Conference and (Un)Conference like events continue to be one of the most valuable events in the software development community. If you’re looking for real conversations about real problems with real people, I can’t recommend it highly enough.

The conference was such a good time with such great topics, introductions, and interactions that I’ve already bought a ticket for next year. If you’re interested in joining the conversation, check out polyglotsoftware.com and grab your tickets at Eventbrite.