I have been making these little single page, local-first, PWA's a lot lately. For example, I created a habit tracker that is integrated with a calendar. Now I don't know why you'd want to run WordPress as a PWA - I'd personally go with TiddlyWiki - but it's a cool idea.

Anyway, they didn't rebuild WordPress for this use-case. Instead, they compiled the PHP interpreter to Web Assembly. Then WordPress is bundled and loaded into an in-memory virtual filesystem. Finally, WordPress is executed as normal using PHP.

You can read more about the architecture here.
And here's the "Press Release".

Sid Ramesh argues that true defensibility is not a moat you build at the end - it’s a direction you compound in. The seven compounding advantages:

1. Proprietary, compounding data, that improves the product with every interaction and cannot be shortcut. For example, Spotify’s decade of listening behavior.

2. Infrastructure‑level trust including reliability, uptime, auditability, and deep integration into workflows. Stripe isn’t just a tool - it’s plumbing. Switching costs come from risk, not fees.

3. Permission moats (regulatory, compliance, licenses) are slow to build, impossible to copy quickly. Coinbase’s years of licensing became a structural advantage once regulators cleared them.

4. Distribution you can’t copy with code, like being the default, the marketplace integration, or the ecosystem hub. Hyperliquid became the coordination layer for decentralized derivatives.

5. Community and brand that exist beyond the product. Notion’s ecosystem of templates, creators, and workflows is uncopyable. You can clone the editor, not the culture.

6. Capital and liquidity depth like Aave’s safety module, loss history, and liquidity pool create a moat no fork can replicate. Liquidity begets liquidity.

7. Physical infrastructure such as warehouses, sensors, manufacturing, logistics, charging networks - atoms don’t compress like bits.

So, the real question is "How do I build something that gets harder to kill the longer it exists?" Most founders chase growth, demos, and pitch decks instead of building something that would materially hurt users if it disappeared.

Durability starts with obsession over a specific user, not a market size slide.

The Popover API is one of the most versatile additions to the web platform in recent years. A single attribute - popover - gives any element top-layer promotion, light-dismiss behavior, and accessible focus management for free. But the API is not one-size-fits-all. Depending on the interaction pattern, you can lean entirely on HTML attributes, mix in a little JavaScript, or take full manual control.

This post walks through four real components that each use the Popover API differently, arranged from the most declarative to the most imperative.

1. Popover

The simplest use of the Popover API requires zero JavaScript. A popovertarget attribute on the button points at the popover's id, and the browser wires up all the toggle logic automatically.

<button type="button" popovertarget="p1">Open popover</button>
<div id="p1" popover>
  <h4>Dimensions</h4>
  <p>Set the dimensions for the layer.</p>
</div>

[popover] {
  inset: unset;
}

The bare popover attribute defaults to auto mode, which gives you two behaviors for free: light-dismiss (clicking outside closes the popover) and exclusive stacking (opening one auto popover closes any other). The popovertarget attribute defaults to toggle behavior — click once to open, click again to close. The CSS resets inset: unset because the browser applies a default inset: 0 to popover elements, which would center them in the viewport rather than letting us position them near the trigger.

2. Tooltip

Tooltips need popover="manual" because they should never light-dismiss — the user did not click to open them, so clicking elsewhere should not be intercepted. They also should not compete with other popovers for exclusive stacking; a tooltip and a dropdown menu should be able to coexist.

<button type="button" popovertarget="t1" popovertargetaction="toggle">Hover me</button>
<div id="t1" popover="manual" role="tooltip">Add to library</div>

[role="tooltip"] {
  inset: unset;
}

const button = document.querySelector("[popovertarget]");
const tooltip = document.querySelector("[popover]");

positionPopover(tooltip, button, { placement: "top", gap: 4 });

button.addEventListener("mouseenter", () => tooltip.showPopover());
button.addEventListener("mouseleave", () => tooltip.hidePopover());
button.addEventListener("focus", () => tooltip.showPopover());
button.addEventListener("blur", () => tooltip.hidePopover());

Since manual mode disables all built-in triggers, we call showPopover() and hidePopover() from four event listeners: mouseenter/mouseleave for hover, and focus/blur for keyboard accessibility. The popovertargetaction="toggle" on the button is a fallback that lets the tooltip also work via click if the JavaScript has not loaded yet. The role="tooltip" ensures screen readers announce the content as a tooltip description rather than a generic region.

3. Hover Card

Hover cards are richer than tooltips — they contain structured content like profile information or previews, and the user should be able to move their mouse into the card to interact with it. Unlike the tooltip, a hover card uses popover="auto" because it benefits from light-dismiss: if the user clicks somewhere else, the card should close.

<a href="#" popovertarget="my-hovercard" popovertargetaction="show">@dustinboston</a>
<div id="my-hovercard" popover="auto">
  <h4>Dustin</h4>
  <p>Software engineer. Joined March 2002.</p>
</div>

[popover] {
  inset: unset;
  position: fixed;
}

let hideTimeout;
const show = () => { clearTimeout(hideTimeout); card.showPopover(); };
const hide = () => { hideTimeout = setTimeout(() => card.hidePopover(), 100); };

button.addEventListener("mouseenter", show);
button.addEventListener("mouseleave", hide);
card.addEventListener("mouseenter", show);
card.addEventListener("mouseleave", hide);

positionPopover(card, button, { placement: "top" });

The popovertargetaction="show" on the anchor is a subtle detail — it means if a user clicks the link, the card is shown rather than toggled closed. The real runtime drivers are the mouse event listeners, but there is an important difference from the tooltip: a delayed hide. When the cursor leaves the trigger, a 100ms timeout starts before hidePopover() fires. If the cursor enters the card within that window, the timeout is cancelled. This lets the user cross the gap between the trigger and the card without the card flickering away. Both the trigger and the card share the same show/hide functions, so hovering either element keeps it open. This is the hybrid sweet spot: the element still gets top-layer promotion and auto-mode light-dismiss from the platform, while JavaScript only handles the hover timing.

4. Context Menu

A right-click context menu is the furthest from the declarative ideal. There is no trigger button to wire popovertarget to — the menu appears wherever the cursor happens to be when the user right-clicks. This calls for popover="manual".

<div id="context-menu">
  <div id="trigger">Right click here</div>
  <div id="menu" role="menu" popover="manual">
    <button role="menuitem" type="button">Back</button>
    <button role="menuitem" type="button">Forward</button>
    <button role="menuitem" type="button">Reload</button>
    <hr data-separator />
    <button role="menuitem" type="button">Save As...</button>
    <button role="menuitem" type="button">Print...</button>
  </div>
</div>

[popover] {
  inset: unset;
  position: fixed;
}

const trigger = document.querySelector("#trigger");
const menu = document.querySelector("#menu");

trigger.addEventListener("contextmenu", (e) => {
  e.preventDefault();
  menu.style.left = e.clientX + "px";
  menu.style.top = e.clientY + "px";
  menu.showPopover();
});

document.addEventListener("click", (e) => {
  if (!menu.contains(e.target)) menu.hidePopover();
});

Manual mode disables every automatic behavior: no light-dismiss, no Escape-to-close, no exclusive stacking. The contextmenu event provides the cursor coordinates, which are set as inline style.left and style.top before calling showPopover(). Dismissal is handled by a document-level click listener that checks whether the click landed outside the menu. The component is responsible for the entire lifecycle — but it still benefits from top-layer rendering, which means it paints above dialogs and other popovers without z-index hacks or stacking context headaches.

The Spectrum

These four components sit on a clear spectrum:

1. Popover - fully auto, no JS required

2. Tooltip - manual, minimal JS required

3. Hover Card - auto, moderate JS required

4. Context Menu - manual, full JS required

The lesson is straightforward: start with popover and popovertarget. Add popovertargetaction if you need directional control. Reach for showPopover() and hidePopover() only when the trigger is not a click. Switch to manual only when you need to own the entire lifecycle. At every step, the platform is doing the heavy lifting — you are just choosing how much of it to use.

This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.

It's interesting because Kling goes out of the way to explain his AI usage. I think a lot of people feel this way - having to make sure that folks know you're not using AI for slop. Those who wage the great war against slop tend to have an air of superiority that makes you feel shame for using AI. This defensive posture - the need to justify the use of a tool - stems from a cultural narrative that frames AI as a shortcut for the lazy rather than a lever for the ambitious. But the shame surrounding AI is misplaced, rooted in a misunderstanding of how technology evolves and how human knowledge is meant to be shared.

Here are five reasons why using AI is nothing to be ashamed of:

1. The internet was founded on the principle of freely accessible information. The outrage over AI training models often relies on a rigid interpretation of copyright that runs counter to this original ethos. If the web was designed to democratize access to human knowledge, AI is simply the next iteration of that democratization. It is an engine that synthesizes the collective public output of humanity. Using it is not participating in theft; it is engaging with the ultimate distillation of our shared digital history.

2. Critics frequently cite the energy consumption of data centers as a reason to boycott AI. Yet, society readily accepts the massive ecological footprints of other ambitious human endeavors—like launching rockets into orbit or powering global financial systems—because they are implicitly understood as investments in the "greater good." AI demands significant resources, but it also offers unprecedented potential to solve macro-level problems, optimize logistics, and accelerate scientific discovery. The energy cost is an investment in a cognitive infrastructure that benefits humanity at scale.

3. The fear of "slop" assumes that AI operates autonomously to flood the world with mediocrity. As Kling’s experience demonstrates, high-quality output requires high-level human orchestration. AI does not replace the human mind; it acts as a compiler for human intent. True software craftsmanship is no longer just about manually typing every character of syntax; it is about architecture, logic, and directing agents to execute a vision. The shame belongs to those who output thoughtless work, regardless of whether they used a keyboard or a prompt to generate it.

4. There is a persistent, romanticized notion that "harder" means "better." When high-level programming languages first appeared, developers writing in Assembly viewed them with similar skepticism. Refusing to use AI out of a sense of purity is a false economy. Efficiency is not a sin, and leveraging the most powerful tools available to execute an idea faster and with fewer errors is the hallmark of a skilled professional, not a hack.

5. AI acts as a force multiplier, dramatically lowering the barrier to entry for complex problem-solving. It allows an individual to act as an entire team, bridging the gap between a conceptual idea and a deployed reality. Making individuals feel ashamed for utilizing a tool that elevates their capabilities only serves to protect established monopolies and gatekeepers. Embracing AI is embracing a more level playing field where execution is limited only by imagination, not headcount.

Core Perf Pitfalls

• Using top-level await in a page component prevents the server from streaming the initial UI shell. This leaves users staring at a blank screen until the slowest data fetch completes.

• Passing entire database objects across the server-client boundary bloats the HTML and increases hydration time. Use only the fields the client actually needs.

• Placing the use client directive too high in the component tree forces static elements to be included in the JavaScript bundle and hydrated unnecessarily.

• Failing to use Suspense for non-essential, slow-loading data prevents the browser from showing "fast" content (like headers or sidebars) immediately.

• Forgetting to use revalidatePath or revalidateTag in Server Actions can lead to stale UI where the database updates but the view remains unchanged until a manual refresh.

• Using async logic directly in a root layout blocks the entire application's rendering. Data-heavy elements should be moved to isolated components wrapped in Suspense.

The article emphasizes that RSC performance is often about perceived speed and visible progress. By isolating slow work behind Suspense boundaries and keeping the client-side bundle lean, developers can ensure the shell of an application renders instantly, even if back-end processes are slow.

Butler explains that when AI can generate functional code and interfaces instantly, the "economic imperative" for standardization disappears. We are moving toward an era of bespoke technology, where software is no longer a static product but access to a "mind" that generates unique, personal solutions. In this context, consistency is viewed as a sign of "civilizational infancy"—a limitation we will eventually outgrow.

This shift presents some big challenges:

• If every interface is unique, sharing knowledge or teaching others becomes difficult.

• Centralized ownership of AI "minds" creates significant power imbalances.

• Transitioning from "wrestling with constraints" to mere prompting may atrophy human imagination.

Ultimately, Butler suggests that while a world of infinite, inconsistent variation may look like chaos today, it represents a future where technology is finally as distinct as the individuals using it.

Delivering new code has dropped in price to almost free... but delivering good code remains significantly more expensive than that.

Why is good code expensive? It's tested, documented, accessible, reliable, secure, maintainable, and observable.

Coding agent tools can help with most of this, but there is still a substantial burden on the developer driving those tools to ensure that the produced code is good code

The reality is that AI makes the mechanical work of software construction light work, but not the craft of software engineering. Engineers are still responsible for architecture, pattern adoption and reliability, domain modeling, security, scalability, reliability, systems integration, and the alignment of technical decisions with business outcomes."

The good news according to Steiner is that the need for more software will only increase the need for more engineers to manage it. This is "Jevons' paradox: increasing efficiency expands demand." In other words, AI multiplies the amount of software and therefore the amount of software engineering.

The point is that "writing code is only one step of the software development lifecycle (SDLC)," which typically includes seven phases: planning, analysis, design, implementation, testing, deployment, and maintenance. Steiner points out that, every phase of the software development lifecycle benefits from AI: "Early-stage requirements can be transformed into structured specifications; Architectural diagrams can be drafted or critiqued; Test suites can be auto‑generated; CI/CD workflows can be orchestrated; Logs and incidents can be summarized and diagnosed; Legacy code can be refactored into modern patterns"

One approach that I've been experimenting with lately is spec-driven development, "where a structured specification becomes the system’s single source of truth." It has added a level of control that I didn't have when purely vibe-coding. No doubt, AI can still be unwieldy.

For many, the fun part of software development has always been writing the code. AI takes that part and makes it more efficient. That's pretty unfortunate for the engineers who love writing code, but the good news is that there is still plenty to do.

Via The New Stack

• "The simplest refutation of the “death of software” argument is this: AI is still software. And application-layer AI delivered in the cloud is still Software-as-a-Service."

• "If AI makes code cheaper, it makes the non-code moats — domain expertise, distribution, customer relationships, and what Evans memorably called “a throat to choke” — relatively more important, not less."

• "One persistent fantasy is that enterprises will simply vibe-code their way out of buying software. Evans called this idea 'delusional' in his interview, and we completely agree, especially in vertical markets."

There’s a detail about how people used to have only two pairs of clothes, one for work and one for church. After the Industrial Revolution, textiles were more available at cheaper prices. Now we have textiles for every occasion. In the same way, the second Industrial Revolution will drive the proliferation of software by increasing availability and reducing cost.

I can’t even imagine what that will look like. Does everyone just go around making software for things? If you need a calculator, you just build the software instead of opening an app. When you close it, the code is unloaded from RAM and deleted off the old aluminum alloy platters. Maybe the software never exists on a drive at all, and instead runs completely in RAM? Ephemeral software. Impermanence. Far out, man.

I still don’t know what the future will look like for my career, but the outlook does seem slightly more hopeful. 

"It was always a helpful coding assistant, but in November it suddenly got much better, and ever since I’ve been knocking off side projects that had sat in folders for a decade or longer. It’s fun to see old ideas come to life, so I keep a steady flow. Maybe it adds up to a half-hour a day of my time, and an hour of Claude’s."

I know what I'm doing after I finish this post. Time to revive some old projects!

1. Mapping and context

Mapping involves understanding the system’s architecture and data flow before reading business logic. In large-scale applications, reading code without a high-level map often leads to cognitive overload.

Documentation

The first step is identifying the "why" behind the implementation. Documentation provides the historical context of technical choices. Architectural documents detail why specific frameworks or patterns - such as a local-first architecture or a specific state management library - were selected over alternatives. Understanding these business constraints prevents the logic from appearing arbitrary.

Entry points

Every software module has a defined entry point or "front door." Identifying these allows a developer to narrow their focus to the most critical paths.

• Identify web API route handlers and middleware chains.
• Find the public API or the primary export file for libraries
• Map props and useEffect statements that fire when a component is mounted in the frontend.

Data flow

A core requirement of mapping is diagramming how data moves through the system. This includes identifying where data enters (ingestion), where it is transformed (business logic), and where it is stored (persistence). This involves tracing a request from the router to the controller, through the service layer, and finally to the database driver.

2. Tracing and analysis

Once the boundaries are defined, the developer needs to see the code working. Static analysis is insufficient for understanding complex state changes and asynchronous operations.

Step debugging

The next step involves using a debugger to step through execution. Rather than simulating logic mentally, developers set breakpoints at high-level user actions, such as an API request or a UI event. By observing the call stack and variable state in real-time, the developer gains a factual understanding of how data mutates across different functions.

Test suites

Automated tests are the most accurate documentation of a system’s current state. They define the "contract" of a module.

1. Run existing unit and integration tests to ensure a stable environment.
2. Intentionally modify a conditional statement or return value within the source code.
3. Watch for which tests fail. The resulting failures show the dependencies and the blast radius of changes within that module.

Version control

Codebases are rarely static designs; they are historical records of bug fixes and shifting requirements. Using GitHub or tools like GitLens, look at the original Pull Request (PR) associated with a line of code. PR comments often contain the reasoning behind non-obvious workarounds or edge-case handling that the code itself does not explicitly state.

3. Modification and validation

The final step is validating the mental model through direct, non-destructive interaction with the code.

Commenting

As a developer reads through complex files, they should add "scratchpad" comments to summarize the perceived function of specific blocks. For example: // Filters expired tokens prior to authentication check. If a block of logic cannot be summarized in a single sentence, the developer has identified a gap in their mental model. These comments are for personal clarification and are not intended for the final commit.

Refactoring

Attempting a local-only refactor is a high-signal method for testing assumptions. This involves renaming variables for clarity or extracting long functions into smaller helpers. Because these changes are kept in a local branch and not merged, the developer can experiment without risk. If the refactor breaks the system in an unexpected way, it indicates that the developer's understanding was incomplete.

Contribution

A developer’s "beginner’s mind" is a temporary asset that allows them to see gaps in new areas that established team members may overlook. The final step in gaining proficiency is contributing back to the project.

• Correcting an outdated README or updating instructions.
• Adding tests for edge cases discovered during the tracing phase.
• Writing JSDoc comments for functions that lacked clarity.

Synthesizing new knowledge into a documentation PR forces a final verification of the mental model while providing immediate value to the engineering team.

Algorithms. Distributed systems. Hardware architectures. Cache management techniques. Networking fundamentals. Database internals. These aren't academic exercises anymore. They're the foundation for evaluating AI-generated code.

When an AI produces a sorting algorithm, can you tell if it's appropriate for your data properties? When it suggests a caching layer, do you understand the trade-offs in consistency? When it generates a distributed system design, can you spot the failure modes?

There are endless layers to study here. Computer science fundamentals that seemed theoretical suddenly matter for practical work. The student who deeply understands how things work will outperform the one who only knows how to use them.

You know, the hard parts of software development.

I completely agree with his prediction that there will be a boom in small business applications that can be built using AI:

Remember when every business needed a website, and local web developers built them? We're about to see the same thing, but for custom software applications...

This is going to be a booming industry. And it favors people who can talk to clients, understand their real problems, and deliver working solutions. It favors generalists who can move quickly over specialists in narrow technologies. It favors judgment over raw coding speed

Writing code is the easy part of the job. It always has been. The hard part is investigation, understanding context, validating assumptions, and knowing why a particular approach is the right one for this situation.

The hardest part of software development, however, is and always has been, people. Politics, opinions, emotions. You can't find an AI for that, although it can help.

In response to the notion that you can't use AI in complex codebases, Hampton says "If agents aren’t working well in your codebase, you need to figure out why that is instead of throwing your hands up." That's the kind of leadership advice Satya Nadella would be proud of.

Congratulations …. your days of whining are over​. In this room, we deliver success, we don’t whine.​ Look, I’m not confused, I know you walk through fields of shit every day. Your job is to find the rose petals. Don’t come whining that you don’t have the resources you need.​ We’ve done our homework. We’ve evaluated the portfolio, considered the opportunities and allocated our available resources to those opportunities. That is what you have to work with. Your job is to manufacture success with the resources you’ve been allocated

This philosophy was what once made working at Netflix so great. The feeling of being empowered was incredible, but the drive to behave like a member of the Dream Team is what had the biggest impact on me. If you want a master class in leadership, read No Rules Rules, by Reid Hastings.

• Swizec Teller says it's Site Reliability Engineering (SRE)
• Addy Osmani thinks it will be "Agentic Engineering"
• Rafa Páez makes a case for Product Engineering

So, which is it? I say it's an everything bagel:

Jobu Tupaki:  I got bored one day - and I put everything on a bagel. Everything. All my hopes and dreams, my old report cards, every breed of dog, every last personal ad on craigslist. Sesame. Poppy seed. Salt. And it collapsed in on itself. 'Cause, you see, when you really put everything on a bagel, it becomes this.

Here's a quick compare and contrast.

What Each Role Optimizes For

• Agentic Engineering optimizes for throughput with correctness. The goal is to produce high‑quality software quickly by orchestrating AI agents, not by typing faster.
• SRE optimizes for reliability over time. The mission is to keep systems predictable under load, failure, and change.
• Product Engineering optimizes for user and business value. The focus is on shipping features that matter and iterating toward impact.

How they work day to day

Agentic Engineers

They treat AI like a fast but unreliable junior developer. Their craft is decomposition, prompting, reviewing, and testing. They build scaffolds, guardrails, and workflows that turn raw model output into maintainable software.

SREs

They live in the world of SLIs, SLOs, error budgets, and incident response. Their work is automation-heavy and relentlessly focused on reducing toil, improving observability, and ensuring systems behave as expected.

Product Engineers

They sit closest to users. They translate product requirements into working features, iterate quickly, and balance speed with long‑term maintainability. They’re the connective tissue between design, backend, and business goals.

How each role uses AI

AI is reshaping all three roles, but in different ways:

• Agentic Engineers build around AI. It’s the core tool, not an add‑on.
• SREs use AI as an accelerator—log summarization, anomaly detection, config generation—but remain deeply skeptical. Reliability requires verification, not vibes.
• Product Engineers use AI to multiply iteration speed: scaffolding features, generating UI variants, writing tests, and exploring alternatives faster than ever.

The common thread: AI shifts the work upward, toward orchestration and decision‑making.

Skills that define each discipline

• Agentic Engineering: system design, decomposition, prompt engineering, test‑driven development, code review, architectural thinking.
• SRE: distributed systems, observability, automation, incident response, performance engineering.
• Product Engineering: UX intuition, full‑stack development, rapid prototyping, experimentation, cross‑functional communication.

These skill sets overlap, but each role has a distinct emphasis.

The downsides of each discipline

• Agentic Engineering risks over‑trusting AI output, weak test coverage, and architectural drift from agent‑generated code.
• SRE risks over‑engineering reliability, becoming a ticket‑ops team, or burning out under incident load.
• Product Engineering risks shipping fast but accruing tech debt, or building features that don’t move metrics.

Understanding these failure modes is part of understanding the craft.

Where the roles converge

AI is pushing all three disciplines toward a shared future:

• Less manual coding, more orchestration
• Less toil, more automation
• Less focus on implementation, more on system‑level thinking
• Less “just ship it,” more continuous verification

But their centers of gravity remain distinct:

• Agentic Engineering asks: How do we build software with AI?
• SRE asks: How do we keep software reliable as it changes?
• Product Engineering asks: How do we build the right software for users?

Together, they form a triangle of modern engineering practice.

The everything bagel

If AI continues absorbing more of the implementation work, the future engineer - regardless of title - starts to look like an everything bagel:

• the orchestration mindset of an Agentic Engineer
• the reliability instincts of an SRE
• the user‑centric judgment of a Product Engineer
• Sesame. Poppy seed. Salt.

In other words:

The future of engineering is a system designer, reliability steward, and product thinker who directs AI to do the work.

Classic software engineer answer.

1. Knowledge dense. They embody decades of knowledge and would be too expensive for an AI to build from scratch.
2. Efficient. They run more efficiently on CPUs than on GPU inference.
3. Broadly useful. They are general-purpose tools with wide applicability.
4. Familiar. Agents have to know your tool exists in terms (via popularity, documentation, etc.) or at least how to find it.
5. Low Friction. Interestingly, their hallucinations should work, docs reinforce intuitive behavior.
6. Appeal to humans. Whether it is human curated, human created, or human experiences.

There's a fun story about Beads, which has evolved over 100 sub-commands, intended for use by AI.