AI Title Inflation, GitHub Actions Security Gaps, and Enterprise Transformation Reality Checks

Don't Call Yourself a Software Engineer, You Are an AI Enabled Engineer

TLDR: A new wave of LinkedIn profile rebranding has developers slapping "AI Enabled" in front of their existing titles. The author argues this is mostly noise, and that the fundamentals of a good engineering career haven't changed because a new label is trending.

Summary: There's a certain ritual to every technology wave — everyone rushes to update their LinkedIn title before they've necessarily changed anything about how they work. The current obsession with "AI Enabled Engineer" follows the same pattern we saw with "Full Stack," "Cloud Native," and about a dozen other adjectives that cycled through the industry over the past two decades. The article draws on Patrick McKenzie's classic observation that calling yourself a Software Engineer rather than a programmer was already a meaningful career move, and asks whether "AI Enabled" is the next step in that same progression or just marketing copy applied to a resume.

The author's answer is pretty clear: the advice that actually moves careers forward is the same as it's always been. Write publicly. Build relationships. Communicate clearly with people who don't share your technical context. Show your work. None of that changes because the tooling now includes a large language model in the loop. The title you put on your profile is secondary to whether you can actually do the work and articulate why it matters.

What I find honest about this take is that it resists the pressure to perform transformation. There's real value in AI tooling right now, and genuinely skilled engineers are incorporating it into their workflows in meaningful ways. But the signal of that competence shows up in what you build and how you talk about it, not in a three-word title update. Chasing the label while skipping the substance is a pattern the industry has seen before, and it rarely ends well for the people doing the chasing.

The underlying tension here is worth sitting with. Titles do matter for visibility and for getting past recruiting filters. But the essay is right that the durable career investments are the ones focused on communication, relationships, and demonstrable output.

Key takeaways:

• Rebranding yourself as "AI Enabled" without changing your actual practice is largely cosmetic
• Career fundamentals — networking, writing, communicating — remain the same regardless of technology wave
• Titles can help with visibility, but substance and demonstrated output are what build durable careers
• The essay draws a direct line to Patrick McKenzie's classic advice about engineer vs. programmer framing

Why do I care: As someone who has watched the industry cycle through "ninja," "rockstar," "full stack," and "cloud native," I'm skeptical of title-first thinking. The engineers I respect most are the ones who can explain what they built and why it mattered, to a non-technical stakeholder, in under two minutes. Whether or not they've updated their LinkedIn bio to include "AI" is irrelevant. That said, I'd encourage every developer to actually learn these tools deeply rather than just wearing the label. The gap between "AI Enabled" as a title and as a genuine practice is exactly where careers stall.

Don't call yourself a Software Engineer, you are an AI Enabled Engineer.

GitHub - motherduckdb/obsidian-duckdb-motherduck: Obsidian Plugin for DuckDB and MotherDuck

TLDR: A new Obsidian plugin brings full DuckDB SQL querying into your notes, letting you query local and remote data files and freeze results as plain markdown tables directly in the note. It supports optional MotherDuck cloud integration and works entirely offline for local queries.

Summary: DuckDB has been one of the more quietly exciting tools in the data engineering space for a while now, and this plugin brings that capability directly into Obsidian in a way that feels surprisingly natural. You write SQL in a code block, the plugin runs it via DuckDB WASM, and the result lands as a plain markdown table right there in your note. Freeze it and the result becomes static, git-diffable, and readable without any plugin at all. That last detail matters more than it might seem at first.

The range of formats the plugin supports is genuinely broad. Parquet, CSV, JSON, Excel, Iceberg, Delta, and geospatial formats are all fair game for local queries. With a MotherDuck token you extend that to cloud-hosted data, and the plugin lets you pick per-block whether a query runs locally or in the cloud. For people who already live in Obsidian for notes and also work with data regularly, this removes a context switch that used to require opening a separate tool entirely.

The scheduled refresh feature is one of those small additions that turns a curiosity into a genuinely useful workflow tool. Set a block to refresh daily or weekly, and your note becomes a living dashboard rather than a snapshot you have to manually update. The activity log keeps a record of what ran and when. Row and cell caps prevent a runaway query from filling your editor with millions of rows.

From a developer experience standpoint, the plugin API for agent and CLI integration opens up some interesting possibilities. You could have an external script or agent trigger a query refresh and act on the result, which starts to close the gap between passive note-taking and active data tooling.

Key takeaways:

• Query Parquet, CSV, JSON, Excel, Iceberg, Delta, and geospatial files directly inside Obsidian notes via DuckDB WASM
• Results freeze as plain markdown tables, making notes fully git-diffable and readable without the plugin
• Supports scheduled auto-refresh (daily/weekly) and per-block connection selection between local DuckDB and MotherDuck cloud
• A plugin API enables agent and CLI integration for external automation
• Works fully offline for local queries; MotherDuck cloud blocks require a token and internet access

Why do I care: I'm always interested in tools that reduce the friction between where I'm thinking and where I'm querying. Obsidian already handles a lot of the note-taking and knowledge graph work for developers, and adding SQL over local files without leaving the editor is a meaningful quality-of-life improvement. The git-diffable frozen tables are particularly smart for reproducibility. If you're doing any kind of data exploration as part of your engineering work and you're already using Obsidian, this is worth ten minutes of your time to set up.

GitHub - motherduckdb/obsidian-duckdb-motherduck

TanStack Supply Chain Attack: 8 GitHub Actions Gaps Found Auditing 20 Repos

TLDR: In May 2026, TanStack/router was compromised through a GitHub Actions cache poisoning attack that extracted OIDC tokens and published 84 malicious npm packages. An audit of 20 repos immediately after revealed eight recurring vulnerability patterns, along with a detailed hardening checklist and a CLI scanner to catch them.

Summary: Supply chain attacks via CI pipelines have been a known risk for years, but seeing a widely-used project like TanStack/router actually get hit makes the threat feel a lot more concrete. The attack vector here was a fork pull request that poisoned the Actions cache, extracted OIDC tokens from the poisoned environment, and then used those tokens to publish malicious packages to npm under the TanStack namespace. Eighty-four packages. That's not a theoretical risk anymore.

The author audited twenty repositories in the immediate aftermath and found the same categories of misconfiguration appearing repeatedly. Unpinned action tags are probably the most common one — using a version tag like v3 instead of a full SHA means the action can change under you without any explicit approval from your side. Overly broad GITHUB_TOKEN permissions are the second major issue, where workflows run with write access to everything when they only need read access to one thing. Shell injection via expression interpolation is the sneaky one, where unsanitized GitHub context values get dropped directly into shell commands and can be manipulated by a malicious PR.

The pull_request_target trigger deserves its own paragraph because it's genuinely dangerous in a way that isn't obvious. It runs in the context of the base branch, not the fork, which means it has access to secrets. If your workflow uses pull_request_target and checks out or runs code from the fork without explicit precautions, you've handed an untrusted contributor your secrets. This has caused real incidents across multiple projects and keeps catching people off guard.

The hardening approach the post recommends is methodical: pin everything to full SHAs, apply least-privilege permissions at the workflow and job level, use environment variable indirection instead of putting GitHub context values directly in shell strings, inject credentials as late as possible in the job, separate build and publish jobs so compromise of one doesn't automatically compromise the other, run zizmor for static analysis, and configure Dependabot or Renovate to keep those SHA pins updated. The author's Sentinel Ruby CLI encodes all 21 checks and gives you a repeatable way to audit your own repos.

Key takeaways:

• TanStack/router was compromised via GitHub Actions cache poisoning in May 2026, resulting in 84 malicious npm packages
• Eight recurring vulnerability categories found across 20 audited repos: unpinned tags, broad token permissions, shell injection, checkout credential leakage, pull_request_target misuse, missing static analysis, stale SHA pins, and cache poisoning from forks
• SHA pinning, least-privilege GITHUB_TOKEN scopes, and environment variable indirection are the three highest-impact fixes
• The pull_request_target trigger is particularly dangerous and needs explicit handling to avoid secret exposure from fork PRs
• Sentinel is a Ruby CLI that encodes all 21 security checks for repeatable auditing
• Renovate is recommended over Dependabot for automated SHA pin management

Why do I care: GitHub Actions security is one of those areas where a lot of teams assume they're fine because they haven't been attacked yet. The TanStack incident should change that assumption. The eight vulnerability categories in this post aren't exotic or obscure — they're the defaults you get if you copy workflow examples from documentation without reading the security implications. If you maintain any open-source project that publishes to npm or has CI/CD, run through this checklist. The sha-pinning and permission scoping alone will close the most common attack vectors. I'm adding zizmor to my standard project setup going forward.

TanStack supply chain attack: 8 GitHub Actions gaps found auditing 20 repos

Melissa Reeve On AI Extinction Events, Unlearning Agile, and What Stage 5 Actually Looks Like

TLDR: An interview with Melissa Reeve, author of "Hyperadaptive," covers why companies have roughly 18 months to meaningfully adopt AI before competitive windows close, why human fear must be addressed before any technology gets deployed, and what leadership teams consistently get wrong when rolling out AI programs.

Summary: The framing of an "extinction event" for companies that don't move fast enough is deliberately provocative, but Reeve's reasoning behind it is worth engaging with seriously. Digital transformation gave most organizations a decade or more to get comfortable and catch up. The AI transformation window is compressing — her estimate is about 18 months before the competitive gap between early adopters and late movers becomes structural rather than recoverable. Whether that exact timeline is right is less important than the underlying dynamic: the compounding nature of AI-enabled productivity means the leaders pull further ahead faster than in previous technology cycles.

The interview's most useful section covers what actually goes wrong when leadership teams try to deploy AI. The most common mistake she describes is distributing AI licenses across the organization without any strategic direction about what problems those tools are supposed to solve. This creates scattered experimentation, a lot of individual time savings that don't add up to organizational capability, and a sense of motion without traction. The license becomes the deliverable instead of the outcome, and the board sees AI spend without AI results.

Reeve's model distinguishes several stages of AI-native maturity, and the interview gets specific about what Stage 4 looks like day-to-day — workflows where AI is embedded in decision-making rather than bolted on as a productivity tool for individual contributors. Stage 5, where any company currently sits on that level, involves genuinely redesigning organizational processes around AI capability rather than adapting existing processes to include AI. The distinction sounds subtle but the operational difference is significant.

The section on Agile is where I found the most to think about. Her argument is that Agile veterans bring habits that were hard-won and genuinely valuable in a slower-moving context — the sprint boundary as a forcing function for prioritization, for instance — but that those same habits can work against continuous learning in an AI-accelerated environment. Learning that happens in two-week chunks is already behind in a context where tools and capabilities are shifting weekly.

Key takeaways:

• The AI transformation window is roughly 18 months, compared to the decade available for digital transformation
• Distributing AI licenses without strategic direction is the most common and costly leadership mistake
• Human fear and resistance must be addressed before technology deployment, not after
• Stage 4 AI-native organizations embed AI in decision-making; Stage 5 redesigns processes around AI capability
• Agile veterans need to unlearn the idea that learning happens in sprints rather than continuously
• No companies are confirmed at Stage 5 yet

Why do I care: I have a lot of skepticism for transformation frameworks that promise to categorize your organization's AI maturity and sell you a consulting engagement. But Reeve's specific observations about what goes wrong are accurate in my experience. The license-as-deliverable problem is real and widespread. Engineering leaders who want to move faster need to start with a clear answer to "what problem does this solve and how will we know it worked," and then work backwards to the tooling. The point about Agile habits creating friction is also worth taking seriously — continuous integration of new capability is a fundamentally different rhythm than sprint-based delivery, and that tension is showing up in a lot of teams right now.

Melissa Reeve On AI Extinction Events, Unlearning Agile, and What Stage 5 Actually Looks Like