use role content_dbt_prod;
use schema content.content_prod;
alter table content.content_prod.place rename to place_hco;
create view content.content_prod.place as select * from content.content_prod.place_spark;
Content Squad announcement:
Old content.content_prod.place table (HCO-based) has been renamed and considered private
In this week's newsletter, Anthropic included this:
"My daily driver currently looks like: two lead agents that keep each
other accountable and restart the other if either fails. These
delegate to tech lead or PM agents for the 8-10 projects I'm running
at any one time, and each project has 5-10 IC [individual contributor]
agents, generalists or specialists depending on the problem. Across
all of these I'm still only doing 30-50 prompts per day, and my IC
agents typically work autonomously for 2-3 days. About 60% of my
interaction is with the leads, 35% with a project lead, and 5% is when
something has gone off the rails. All of these agents communicate
directly with the SendMessage tool."
╭─ keep each other accountable
╭─ two lead agents ┼─ restart the other if either fails
│ ╰─ delegate to ┬─ tech lead ── 8-10 projects...
│ ╰─ PM agents
│ ╭─ . ┬─ generalists
« Daisy workflow » ┼─ 8-10 projects ── per project ── 5-10 IC agents ┤ ╰─ specialists
│ ╰─ work autonomously ── for 2-3 days
│ ╭─ 60% with leads
├─ 30-50 prompts per day ┼─ 35% with project lead
│ ╰─ 5% off rails
╰─ agents communicate ── SendMessage tool
My thoughts:
Why two lead agents? Likely they both run "/loop 30m check projects"
with offset, so one is checking status while another is ready for
communication. This is where "60% with leads" coming from; sometimes
they both are checking, and Daisy goes to project leads directly. Those two
leads have permanent session names and never closing.
8-10 projects. I also have about the same number of big topics a
week, often carried to other weeks. So this sounds like the right
amount of parallelism. Also keeping 8-10 projects on track is within
cognitive abilities of an average human.
╭─ Slack
╭─ where work comes from ┼─ CI/CD ── no point to fix CI/CD manually
│ ├─ Dashboards
│ ╰─ Internal Docs
├─ tip ── try doing ALL work from within CC
│ ╭─ code conventions are not in the model
├─ limits ┼─ fine-tuning doesn't work well ── leads to more hallucinations
│ ╰─ in-context learning ── ICL ── general AI wins over specific AIs
│ ╭─ rigid templates
│ ╭─ compensates lack of intelligence ┼─ guardrails
│ │ ├─ "don't let it touch X"
├─ two kinds of tools ┤ ╰─ gets less useful as model improves
│ │ ╭─ more access
│ ╰─ scales with intelligence ┼─ more control
│ ├─ faster feedback loops
│ ╰─ gets more useful as model improves
│ ╭─ context window stayed at 1M max ── models are way better yoy
│ ├─ can't dump the whole X into context ── X ┬─ wiki
├─ context window is a box ┤ ╰─ codebase
│ ├─ example ── try to run npm on Arduino
│ ╰─ don't pay for what you don't use ── [TK: no slop skills]
│ ╭─ cached tokens are cheap ── new are expensive
│ ├─ not an LRU problem
├─ KV cache ┼─ change in early instructions invalidates the cache ┬─ add new tool
│ │ ╰─ change in CLAUDE.md
│ ╰─ put stable stuff at the front ── volatile at the end ── CC teams tries to solve this problem
├─ Large-scale Software Engineering ── main question ── Does it scale?
│ ╭─ when it's the right tool?
│ ├─ CC has a shell ── Skill+CLI has less overhead
│ │ ╭─ name
│ ╭─ MCP ┼─ tools definitions sit in front ┼─ arguments
│ │ │ ╰─ description
« Agentic flow » ┤ │ │ ╭─ puts just name in the system prompt
│ │ ╰─ tool search ┼─ kind-of lazy-loaded
│ │ ╰─ needs to be very specific ── e.g. slack
│ │ ╭─ in-context
│ │ ├─ one-line description always loaded
│ │ ├─ full SKILL.md and assets loaded on-demand
├─ Plugin primitives ┼─ Skills ┤ ╭─ body is pay-per-use ── good
│ │ ╰─ does it scale? ┼─ reliably loading requires a paragraph in description
│ │ ╰─ not possible to lazy-load sub-skills ┬─ no hierarchy yet
│ │ ╰─ what if 100k skills?
│ ├─ Hooks ┬─ runs code on events ── shell scripts
│ │ ╰─ zero-overhead abstraction
│ │ ╭─ out-of-context ── fundamental difference to a skill
│ │ │ ╭─ named role
│ │ ├─ more Claudes ┼─ own system prompt
│ ╰─ Agents ┤ ╰─ own tool set
│ ├─ spawned with a task ┬─ returns result
│ │ ╰─ its transcript doesn't come back
│ ╰─ description still in-context ── what if 100k agents?
│ ╭─ loads fully unconditionally ┬─ doesn't scale
│ ╭─ CLAUDE.md ┤ ╰─ every plugin adds it
├─ Doesn't scale ┤ ╰─ better inject via SessionStart hook
│ │ ╭─ low-quality ── low-cost ── useful, different contract
│ ╰─ Memory ┼─ model-curated, not human-curated
│ ╰─ plugins are human-authored, human-reviewed
│ ╭─ worktrees ┬─ one repo ── N claudes each owns its branch
│ │ ╰─ better make it long-lived ── less overhead ── [TK: try kunchenguid/treehouse?]
├─ Multi-clauding ┼─ asynchrony ┬─ walk away, let it do the work
│ │ ╰─ /loop 10m
│ ├─ parallelism ── multiple of asynchrony
│ ╰─ lot's of context switching
╰─ Agent-teams ┬─ teammates ── long-lived ── unlike agents
╰─ SendMessage tool ── Claude's talking to each other
Let's see if I'm going to use it, if yes – will think about publishing
a release. If you want to build it – clone the repo and ask Claude
Code to build it.
☑ Internal Org Roam links are pasted as markdown files. So in theory,
I could somehow expose them.
I ended up forking it to https://github.com/velppa/textpod and greatly
improving it for my needs. You're reading notes served by Textpod
v0.2.0. It is my project.
Notable changes:
Read-only mode with token authentication: The app now supports an
optional --token flag that enables authentication. When a token is
set, users without the token see a read-only interface where they
can only search notes. Access is granted via a ?token=X query
parameter (which sets a cookie) or a Bearer token in the
Authorization header. The UI dynamically adjusts based on
authentication status, hiding edit/delete controls and changing the
editor placeholder for unauthenticated users.
Enhanced note management: Notes now have unique IDs based on
timestamps, enabling direct access via /note/:id URLs. PUT method
allows editing notes (upserting if not found).
Subpath support: to deploy on your domain under subpath, supply
--base-path notes flag. Then notes will be under /notes subpath.
The app watches the notes file for external changes and
automatically reloads.
The link archiving feature lets users prefix URLs with + to both raw
urls and Markdown-formatted.
Special handling of links to .md files: They appear when exporting
from Org-roam. These are internal links and Textpod now turns them
into search by filename, effectively returning all mentions of this
concept. Poor man zettelkasten import.
UI improvement: larger fonts, footer, better code snippets for
dark mode, tags on the heading.
textpod.el: Companion Emacs package for quick sending notes to
Textpod.
Later changes to setup will go into separate notes.
Vincent Van Gogh gallery
I found on my external drive a collection of Vincent Van Gogh
paintings, that I converted into desktop wallpapers using
Backgroundifier app (archagon/backgroundifier-public) several years
ago.
The collection is pretty big, 1380 paintings. To explore it in a
better way than just going through files on a disk, I built an
interactive gallery (a small project using Claude Code). It serves
images directly from my external drive; also had to prepare thumbnails
for faster loading.
