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

Aside from coding itself, software engineering involves:

• Project scoping: Defining what the software will do, and the processes it will follow in order to get it done, including setting safety guardrails.

• Architecture: Defining the different elements that come together to create the tool, and how they all fit together.

• User interface and user experience design: Designing the interface that users will interact with the software through, and ensuring that using it is as streamlined and friction-free as possible.

• Data engineering: Structuring and managing the flow of data through the tool.

• Testing: Ensuring that errors and unexpected user behavior are handled correctly.

• Version control and documentation: Tracking changes and updates to the code as it’s developed.

While AI can generate code quickly, understanding these other aspects of software engineering is essential if we want to turn that code into tools that are coherent, usable and trustworthy.

Source: Why Vibe Coders Still Need To Think Like Software Engineers

They're going to make a few hundred thousand dollars a year, their base pay," said Huang of engineers. "I'm going to give them probably half of that on top of it as tokens so that they could be amplified 10X. Of course, we would."

"It is now one of the recruiting tools in Silicon Valley: How many tokens comes along with my job?" Huang added. "And the reason for that is very clear, because every engineer that has access to tokens will be more productive.

But it's not like we actually want tokens. We want money. Tokens are incidental. What I DO care about is not having enough tokens to meet demand. And employers are demanding ALL THE TOKENS. Regardless of my salary, if an employer expects me to use AI but can't afford to give me the tokens to use it effectively, is that a place that I would want to work? The way I see it, tokens are not an incentive, they are fundamental to modern work. You have a computer, an internet connection, and a shit load of tokens to burn.

Writing code is pattern recognition. Take what’s been done before, apply it to a new context, and scaffold it out. Large language models are exceptional at this because that’s exactly what they do: recognize and reproduce patterns from massive corpora of prior work.

Software engineering is something else. It’s trade-offs. Constraints. Decisions that require context no model has access to: your business domain, your product strategy, your customers, your technical debt, the conversation your team had last week about why you chose one approach over another.

Working with an LLM in a professional manner involves creating a requirements document, generating or manually updating code, creating and enforcing style guides (via linters), testing and code coverage (plus automation), build and deployment (CI/CD), security, project maintenance, SLAs, guarantees about project timing and delivery, negotiating features, managing complexity, creating documentation, and most importantly the years of experience to know when to do what.

Division of Labor

Here's a good rule of thumb for dividing the work between an engineer and an LLM:

Developers own the work where the output is a decision, not an artifact: what to build, what to cut, and which technical bets to place six months from now. Agents can generate options. They cannot tell you which option is right for your situation because “right” depends on factors that reside in human heads and organizational contexts, not in training data.

And for LLMs:

There is a mountain of work in every codebase that is a waste of human brainpower. Boilerplate, scaffolding, repetitive refactors, unit test generation, configuration templating, and data formatting. This work is rote, mechanical, and can be reasoned entirely from prior patterns. Agents should own it.

In other words, LLMs are a tool that engineers can use to make development faster, but for software that you can depend on you still need an Engineer in the Loop.

The written word earned its authority because it preserved ideas. But also because it seemed to carry the trace of a person behind them. That authority is now being weakened by AI that can generate language without the lived experience or the cognitive burden that once stood behind the words.

That may be why so much of today's posts and prose feel strangely vacant. Language has become easier to separate from the human mind that once gave it both substance and meaning.

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.