40 posts tagged with "ai"

I ended last time with: "Treat AI like a person. The confusion mostly goes away."

I still believe that. But "like a person" is more precise than it sounds — and most people are using it imprecisely.

The mistake is treating human capability as a single axis, and AI as a point somewhere on it. Better or worse, faster or slower, ready or not. The actual shape is jagged. Which makes it considerably more useful.

The frame isn't just "AI is like a person." It's more useful than that: human capability is the map. The places where AI still can't match a person are exactly where the interesting work is.

Two posts set up predictions that are now testable against field data.

DevOps at Scale predicted that organizations with mature DevOps — real SLO discipline, health-gated CI/CD, systematic observability — would be far better positioned for AI-native infrastructure than organizations that treated DevOps as theater. Who's Driving the AI-Native Organization? identified the TOIL wall: the empirical finding that Ops automation is dramatically harder than Dev automation, explained through the open/closed problem lens. The first 60% of operational toil is closed — known failure modes, documented runbooks. The stubborn residue behaves like open problems — novel situations, ambiguous signals, judgment calls about what the problem even is.

What I said then was that the wall is real. What I didn't say was whether it's permanent. This is the progress report on both predictions — and the argument for why the wall moves.

Prompt engineering. Context engineering. Spec-driven development. Harness. Loop engineering. Context minimalism. Tokenmaxxing.

A new term lands every week. The smartest people in tech are pouring into AI, and ideas collide fast — CTOs taking IC roles at Anthropic, researchers shipping frameworks before the last one has been absorbed. The vocabulary is exciting. It's also exhausting. And some of it turns out to be wrong.

Tokenmaxxing already showed cracks. Process-heavy agent frameworks are losing ground. Every few months something that felt foundational quietly gets replaced.

I kept looking for the underlying logic. What actually persists? Then a friend said something that stopped me mid-scroll.

"Treat AI as labor. Instead of inventing new concepts for something entirely unprecedented and making it increasingly complex, design your verification and management methods according to how you'd manage people."

That one sentence turned out to explain almost everything.

Everyone is writing AI-native organization manifestos right now.

Jack Dorsey published From Hierarchy to Intelligence in March, arguing that corporate hierarchy is a two-thousand-year-old information routing protocol that AI makes obsolete. Ivan Zhao wrote Steam, Steel, and Infinite Minds, framing AI as this era's miracle material — the steel of our gilded age. Both essays are worth your time. Both are also written from the CEO's chair.

I've been running the experiment from a different seat. At my previous company I started pushing the organization toward AI-native ways of working. This year the experiments have accelerated, on every layer I can reach: the development lifecycle, operations, and management itself. This post is the field report — what worked, where the walls are, and the one distinction the manifestos miss.

In From Cloud Native Apps to AI Native Agent Platforms: The Belts Are the Problem, I used the factory electrification story to make an argument about AI platform adoption: factory owners in the 1890s replaced steam engines with electric motors and kept the same belts, shafts, and building layouts. For thirty years, productivity barely moved. The breakthrough came when they reorganized the factory around the new technology — workflow-first, not power-transmission-first.

That post argued at the platform layer: the decisions organizations make about how to architect and run AI-native applications. The electrification analogy there was about keeping the wrong infrastructure assumptions while adopting new technology.

This post is one layer down — the development lifecycle itself. What happens to a team's coordination model when the implementation loop accelerates by an order of magnitude? The same pattern applies: if the team keeps the existing process assumptions while individual engineers adopt AI-accelerated workflows, the system neutralizes the gain.

With OpenSpec + Superpowers + Harness, I've run enough iterations to say the individual story is real. Features that used to take 2-3 days take hours. The workflow knows what done means. I'm not watching in between.

Then someone on the team wanted to use the same workflow. That's when I found out where the bottleneck had moved.

Anthropic's engineering team published a post on harness design for long-running apps. One line stopped me:

"Generators self-assess poorly — confident praise even for mediocre output."

I've been running OpenSpec's apply phase with a code review skill baked in. It runs in the same agent context as the implementation. The reviewer and the implementer are the same session. I read that line and immediately knew: that's my problem. The reviewer runs inside the same context that just wrote the code. The confidence is real. The bias is invisible.

That was the crack. This post is the fix.

This is part of the Agent Engineering track. Building a Personal Finance Knowledge Base with LLM Wiki built the knowledge base. Building an AI Agent: From Claude Skills to Production extended it into a production personal tool. This post is the next step: building an actual agent application — one that runs independently, serves multiple users, and doesn't require you to be sitting at a terminal.

I already had a working LLM Wiki setup. Structured Markdown files, Claude Code reading them at query time, a set of slash commands that composed into useful workflows. It worked well — for me, running it myself, from my own machine.

Three things eventually broke that model. First, I wanted my wife to be able to use it without opening a terminal. Second, the knowledge base grew past what fit cleanly in a context window. Third, I wanted a morning scan to run on a schedule rather than requiring me to trigger it manually.

None of those problems is hard to state. Each one requires a fundamentally different architecture to solve.

This post is the engineering record of what I built: python-agent, a multi-user knowledge base agent running as a self-hosted Docker application. LangGraph for orchestration, Qdrant for vector storage, Flask + Vue for the web layer. The domain is personal finance, but nothing about the architecture is finance-specific.

This is not a feel-good tutorial. The implementation decisions were right more often than wrong, but the failure modes were real — I'll describe four of them in detail. The point is not to discourage you from building agents; it's to give you a more accurate map of the terrain than the docs provide.

The engineers I worry about most aren't the juniors struggling to break in.

They're the 10-year veterans who've added AI tools to their workflow, are producing work at roughly the same pace they were 18 months ago, and have concluded that AI is "useful but overhyped."

The junior who's struggling at least knows there's a problem to solve. The senior who's plateaued often doesn't.

I published Stacking OpenSpec and Superpowers on April 19th — three weeks ago. The headline number was concrete: a refactor shipped in three hours, eighty-six new tests, zero regressions. I meant every word of it. At that time, that stack — OpenSpec's propose/apply/archive triplet (the framework also offers explore, but I'd been skipping it) over the three Superpowers skills I lean on most (brainstorming, test-driven-development, requesting-code-review) — was the best discipline I'd found for spec-driven development with AI in the loop.

What I didn't say — because I didn't know yet — is that the stack had five hidden cracks. They didn't show on a single refactor. They showed up the third, fourth, fifth time I ran it on a new project, when the workflow had to carry weight rather than win a sprint.

This post is the evolution. It's what I'd add to that earlier post if I had to write it again today, after running the stack across a couple more projects — most cleanly on python-agent, where I deliberately let each friction point speak for itself before designing the fix.

I'll spend the first half listing the five friction points (where the earlier stack hurt) and the second half on what I did about them (a three-step methodology abstraction plus four command-level fixes). Then I'll show the four-command, four-phase shape I ended up with, why this is still agile in the form you'd recognize, and the plugin I packaged so you can run the whole thing without re-reading either post.

If you haven't read the earlier post, the original entry point is there. This post assumes OpenSpec's four-command base (explore/propose/apply/archive) and the three Superpowers skills I just mentioned (brainstorming, test-driven-development, requesting-code-review).

One thing I want to flag up front: nothing in the evolution is a clever invention. Each fix was a response to a specific moment where the earlier stack produced output I didn't trust. The pattern that emerged is practice → friction → fix → harden. Methodology evolves by being run, not by being designed. The plugin at the end is the byproduct, not the goal.

I write about AI on this blog. Not "AI in general" — that's too big to write coherently about as a single topic. You end up writing platitudes. Instead, I write across four tracks, each anchored to a place where I've actually paid the cost of learning.

Since the start of the year, I've accumulated enough AI-related posts that it's time to step back and lay out the structure they fit into. This post is the map: what the four tracks are, why they hang together, what's already published in each, and what's coming next. If you've ever landed on the blog from one post and wondered whether the rest is worth your time, this is the index.