You Need AI That Reduces Maintenance Costs is a great article. You should definitely read it. It doesn't cover how to reduce maintenance costs with AI, though, so I thought I'd take a stab at that. First let's talk about the non-AI scenario.

How to Reduce Maintenance Costs without AI (traditional advice)

Before diving into how to reduce maintenance costs with AI, I think it's worth going over the traditional ways we might reduce costs:

1. Write less code. I'm not trying to be a smartass, I swear. The cheapest code to maintain is code that doesn't exist. Aggressively delete unused features and dead branches. Resist premature generalization - build for the problem you have, not the one you imagine (this one has been huge for me).

2. Favor boring, simple solutions. For example maybe just stick with React, or better yet, use plain HTML. Clever code is expensive code. Use mature, well-understood languages and frameworks; standardize on a small stack so you're not paying a cognitive tax across dozens of tools. This is what I used to do at the web agency I worked for. Then I automated creation of new projects. "Choose Boring Technology" by Dan McKinley is the canonical essay here.

3. Write tons of automated tests. Without a solid test suite, every change becomes risky and slow. Tests are what make refactoring safe, which is what keeps a codebase from rotting. A reasonable target is enough coverage that developers feel comfortable changing things without fear.

4. Refactor infinitely. Technical debt compounds. Small, ongoing cleanups are dramatically cheaper than periodic "rewrite the legacy system" projects. "Leave the code cleaner than you found it," should be the norm. NOTE: If you feel like being chaotic-neutral at work, which I sometimes like to do, start referring to the current system as the "legacy system."

5. Modular architecture with clear boundaries. Loose coupling and high cohesion let you change one part without breaking others. Architecture is a bit of a weak spot for me. AI can help me learn by applying specific architectures and walking me through them.

6. Good documentation. Document the "why," not the "what." Code shows what it does. What's missing is why a decision was made. Inline comments for non-obvious choices, and runbooks for ops scenarios save lots of time when someone unfamiliar (probably future-you) is debugging at 2am.

7. Strong observability. Good logging, metrics, and tracing turn hour-long debugging sessions into ten-minute ones. You only pay the cost once.

8. Invest in developer experience. Fast builds, fast tests, one-command local setup, fast CI. Every minute of friction multiplied by every developer over years adds up to staggering costs.

9. Manage dependencies carefully. Each dependency is a long-term liability. Prefer fewer, more mature ones. Keep them updated incrementally. Falling years behind on a major framework is one of the most common ways maintenance costs explode.

10. Knowledge transfer. Pair programming, code reviews, rotating ownership, and good onboarding docs reduce bus-factor risk. A system only one person understands is one resignation away from a crisis.

For starting a new project, see my Enterprise Project Checklist. For an existing codebase, here are ten ways to reduce maintenance costs with AI.

How to Reduce Maintenance Costs with AI

1. Write Less Code

Tell AI to delete some stuff. Ask it to find dead code, unused exports, unreachable branches, and duplicated logic that could be combined. That kind of audit used to be too tedious to do regularly. But AI is good at simplifying clever code, pointing out unnecessary abstractions, and spotting similar modules that should be merged. One could go so far as to set explicit "lines deleted" as a metric alongside features shipped, if one wanted to.

Audit this codebase for code that should be deleted or consolidated. Look for:

1. Dead code - functions, classes, or files that are never called or imported
2. Unused exports - public symbols with no consumers
3. Unreachable branches - conditionals that can never be true given surrounding logic
4. Duplicated logic - multiple places implementing the same thing with minor variations
5. Speculative abstractions - interfaces, factories, or generic wrappers with one
   concrete implementation and no near-term plan for more
6. Over-clever code that would be clearer as straightforward procedural code

For each finding, return: file and line range, category, a one-paragraph reason it's
a candidate for removal, and a confidence level (high/medium/low) with what would
change your mind.

Sort by confidence, highest first. Don't propose changes that require business
context you don't have - flag those as "needs human input" instead.

2. Boring Solutions

AI can lay out trade-offs between technology choices. Before adopting a new library or pattern, ask it what the maintenance implications are, what the common pitfalls look like, and what you give up by sticking with the boring option.

It's also useful for translating clever code into boring code. For example, it can turn a dense functional one-liner into the readable, debuggable equivalent. Push back when it suggests a pattern for what could be a function. Its training data over-indexes on enterprise patterns.

Audit this codebase for clever code that would be clearer as boring code.
Optimize for the person who will debug this at 2am with no context. Look for:

1. Nested ternaries, point-free chains, dense reduce/flatMap stacks, or
   functional one-liners that hide what the code is actually doing
2. Single-letter variable names outside trivial scopes
3. Deep nesting that could be flattened with early returns
4. Anonymous functions doing non-trivial work that should be named
5. Premature abstractions - factories, generic wrappers, or interfaces with
   one concrete implementation and no near-term plan for more
6. Macros, decorators, or metaprogramming where straightforward code would do

For each finding, return: file and line range, category, a one-paragraph
explanation of why a boring version would be clearer, a proposed rewrite,
and a confidence level (high/medium/low) with what would change your mind.

Sort by confidence, highest first. Skip code where the cleverness is earning
its keep - hot paths, library boundaries, places where the plain version
would be substantially longer. Flag those as "intentional - skipping"
rather than dropping them from the report.

3. Automated Tests

This is probably the biggest way to reduce maintenance costs with AI. AI can generate unit tests for code, propose edge cases humans tend to miss and write tests that lock in current behavior before you refactor. It can also find flaky tests, slow tests, and redundant tests, and convert integration tests into faster unit tests where that makes sense. There is absolutely no reason to have anything less than 100% code coverage. 100% is easy for AI to track. Anyway, going from 20% coverage to even 80% used to be a quarter-long slog. Now you can do it in a week.

Audit this codebase for test coverage gaps and weak tests. Aim for full
coverage by surfacing what's missing. Look for:

1. Public functions, methods, and exported modules with no tests at all
2. Tested code where only the happy path is covered, missing: null/undefined
   inputs, empty collections, boundary values (0, 1, max), unicode and
   encoding, concurrency, clock and timezone dependencies
3. Source code paths that aren't reached by any test
4. Tests that don't actually assert anything meaningful (no expects, only
   verifying that the code didn't throw)
5. Flaky tests, slow tests, and tests that duplicate what another test
   already covers
6. Integration tests that could be unit tests if a dependency were mocked

For each finding: file and line range (or test file), category, a
one-paragraph reason it matters, and a confidence level.

Sort by impact: untested code central to the system first, edge cases in
critical paths next, redundancy and flake last. For each untested function,
draft a test in the existing framework and style, including a one-line
comment on what it verifies. Flag any behavior you can't test because it
requires external state or context you don't have - don't fake what you
don't know.

4. Refactor Infinitely

The small refactors engineers used to skip - rename a poorly-named variable across the codebase, extract a duplicated block, split a 2,000-line file - become minutes of work. A weekly audit surfaces dozens in one pass, sorted by impact. "Leave it cleaner than you found it" used to mean 30 seconds at the end of each task. Now you sweep the whole codebase at once.

Audit this codebase for small refactors worth doing - the kind that used
to get skipped because they weren't worth the context switch. Look for:

1. Poorly-named variables, functions, or types (cryptic abbreviations,
   misleading names, single letters outside trivial scopes)
2. Duplicated code blocks that could be extracted into a function
3. Files over 500 lines that have grown two or more distinct
   responsibilities and should be split
4. Functions over 50 lines doing more than one thing
5. Long parameter lists (5+) that should be objects
6. Conditional ladders that should be lookup tables or polymorphism
7. Magic numbers and string literals that should be named constants

For each finding: file and line range, category, the current state, the
proposed refactor, estimated work (lines touched, files affected), and a
confidence level.

Sort by impact divided by risk - high-leverage, low-risk refactors first.
Don't propose refactors that require business context you don't have; flag
those as "needs human input."

5. Modular Architecture

AI can analyze a codebase for boundary violations: modules reaching into each other's internals, circular dependencies, leaky abstractions. Combine it with static analysis and get you a dependency graph plus the worst offenders highlighted. Then have it report back with suggestions. This one catches a lot for me.

For new code, AI can enforce architectural rules in code review. For existing, tangled systems, it's useful to propose where a monolith can be split, and for doing the mechanical work of moving code once you've decided.

Audit this codebase for boundary violations:

1. Modules importing each other's internals instead of going through a public interface
2. Circular dependencies between modules
3. Layer violations - a lower layer (data, infrastructure) importing from a higher
   layer (business logic, presentation)
4. Leaked abstractions - a module that's supposed to hide a detail but exposes it
   through return types, error messages, or required parameters
5. Modules that have grown two unrelated responsibilities and should be split
6. Two modules with overlapping responsibilities that should merge

For each finding: the modules involved and the specific import or call that's the
violation, why it's a problem concretely (what it couples, what it blocks), a
suggested fix including the rough shape of any new boundary, and a rough estimate
of how much work the fix is.

6. Good Documentation

AI can draft docs about decisions made from your commit history that might otherwise get buried. It can turn incident postmortems into first-draft runbooks, generate onboarding docs by reading the codebase, and correct docs that have drifted apart from the code.

The new problem is making sure AI-generated docs (and comments) show the reasoning, not just restating what the code obviously does. Some docs you might want to have are: architecture, auth, data-migrations, database, environment, features, design guide, and a test plan.

Audit this codebase's documentation. Compare what exists in /docs (or
equivalent) and any README files against what's actually in the code.
Look for:

1. Modules, features, or subsystems with no documentation at all
2. Documentation that describes behavior that no longer exists, or
   contradicts the current code
3. Decisions captured nowhere - non-obvious architectural choices, library
   selections, or design tradeoffs that a new engineer would have to
   reverse-engineer from git blame
4. Setup or operational steps documented partially but missing crucial
   details (env vars, gotchas, recovery procedures)
5. API surface that's documented for some endpoints or functions but not
   others
6. Comments that restate what the code does without explaining why

Useful targets if you find gaps: architecture, auth, data migrations,
database schema, environment setup, features, design guide, test plan.

For each finding: location, category, what's wrong or missing, what
should exist, and a confidence level. For each gap, draft the missing
documentation - capture the "why," not the "what." Cite commit messages,
PR descriptions, or comments when you can find the reasoning. If you
can't, mark it "needs human input" rather than inventing.

Sort by impact: things a new engineer would hit on day one first.

7. Strong Observability

AI can add logs, instrumentation, and analytics. It's also useful for writing alerts that catch problems without firing constantly, building better dashboards, and summarizing noisy log streams into something actionable. Over time, incidents resolve faster.

Audit this codebase and propose observability instrumentation. For each suggestion:
- Location (file and line)
- Type: log (with level), metric (counter/gauge/histogram), or tracing span
- Exact name and tags/attributes
- The question this instrumentation helps answer ("Is the payment gateway slow?"
  not "It logs the duration.")

Prioritize:
- Seams between services (network calls, queue publishes, DB queries)
- Decision points where the code chooses between paths
- Error handlers and retry logic
- Anything with a timeout, backoff, or circuit breaker

Don't suggest logging inside tight loops, logging that restates the function name,
or metrics no dashboard would ever look at. If you're unsure something's worth
instrumenting, leave it out.

8. Developer Experience

AI can audit your build, test, and CI pipelines for slowness and propose specific fixes like parallelization, caching, test splitting. It can write the scripts that make local setup one command. It's good at upgrading dev tooling, writing better error messages in internal tools, and generating IDE configs and pre-commit hooks tailored to your codebase.

Audit this project for developer experience problems. Look at:

1. Build config (package.json, Makefile, build scripts) - what's slow, redundant,
   or could be cached or parallelized
2. Test config - slow suites, sequential runs that could parallelize, repeated
   setup that could be hoisted
3. CI pipeline - jobs blocking other jobs unnecessarily, repeated work, missing
   caching
4. Local setup - how many commands does a new dev run before they can boot the
   app? How many implicit dependencies (specific Node version, local Postgres,
   env vars to copy)?
5. Error messages in internal tooling - anything that says "Error" with no
   actionable suggestion

For each finding: current state with the offending file/line, a concrete fix,
and estimated time saved per developer per day if you can estimate it. Sort by
impact (time saved × developers affected).

9. Dependencies

Major version upgrades that used to be quarter-long projects can often be done in days. AI reads the migration guide, applies the breaking changes across the codebase, updates the tests, and asks about anything that needs human judgment.

It can also audit your codebase for unmaintained dependencies, known vulnerabilities, or things that could be replaced with standard-library equivalents. Run dependency audits regularly.

Audit every dependency in this project. For each one, assess:

1. Currency - how many major/minor versions behind latest? When was the
   package last released? Is it still actively maintained?
2. Security - any known CVEs? Any transitive dependencies with known issues?
3. Necessity - how much of the dependency does this codebase actually use?
   Could it be replaced with standard-library equivalents or a few lines of
   in-house code?
4. Migration cost - for any major version we're behind on, read the
   migration guide and estimate the breaking-change surface area in our code.
5. Risk concentration - are we depending on multiple packages from a single
   maintainer or org that's a single point of failure?

For each dependency, return: name, current version, latest version, last
release date, maintenance status, CVE summary, usage scope in our code,
upgrade recommendation (upgrade now / upgrade soon / replace / remove /
leave alone), estimated migration effort, and a confidence level.

Sort by risk: unmaintained or vulnerable packages first, then large
version-lag packages with security implications, then everything else.
Don't suppress deprecation warnings to make things look healthier than
they are - if a deprecation will become a breaking change in the next
version, surface it.

10. Spread Knowledge

AI partially solves bus-factor risk by reading the codebase and producing the docs that should already exist. Anyone can ask "how does payments work in this system?" and get a useful answer, instead of waiting for the one person who built it. It can also generate role-specific onboarding curricula, summarize how features evolved over time, and create searchable indexes of past decisions. (The manual diagnostic lives in a few git log commands - same analysis, more typing.)

Don't let it replace human knowledge-sharing, though. Pair programming and code review still matter because they build judgment, not just transfer facts. Use AI for the "where is X?" questions so humans can focus on the "why did we decide X?" conversations that actually require dialogue.

Audit this codebase for bus-factor risk and produce documentation that
reduces it. The goal: any engineer should be able to answer "how does X
work?" by reading what you produce, without waiting for the one person who
built it. Look for:

1. Subsystems where git blame is dominated by a single author
2. Modules with no documentation, sparse comments, and non-obvious behavior
3. Critical paths (auth, payments, data migrations, anything customer-facing)
   that lack runbooks or onboarding notes
4. Tribal knowledge encoded in code review history, commit messages, or
   PR descriptions but not in any document a new engineer would find

For each high-risk area, produce a short knowledge doc covering: what the
subsystem does, how it works at a high level, why it's designed this way
(cite sources when you can), the failure modes worth knowing about at 2am,
and where to look first when debugging.

Ground every claim in specific files, functions, and line ranges. Skip
what's obvious from reading the code - focus on the why and the gotchas.
If two parts of the codebase contradict each other, say so. Mark anything
you couldn't determine as "needs human input" rather than inventing.

Sort output by bus-factor risk: highest concentration of single-author
ownership first.

Schedule the Prompts

You don't have to run these prompts manually. Claude Code has a /schedule slash command that sets up recurring runs as "routines" - saved configurations that fire on a schedule, clone your repo, and write back a report or open a PR. The Cowork tab in the Claude app does the same thing for people who'd rather not be in the terminal.

The setup is a conversation. Claude asks what you want to schedule, then handles the boring stuff: converting plain English into cron, scoping tool permissions, picking a model, and adding repo-specific context so the agent isn't completely cold when it wakes up next Monday.

Here's me setting up the dead-code audit (truncated):

❯ /schedule

● What should this agent do?

❯ [pasted the dead-code audit prompt]
  Let's use claude-opus-4-7. We can run it every Monday at 10 am.

● Quick conversion: 10am Monday America/Los_Angeles = 17:00 UTC.
  Cron: 0 17 * * 1.

  Here's the full config:
  - Name: Weekly dead-code audit
  - Schedule: 0 17 * * 1 (Mondays 10am PDT / 9am PST)
  - Model: claude-opus-4-7
  - Repo: dustinboston/dblogit-next
  - Tools: Read, Glob, Grep, Bash (read-only - analysis only)

  Prompt (your text, with a preamble so the agent has repo context):

      You are running a weekly dead-code audit on the dblogit-next repo
      (Next.js 16 App Router, TypeScript, Drizzle ORM, Vitest + Playwright).

      Focus on `src/`, `scripts/`, and `tests/`. Use Grep liberally to verify
      "unused" claims - search for the symbol across the whole repo, not
      just the file where it's defined. Remember that Next.js App Router
      files (page.tsx, layout.tsx, route.ts, server actions) are entrypoints
      and won't have explicit imports.

      [...original prompt...]

● Routine created.
  Next run: Mon, May 18, 10:08 AM PDT
  Manage: https://claude.ai/code/routines/trig_011f32v4Q9YuyH4xU1ZHTKBX

A few things to notice. "10am Monday" turned into 0 17 * * 1 automatically. I didn't have to think about timezones or learn cron. Claude added a preamble to my prompt with the repo's stack and a note about Next.js entrypoint files not having explicit imports, which is the kind of context-setting that makes a cold-start agent useful instead of confused. Tools were locked to read-only because the audit is analysis, not changes. I asked for Opus 4.7 instead of the Sonnet default since these audits are worth a bit more thinking.

All of these prompts work as routines now that they're framed as codebase audits. Setting them up takes about a minute each, and then I just read the PRs that show up Monday morning. The routines surface the work; the engineer in the loop still decides what to merge.

To reduce maintenance costs with AI, you don't need new advice. Most of it has been canon for decades, and every senior engineer would nod along reading the list. What changed is the cost. Maintenance work was always worth doing; it just wasn't affordable for most teams. Now it is.

Microsoft Exchange

Something we used to do in the early 2000's was host from home. You'd load up your servers on an old Dell PC and point DNS at your IP. A million years ago, I happened to get a bunch of Microsoft server licenses. I went ham and installed everything: Microsoft Exchange, Microsoft SQL Server, IIS, the works. Then one day there was a really bad storm that knocked the power out at my house. The Exchange server happened to be in the middle of indexing, and I lost a lot of email from family and friends. But it wasn't worth the effort to restore.

Then ISPs started blocking port 80. You had to do the work-around with dynamic DNS. Over time it just became a lot of effort. Editing config files, trying to understand all the quirky Windows UIs. Keeping the server up to date. Eventually I decided to stop hosting from home.

Self-Hosting on a VPS

I ran my own email server on Digital Ocean and self-hosted my websites with Mail-in-a-box. For the most part, it was pretty low touch. But those upgrades between Ubuntu versions were rough. The thing with Mail-in-a-box is that if you use all the features (i.e. Nextcloud), and if you have more than one user (I had my whole family on board), the costs start to go up. It was going to end up costing me a lot to keep up with the storage needs of the family. I finally got tired of being tech support and devops, so I took it all down, moved to Gmail like everyone else and started hosting on GitHub pages.

Application Hosting

But that left me wanting more from my websites. I vibe coded up a Next.js application and slid on over to Vercel. Now I live in fear of making it on Hacker News. I'm basically spending more time and money maintaining my websites than I ever have before. I'm paying for a SQLite database for crying out loud. It's a freaking file. They just make it so easy.

The Boring Internet is Kinda a Lot of Work

The point of all this rambling is that doing it The Old Way is great and nostalgic, but it also takes a lot of effort to keep it all going. And with every innovation there is an even higher financial cost. But Godier's right that the protocols are still there. SMTP didn't go anywhere, nobody took DNS public, the boring internet is humming along just fine.

What the essay doesn't quite say is that the cost of being a small participant on those protocols has quietly gone up. Running an MX record in 2003 meant your server was a peer on the network. Running one in 2026 means begging Gmail to like you so they don't send all of your email directly to spam. The protocols haven't changed but maybe the social contract around them has.

So my version of the boring internet is a little more bittersweet. I love that it's all still there. I want to be there. Maybe the next move is back down. Honestly though, I'm not sure I have the energy. That, I think, is what the veneer is really made of: convenience compounding until the alternatives feel like work.

I've been creating a lot of single page applications (SPAs) similar to Simon Willison's Tools page but it hadn't occurred to me to use HTML as an output format. Here are the basic arguments Tariq makes:

1. Markdown is becoming limiting

2. HTML has richer information density

3. HTML improves readability

4. It's easy to share HTML

5. Use cases span the SDLC

There are a few downsides though:

• HTML uses more tokens

• HTML takes longer to generate

• HTML is worse for diffs

I'll have to give this a try to see how it works.

What employees typed into their computer, how they moved their mouse, where they clicked and what they saw on their screen would be tracked, Meta said. The goal, the company said, was to capture employee data so Meta’s artificial intelligence models could learn “how people actually complete everyday tasks using computers.”

Here are five reasons that this is absolutely bonkers, and how employee surveillance for AI training is unethical.

1. No way to opt out

When an engineering manager asked Andrew Bosworth, CTO of Meta, about how to opt out, Bosworth noted that is not an option. Sure, the computers that employees use are property of Meta. And Meta can legally do whatever they want with their own devices. But that doesn't make it ethical. Ethical would mean that an employee has given consent to the collection of their data. But since Meta knew that nobody would consent, they made it into an issue of compliance. Now employment is conditional upon acceptance of surveillance. Employees weren't told about this policy when they were hired. Now they have to make the decision to stay with the company or quit, there's no real choice.

2. Coercive timing

Here's why I say there was no real choice. Facebook said they would lay off 10% of their workforce. Rolling out a plan to surveil employees weeks before layoffs was strategically timed to get people to leave. But if you think about it, folks generally aren't going to leave right before layoffs. The thinking is that It's better to stick it out and collect severance pay than quit on ethical grounds and get nothing. Meta may say that these events have nothing to do with each other. But it doesn't matter. The conditions of free choice were not there regardless of intent. Add Meta to the layoffs wall of shame.

3. Training replacements

In the Times article Susan Li, CFO of Meta, hinted that the size of the company would change due to A.I. capabilities.

We don't really know what the optimal size of the company will be in the future... I think there's a lot of change right now, with A.I. capabilities advancing rapidly.

Janelle Gale, the HR head, made it explicit in an internal message:

The cuts will allow the company “to offset the other investments we’re making,” Janelle Gale, Meta’s head of human resources, said in an internal message. She added, “I know this leaves everyone with nearly a month of ambiguity which is incredibly unsettling.”

How humiliating - train your own replacement - just to be let go. Let me spell this out. The company announces that there are going to be layoffs and then they say employee surveillance for AI training is mandated.

4. Sharing PII with Meta

Personally Identifiable Information (PII) will get swept up in the screen and keystroke capture. For example, when you type a password the keylogger will just eat it right up. It could also Hoover up health information, personal messages, confidential information. If they track the clipboard as well, there's literally no safe way to enter a password.

5. Inefficiency

AI doesn't need to watch you use your computer, because AI doesn't need to use a computer that way. I'll restate it differently. AI doesn't have the same constraints that humans have. Why tie AI to a slow user interface when it can operate a system using Unix-style commands at a much faster pace. "OK, wise guy," I hear you saying. "What if there are legacy apps with no APIs. AI could interact with it." Well, you're right, as long as you're not concerned about performance, compute per task, or visual parsing errors. Even if none of this was an issue, AI is still going to create more engineering work (in a good way).

And more...

• Zuckerberg's "not for surveillance" line collides with token dashboards already tied to performance reviews.

• "Agents to find agents" is Goodhart's Law in real time (when a measure becomes a target, it ceases to be a good measure).

• The idea that there "will not be a leak risk" is indefensible, but readers have heard this concern about every data program.

• It sets a bad industry precedent. We don't want even more companies surveilling their employees.

Employee surveillance for AI training is unethical

The case against Meta's program isn't that surveillance is new, or that AI training is inherently wrong, or that employees have an absolute right to privacy on corporate devices. But meaningful consent requires the genuine ability to refuse, and Meta has explicitly removed that ability. When the CTO confirms there is no opt-out. When the rollout lands three weeks before an 8,000-person layoff. When the data being captured includes keystrokes, screen content, and mouse movement. What's being asked of employees is not participation in a data program. It's compliance with a condition of continued employment, on terms they had no role in setting.

That's what makes employee surveillance for AI training ethically distinct from ordinary workplace monitoring. The traditional justification for watching workers is operational (security, productivity, legal compliance). Here, employees are being conscripted for commercial AI products, under conditions where objecting carries real career risk and the technical premise (that AI must learn by watching humans use computers) is itself a choice rather than a necessity.

The deeper problem isn't any single design decision but the pattern they form together: a company with the engineering capacity to do this differently has chosen the path that extracts the most from the people with the least power to say no. Whatever the eventual capabilities of the resulting AI, the precedent being set - that workforce-scale behavioral capture is an acceptable cost of staying competitive - is one other employers will follow, and one that will be much harder to walk back than it was to begin.

Here's a picture of a kid to calm your nerves. Just look at those tiny horns and that devilish grin. (Photo by Gordon Milligan)

Changes have been rolling out across WordPress.org after Matt Mullenweg recently created a new channel on WordPress Slack, giving a small group of trusted contributors the authority to overhaul the site without approval from any team, committee, or stakeholder other than himself.

Interesting that just 12 people have been granted access. We used this same "Tiger Team" approach at Disney when we migrated Hulu into the Disney platform. Small teams with broad authority can move much faster. It's a good call, but it's a Band-Aid. Once the overhaul is complete, and the team is disbanded, who will keep the site from rotting again?

I accidentally truncated the whole posts table because of a misunderstanding about how Drizzle works. But hey, I didn't panic so that's good. What I did do: looked for a backup, realized it was two months old, cursed my own name. Then, I pieced together whatever I could, which was about 30 posts short of what I actually had. I restored it and found a bug in my restore logic. Of course. Yack shaving time.

Fast forward a couple of hours. The fix was in. I had to truncate the tags/posts table because the IDs for the posts I found were different from the post IDs in the lookup table. That caused an error when I tried to import. Still missing about 30 posts.

As I was combing through my downloads folder, I found a full backup from days ago. I don't even remember making it. Thank the database gods.

Adds the loading attribute to video and audio elements, letting developers defer media resource loading until the element is near the viewport using loading="lazy". This matches the existing lazy loading behavior for and elements, improving page load performance and reducing data usage.

They also shipped a new prompt API. Nobody's happy about that.

• There's a keyword in the title. [kb][topic] (weight 7)

• And it's at the beginning. [kb][topic] (weight 4)

• There's also a keyword in the meta description. [kb][topic] (weight 6)

• And in the URL slug. [kb][topic] (weight 5)

• There's a keyword in the content. [kb] (weight 6)

• And it appears in the first 10%. [kb] (weight 5)

• At least one subheading contains a keyword. [kb][topic] (weight 5)

• The keyword appears in image alt text. [kb][topic] (weight 5)

• Keyword density is between 0.75 and 2.5. [kb][topic] (weight 6)

• Focus keyword has not been used on another post. [kb][topic] (weight 4)

• Content is >= 2,500 words long. [kb] (weight 7)

• URL slug is less than or equal to 75 characters. [kb][topic] (weight 3)

• Content has at least 1, preferably three or more internal links. [kb] (weight 5)

• Content has at least one external link. [kb] (weight 5)

• Content mixes internal and external links. [kb] (weight 3)

• There is a sentiment word (positive or negative) title. [kb] (weight 3)

• A power word is in title. [kb][blog] (weight 3)

• The title contains a number. [kb] (weight 3)

• There is a table of contents. [kb] (weight 3)

• All paragraphs are under 120 words. [kb] (weight 6)

• There are images or media. [kb] (weight 6)

Table of Contents

• Start With Intent, Not Keywords

• Do Real Keyword Research for Blog Post SEO

• Write With First-Hand Experience

• Nail the Headline and First 100 Words

• Modern Blog Post SEO Means Optimizing for AI Search

• Build Topical Authority, Not Orphan Posts

• Get the Technical Fundamentals Right

• Earn Links the Slow Way

• Match Format to Reader Behavior

• Don't Ignore Voice and Visual Search

• Update Old Posts Ruthlessly

• Track What Matters, Ignore What Doesn't

• Be Patient

• Have I Ranked?

Start With Intent, Not Keywords

Ranking a blog post in 2026 is less about gaming the algorithm and more about being the best answer for a real query. Modern blog post SEO rewards depth, originality, and intent-matching far more than keyword tricks.

Before you write a word, search the term you're targeting and study the top 10 results. What format is winning — a listicle, a deep guide, a comparison, a how-to? What questions do they answer? What do they miss? Your job isn't to mimic them; it's to write something that makes them look incomplete. A post targeting "best running shoes for flat feet" beats anything generic about running shoes — match the specific intent or don't bother.

Search intent generally falls into four buckets: informational ("how does compound interest work"), navigational ("Rank Math login"), commercial ("best email marketing tools"), and transactional ("buy noise canceling headphones"). Each demands a different post structure. Informational queries want thorough explainers with diagrams. Commercial queries want comparison tables, pros and cons, and clear recommendations. Mismatching intent is the single most common reason a well-written post fails to rank — and it's the foundation of all good blog post SEO. Google has decided what searchers want, and you don't get to override that with great prose alone.

Do Real Keyword Research for Blog Post SEO

Keywords aren't dead — they're just not the whole game. Effective blog post SEO still requires knowing which terms people actually search for, how often, and how hard they are to rank for. Free tools like Google Keyword Planner, Google Trends, and AnswerThePublic give you a starting point. Paid tools like Ahrefs, Semrush, and Mangools go deeper with difficulty scores, click-through rate estimates, and SERP analysis.

The trick is targeting keywords you can actually win. A new site has no business chasing "credit cards" — that's a battlefield owned by NerdWallet and Bankrate. But "best credit cards for freelancers with irregular income" might have only a handful of mediocre results competing for it. Long-tail keywords (three or more words, more specific) typically have lower volume but much higher conversion intent and far less competition. Build your content calendar around these wins, then graduate to harder terms as your site's authority grows.

One more nuance: don't optimize a single post for one keyword. A modern approach to blog post SEO targets a primary keyword plus 10–30 semantically related terms. Google's algorithms reward content that comprehensively covers a topic, not content that mentions one phrase repeatedly.

Write With First-Hand Experience

Google's helpful content system and the rise of AI Overviews have made one thing clear: the web doesn't need another summary of summaries. If you've actually done the thing, tested the product, or worked in the field, that signal — the "E" in E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) — shows up in screenshots, original photos, specific numbers, and opinions other articles wouldn't risk. Pure AI-generated rewrites of existing content are getting filtered out at scale.

Practical ways to inject experience into a post: include before-and-after screenshots from your own dashboard, share specific numbers from your own results (revenue, traffic, time saved), name the exact tools and versions you used, describe a mistake you made and what it cost you, and quote real conversations with experts in your field.

A post titled "How I Reduced My Page Load Time From 4.2s to 0.8s" will outperform "How to Speed Up Your Website" every time, because the first signals lived experience and the second smells like AI slop. Experience is the most underrated input in blog post SEO.

Nail the Headline and First 100 Words

Most readers (and AI summarizers) decide whether your post is worth their attention in the first few seconds. Your H1 should promise a specific outcome, not tease it — "How to Cut Your AWS Bill by 40% in a Weekend" beats "Saving Money on Cloud Hosting" every time. Then deliver on that promise immediately. The opening paragraph should answer the core question or state the thesis up front, with the supporting detail below. This isn't just good writing; it's how AI Overviews and featured snippets pick which passage to quote. Burying the lede in 2026 means burying your traffic.

The same logic applies to your meta description and title tag, which appear in search results. The title tag should include your primary keyword near the beginning and stay under 60 characters so it doesn't get truncated. The meta description (around 155 characters) doesn't directly affect rankings, but it heavily influences click-through rate, which does. Write it like ad copy: include the keyword, hint at the value, and create a small reason to click. A post that ranks #3 with a great snippet often gets more traffic than a post that ranks #1 with a boring one.

Modern Blog Post SEO Means Optimizing for AI Search

A growing share of searches now end inside Google's AI Overviews, ChatGPT, Perplexity, and similar tools without a click to your site. To get cited in those answers, structure content so individual passages can stand alone: clear question-style subheadings, direct answers in the first sentence under each, and definitive statements rather than wishy-washy hedging. Schema markup is now a core part of blog post SEO — FAQ, HowTo, Article, and Product schemas help machines understand what your page is about and increase your chances of being surfaced.

The data backs this up. The 2025 Web Almanac found that AI systems are beginning to rely on the same SEO practices that have always served human searchers — but with a twist: visibility now means being understood by AI, not just crawled. Crawlability and indexability are getting more complex as bots multiply and rendering paths fragment, while the fundamentals like consistent titles and headings remain stable (meta descriptions are even rebounding after years of decline). On the structured data front, JSON-LD is now the dominant format for schema markup and AMP has fallen below 1% adoption — so if you're still wiring up AMP pages, stop, and put that energy into JSON-LD instead.

This shift toward "zero-click" search means your job has split in two: you still want clicks, but you also want to be the source AI tools cite when they don't send a click. Citations build brand recognition and authority over time, even when traffic doesn't immediately follow. Original research, unique data points, and clear definitions are particularly likely to be quoted. If you publish a stat in 2026, expect it to show up in someone's AI-generated answer next month — make sure your name is attached.

Build Topical Authority, Not Orphan Posts

One great article on a niche site usually outranks a great article on a generalist site, because Google rewards depth in a subject. Plan content in clusters — a pillar post plus 5–10 supporting pieces that link inward — rather than a scattershot of unrelated topics. Internal linking with descriptive anchor text is one of the most underused on-page levers.

Here's how a content cluster works in practice. Say you run a personal finance blog. Your pillar post might be "The Complete Guide to Index Fund Investing" — a 4,000-word definitive resource. Around it, you build supporting posts: "VTSAX vs VTI: Which Should You Choose?", "How to Open a Vanguard Account in 10 Minutes", "Tax-Loss Harvesting With Index Funds", and so on. Each supporting post links to the pillar, and the pillar links out to each supporting post. Google sees this network and concludes your site has genuine depth on index fund investing — and starts ranking all the posts higher together. This is blog post SEO at the architectural level, not the page level.

Get the Technical Fundamentals Right

A post that takes four seconds to render on mobile won't rank no matter how good it is. Compress images, use a fast theme, and pass Core Web Vitals. Make sure your title tag is compelling and under about 60 characters, your meta description is genuinely useful (not stuffed), your URL is short and readable, and every image has descriptive alt text. None of this technical blog post SEO ranks you alone, but missing it bleeds rankings you've already earned.

Core Web Vitals deserve specific attention. Google measures three things: Largest Contentful Paint (how fast the main content loads, target under 2.5 seconds), Interaction to Next Paint (how quickly the page responds to clicks and taps, target under 200ms), and Cumulative Layout Shift (how much the page jumps around as it loads, target under 0.1). Run any post through PageSpeed Insights and fix what's flagged. The most common culprits are unoptimized images, render-blocking JavaScript, and too many third-party scripts (analytics, chat widgets, ad networks). Each one you remove typically buys back hundreds of milliseconds.

Earn Links the Slow Way

Backlinks are still one of the strongest ranking signals, and there's no shortcut that lasts. The reliable plays are creating original data or research worth citing, writing the definitive piece on something underserved, and being a real person on social platforms where journalists and bloggers in your space hang out.

What doesn't work in 2026: buying links, mass guest posting on low-quality sites, private blog networks, and "link exchanges." Google's algorithms catch these reliably, and the penalty often outweighs years of legitimate work. What does work: publishing original studies (even small ones — a survey of 200 people in your niche can generate dozens of links), creating free tools that solve a specific problem, contributing thoughtful guest posts to genuinely respected publications in your industry, and building relationships with journalists by being responsive on platforms like Source of Sources (the spiritual successor to HARO, which shut down in late 2024), Featured.com, or Qwoted. Quality over quantity always — five links from authoritative sites in your niche outweigh 500 links from random directories.

Match Format to Reader Behavior

Walls of text lose. Today's readers scan first and read second, especially on mobile, where most of your traffic now lives. Break content with descriptive subheadings every 200–300 words, use short paragraphs (2–4 sentences), and lean on bulleted or numbered lists when you're enumerating steps or items. Add a table when you're comparing options — Google often pulls tables directly into search results. Embed an original chart, diagram, or annotated screenshot if you can; visual assets keep readers on the page longer, which sends positive engagement signals, and they're far more likely to attract organic backlinks than another wall of prose.

Pay attention to readability too. Tools like Hemingway Editor flag passive voice, complex sentences, and reading-level scores. Most blog content should land at a 7th-to-9th-grade reading level — not because your audience is unsophisticated, but because clarity beats cleverness. Even academic readers prefer clean prose when they're skimming for an answer. Save your literary flourishes for fiction.

Don't Ignore Voice and Visual Search

Roughly 30% of searches now happen by voice, and visual search (Google Lens, Pinterest Lens, AI tools that accept image inputs) is growing fast. Voice queries tend to be longer and more conversational — "what's the best way to remove a coffee stain from a white shirt" rather than "remove coffee stain shirt." Optimize for these by including natural-language questions as subheadings and answering them directly underneath. Visual search rewards properly tagged images: descriptive filenames (red-leather-handbag.jpg, not IMG_4823.jpg), thorough alt text, and image schema markup. If you sell products or feature objects in your content, treating images as a search surface — not just decoration — opens a traffic channel most competitors are ignoring in their blog post SEO strategy.

Update Old Posts Ruthlessly

Most blogs leave traffic on the table by publishing and forgetting. Twice a year, audit posts that rank on page two or are slipping. Update facts, add new sections, refresh examples, improve internal links, and republish with the new date. This is often higher-leverage than writing new content, and it's the single most overlooked tactic in blog post SEO.

A practical refresh checklist: update any statistics older than 18 months, swap out screenshots that show outdated UI, add a new section addressing a question that's emerged since publication, check that all outbound links still work and replace dead ones, look for new related posts you've written that could be linked internally, and rewrite the title and meta description if click-through rate is below 2%.

After republishing, request reindexing in Google Search Console so the changes are picked up quickly. Posts I've refreshed have routinely jumped from position 12 to position 4 within a few weeks — for free, using content that already existed.

Track What Matters, Ignore What Doesn't

Vanity metrics will mislead you. Don't obsess over your Rank Math SEO score, keyword density, or how many words you've written — none of these correlate strongly with rankings. (Rank Math themselves publish a guide on hitting 100/100 that's worth reading specifically so you understand what their score does and doesn't measure.)

Focus on the metrics that actually predict traffic: impressions and average position in Google Search Console, click-through rate on your title tags (anything under 2% on page one means your title needs work), and engagement signals like time on page and scroll depth in your analytics. If a post gets impressions but no clicks, the problem is your title or meta description. If it gets clicks but visitors bounce in seconds, the content didn't deliver on the promise.

Set up a simple monthly review. Pull your top 20 posts by traffic and look for trends — which are climbing, which are slipping, which haven't been touched in a year. Pull your bottom 20 posts and decide whether each is worth fixing, consolidating with another post, or deleting outright. Yes, deleting. Thin or outdated content actively hurts your site's overall authority because it dilutes your topical focus. Pruning 50 weak posts can improve rankings on the 200 you keep — counterintuitive but proven blog post SEO hygiene.

Be Patient

New posts on established sites can rank in days; new posts on new sites often take six months even when everything is right. Blog post SEO compounds — the value isn't in one post, it's in fifty posts working together over two years.

The hardest part of SEO is the gap between effort and result. You publish a great post, and nothing happens for weeks. You write another. Still nothing. Then in month four, the first post starts pulling in 50 visitors a day, and by month eight it's at 500. By month eighteen, you have a portfolio of posts each pulling steady traffic, and the cumulative effect is real. Most people quit in month three. The ones who keep showing up — publishing, refreshing, internal linking, building real authority — are the ones who eventually own their niches. There is no shortcut. There has never been a shortcut. The shortcut is starting two years ago, and the next-best time is today.

Have I Ranked?

You'll typically know your page has ranked when it starts showing up in search results for the keywords you targeted — but the easiest way to track this systematically is through Google Search Console. Once your page is indexed (usually within a few days to a few weeks of publishing), check the Performance report and filter by the page URL. You'll see the queries it's appearing for, your average position, impressions, and clicks. A position of 1–10 means you're on page one; 11–20 means page two, and so on.

Don't trust what you see by Googling the keyword yourself — personalized results, your location, and search history all skew what you see, making it look like you rank higher than you actually do. Use an incognito window with location set neutrally, or better, a rank tracking tool like Ahrefs, Semrush, or the keyword tracker built into Rank Math Pro to monitor positions over time.

The clearest signal you've truly ranked is sustained organic traffic to the post showing up in your analytics — once Google sends you clicks consistently for a target query over a few weeks, you've earned the spot rather than just briefly visited it.

Five git log commands that diagnose a new codebase before you open a single file: code churn hotspots, bus factor, bug clusters, and crisis patterns.

Here are the commands, for quick reference:

# What changes the most?
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

# Who built this?
git shortlog -sn --no-merges

# Where do bugs cluster?
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

# Is this project accelerating or dying?
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

# How often is the team firefighting?
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

Source: The Git Commands I Run Before Reading Any Code

1. The user can create memories at any time with a slash command.

2. Memories go into a folder and then the memory index file is updated with a link to each memory.

3. The memory index file is injected into the system prompt.

4. On each turn extract memories from the conversation into memory files. GOTO #2

5. Memories are consolidated in the background once a day.

He says that the productivity gap among 1x, 10x, and 100x engineers using AI coding agents has almost nothing to do with model quality. Instead, the difference comes from the architecture wrapped around the model. Tan calls this the harness, and the central claim is that the harness, not the model, determines whether someone gets mediocre results or transformative ones.

The idea is that modern models already know how to reason, synthesize, and write code. Model failures come from not understanding the specific environment they are working in. The harness exists to give the model the right context at the right moment, without overwhelming it with irrelevant information. Tan describes reading the leaked Claude Code source and discovering that the real magic is not in the model but in the wrapper that orchestrates it. Can confirm.

To explain how this works, Garry introduces five concepts: skill files, the harness, resolvers, latent and deterministic work, and diarization. These form the backbone of a system that can scale from simple tasks to complex knowledge work.

1. Skill Files

Skill files are reusable markdown documents that describe a process. They don’t tell the model what to do; they tell it how to do it. The user supplies the goal, and the skill supplies the method. Tan compares a skill file to a method call with parameters. A single skill can be invoked in many different contexts, producing different outcomes depending on the arguments. Tan argues that markdown is a better medium for encoding judgment and process than traditional code, because it matches the model’s native mode of thinking.

2. The Harness

The harness is the minimal program that runs the model. It loops the model, manages context, reads and writes files, and enforces safety. Tan warns against building a bloated harness full of tools and abstractions that slow everything down and clutter the context window. His ideal harness is thin, while the skills are fat. Modern software no longer needs to be precious or over‑engineered; it should be fast, narrow, and purpose‑built.

3. Resolvers

Resolvers act as routing tables for context. They decide what documents to load when a certain type of task appears. Without resolvers, developers tend to stuff everything into a single giant prompt, which degrades the model’s attention. With resolvers, the system loads only the relevant documents at the right time. Tan describes how their own massive CLAUDE.md file became unmanageable until they replaced it with a small resolver that pointed to the right documents on demand.

4. Latent vs Deterministic Work

The distinction between latent and deterministic work is another key idea. Latent space is where the model exercises judgment, interpretation, and synthesis. Deterministic space is where reliability matters: SQL queries, arithmetic, and other operations that must produce the same output every time. Problems arise when tasks that belong in deterministic space are forced into latent space. Scale forces us to handle queries deterministically.

5. Diarization

Diarization is the process of reading a large body of material and producing a structured profile that captures the essential judgments. This is something neither SQL nor RAG can do. It requires the model to read, compare, notice contradictions, and synthesize. Tan argues that diarization is the key to making AI useful for real knowledge work.

Architecture

These five ideas combine into a three‑layer architecture. At the top are the fat skills, which encode judgment and process. In the middle is the thin harness, which orchestrates the model. At the bottom is the deterministic layer, which handles reliable operations like database queries and file access. The guiding principle is to push intelligence upward into skills and push execution downward into deterministic tools.

The article ends with a principle: if a task will need to be done more than once, it should be codified into a skill. Skills become permanent upgrades. They never degrade, and they improve automatically when models improve. This compounding effect, not smarter models, is what produces the dramatic productivity gains described at the beginning.

Module 1: Scaffolding & Configuration

• Domain: Project initialization, environment strictness, and repository metadata.

• Execution Independence: Can run immediately upon repository creation.

• Version Control (.gitignore): Must omit node_modules, build directories (dist/build), .env files, OS artifacts, and IDE configs.

• Configuration Validation: Environment variables must be validated at runtime startup (e.g., via Zod or Joi). No hardcoded credentials or environment-specific URIs in source code.

• System Documentation (CLAUDE.md): Must exist at root. Requires: system overview, package script definitions, environment setup steps, and architectural links.

• Licensing: Default to CC BY-NC 4.0. For proprietary code, package.json must state "license": "SEE LICENSE IN <filename>" and "private": true, with a corresponding custom license file.

Module 2: Code Quality & Type Safety

• Domain: Static analysis and syntax enforcement.

• Execution Independence: Can run as a continuous background linting/typing agent.

• Type Strictness: TypeScript tsconfig.json must have "strict": true. Zero tolerance for any types, non-null assertions (!), or type casting (as Type).

• Linting Rules: Must implement xo configured for maximum strictness. Pre-commit hooks must block non-compliant code.

• Dependency Auditing: Lockfiles (package-lock.json / yarn.lock / pnpm-lock.yaml) must be present. Automated vulnerability scanning (e.g., npm audit or Dependabot) must pass with zero critical/high vulnerabilities.

Module 3: Architecture & State

• Domain: System design, persistence layers, and local infrastructure.

• Execution Independence: Requires schema and system design definitions.

• Architectural Patterns: Enforce separation of concerns (e.g., controllers, services, repositories). File structure must reflect domain-driven or strictly layered architecture.

• Data Persistence: Database schemas (e.g., PostgreSQL for relational, Pinecone for vector data) must use migration scripts. No manual schema modifications.

• Containerization: Local dependencies (databases, cache, messaging queues) must run via docker-compose.yml. Applications should have multi-stage Dockerfile definitions for production builds.

Module 4: Security & Safeguards

• Domain: Threat mitigation, access control, and data protection.

• Execution Independence: Can review PRs for security anti-patterns in parallel with testing.

• Secrets Management: All cryptographic keys, API tokens, and database credentials must be encrypted at rest and injected via secure managers (e.g., AWS Secrets Manager, HashiCorp Vault). Require key rotation mechanisms.

• Destructive Operations: Any DELETE or DROP operations must implement soft-delete (boolean flags) or robust undo mechanisms. All destructive actions require an immutable audit log entry (actor, timestamp, action, resource).

• API Contracts: Endpoints must have defined input/output schemas (e.g., OpenAPI/Swagger) to prevent injection and enforce strict payload boundaries.

Module 5: Resilience & Traffic Management

• Domain: System stability under load and failure conditions.

• Execution Independence: Can evaluate network and service-layer code.

• Error Handling: Implementation of try/catch on all asynchronous operations. Downstream service calls must implement the Circuit Breaker pattern to prevent cascading failures.

• Rate Limiting: Ingress traffic must be rate-limited by IP or API key. Outbound retry logic must implement exponential backoff with jitter to prevent thundering herd problems.

Module 6: Telemetry & Monitoring

• Domain: Observability, health tracking, and incident alerting.

• Execution Independence: Can verify infrastructure-as-code and application middleware.

• Observability (Logs, Metrics, Traces): Structured JSON logging must be enforced. Spans and traces must follow requests across system boundaries (e.g., OpenTelemetry).

• Monitoring & Alerting: Integration with APM tools. Endpoints must include a /health or /live route checking DB connectivity and memory usage. Usage analytics must be tracked without logging PII.

Module 7: Verification & Delivery

• Domain: Automated testing and deployment.

• Execution Independence: Runs post-build, parallelized across test runners.

• Test Coverage: Strict 100% code coverage requirement across three layers:

  • Unit Tests: Isolated logic, mocked dependencies.

  • Integration Tests: Cross-module and database interactions.

  • E2E Tests: Full user journey simulation.

• CI/CD Pipeline: Automated pipelines (e.g., GitHub Actions) must execute linting, type-checking, and testing. Merges to main require automated semantic release creation and deployment script execution.

Module 8: Documentation Context

• Domain: Knowledge transfer and operational guides.

• Execution Independence: Runs asynchronously, reviewing code to update docs.

• API Documentation: Auto-generated from code annotations or strict Markdown.

• Operational Guides: Must include a deployment guide, security considerations matrix, and a CONTRIBUTING.md outlining local setup and PR standards.

The next time you begin your workday, try this: clear your work surface completely. Close all browser tabs. Create a fresh page in your notebook. Open only the one file you need.

Source: "Nothing" is the secret to structuring your work

1. The cognitive ceiling. Research by Ericsson, Mark, and Newport shows that 3-4 hours is the daily maximum for concentrated effort. Beyond that, diminishing returns.

2. Where developer time actually goes. Data reveal that the median coding time is 52 minutes/day. Meetings consume 11+ hours per week, pushing peak coding to the afternoons when mornings should be prime.

3. The cost of interruptions. 23 minutes to recover from one interruption. For programmers, 30-45 minutes to rebuild the full context. A single meeting can destroy an entire afternoon.

4. Flow as a force multiplier. Csikszentmihalyi’s research: 500% increase in productivity in the flow state. But flow requires 15-25 minutes of uninterrupted time just to begin.

Agency is the ability to hold the entire [development] loop in your head and act on it. What does the user actually need? What should this feel like to use? What's the fastest way to build it that isn't embarrassing? How do we know if it worked? A high-agency person can move through that whole sequence without waiting for someone else to hand them the next step.

Source: Agency