georgecalm

I really appreciate that someone's job (or at least part of it) was to "prototype concepts that would add some interactive sparkle to the site". Working on a larger team, we generally add this kind of interaction at the start of a project or during redesign. There are larger prototypes, of course. But very rarely is someone designated to independently go out and just find small ways of making the experience just a bit nicer for the users, and build that; and I really like that idea.

Is there any evidence for the codebase having no tests? I wouldn’t expect those to come through in the source map.

Intersected available info on the web with the source for this list of new features:

UNRELEASED PRODUCTS & MODES

1. KAIROS -- Persistent autonomous assistant mode driven by periodic <tick> prompts. More autonomous when terminal unfocused. Exclusive tools: SendUserFileTool, PushNotificationTool, SubscribePRTool. 7 sub-feature flags.

2. BUDDY -- Tamagotchi-style virtual companion pet. 18 species, 5 rarity tiers, Mulberry32 PRNG, shiny variants, stat system (DEBUGGING/PATIENCE/CHAOS/WISDOM/SNARK). April 1-7 2026 teaser window.

3. ULTRAPLAN -- Offloads planning to a remote 30-minute Opus 4.6 session. Smart keyword detection, 3-second polling, teleport sentinel for returning results locally.

4. Dream System -- Background memory consolidation (Orient -> Gather -> Consolidate -> Prune). Triple trigger gate: 24h + 5 sessions + advisory lock. Gated by tengu_onyx_plover.

INTERNAL-ONLY TOOLS & SYSTEMS

5. TungstenTool -- Ant-only tmux virtual terminal giving Claude direct keystroke/screen-capture control. Singleton, blocked from async agents.

6. Magic Docs -- Ant-only auto-documentation. Files starting with "# MAGIC DOC:" are tracked and updated by a Sonnet sub-agent after each conversation turn.

7. Undercover Mode -- Prevents Anthropic employees from leaking internal info (codenames, model versions) into public repo commits. No force-OFF; dead-code-eliminated from external builds.

ANTI-COMPETITIVE & SECURITY DEFENSES

8. Anti-Distillation -- Injects anti_distillation: ['fake_tools'] into every 1P API request to poison model training from scraped traffic. Gated by tengu_anti_distill_fake_tool_injection.

UNRELEASED MODELS & CODENAMES

9. opus-4-7, sonnet-4-8 -- Confirmed as planned future versions (referenced in undercover mode instructions).

10. "Capybara" / "capy v8" -- Internal codename for the model behind Opus 4.6. Hex-encoded in the BUDDY system to avoid build canary detection.

11. "Fennec" -- Predecessor model alias. Migration: fennec-latest -> opus, fennec-fast-latest -> opus[1m] + fast mode.

UNDOCUMENTED BETA API HEADERS

12. afk-mode-2026-01-31 -- Sticky-latched when auto mode activates 15. fast-mode-2026-02-01 -- Opus 4.6 fast output 16. task-budgets-2026-03-13 -- Per-task token budgets 17. redact-thinking-2026-02-12 -- Thinking block redaction 18. token-efficient-tools-2026-03-28 -- JSON tool format (~4.5% token saving) 19. advisor-tool-2026-03-01 -- Advisor tool 20. cli-internal-2026-02-09 -- Ant-only internal features

200+ SERVER-SIDE FEATURE GATES

21. tengu_penguins_off -- Kill switch for fast mode 22. tengu_scratch -- Coordinator mode / scratchpad 23. tengu_hive_evidence -- Verification agent 24. tengu_surreal_dali -- RemoteTriggerTool 25. tengu_birch_trellis -- Bash permissions classifier 26. tengu_amber_json_tools -- JSON tool format 27. tengu_iron_gate_closed -- Auto-mode fail-closed behavior 28. tengu_amber_flint -- Agent swarms killswitch 29. tengu_onyx_plover -- Dream system 30. tengu_anti_distill_fake_tool_injection -- Anti-distillation 31. tengu_session_memory -- Session memory 32. tengu_passport_quail -- Auto memory extraction 33. tengu_coral_fern -- Memory directory 34. tengu_turtle_carbon -- Adaptive thinking by default 35. tengu_marble_sandcastle -- Native binary required for fast mode

YOLO CLASSIFIER INTERNALS (previously only high-level known)

36. Two-stage system: Stage 1 at max_tokens=64 with "Err on the side of blocking"; Stage 2 at max_tokens=4096 with <thinking> 37. Three classifier modes: both (default), fast, thinking 38. Assistant text stripped from classifier input to prevent prompt injection 39. Denial limits: 3 consecutive or 20 total -> fallback to interactive prompting 40. Older classify_result tool schema variant still in codebase

COORDINATOR MODE & FORK SUBAGENT INTERNALS

41. Exact coordinator prompt: "Every message you send is to the user. Worker results are internal signals -- never thank or acknowledge them." 42. Anti-pattern enforcement: "Based on your findings, fix the auth bug" explicitly called out as wrong 43. Fork subagent cache sharing: Byte-identical API prefixes via placeholder "Fork started -- processing in background" tool results 44. <fork-boilerplate> tag prevents recursive forking 45. 10 non-negotiable rules for fork children including "commit before reporting"

DUAL MEMORY ARCHITECTURE

46. Session Memory -- Structured scratchpad for surviving compaction. 12K token cap, fixed sections, fires every 5K tokens + 3 tool calls. 47. Auto Memory -- Durable cross-session facts. Individual topic files with YAML frontmatter. 5-turn hard cap. Skips if main agent already wrote to memory. 48. Prompt cache scope "global" -- Cross-org caching for the static system prompt prefix

> This is the most expensive failure mode with AI-assisted coding, and it’s not wrong syntax or bad logic. It’s implementations that work in isolation but break the surrounding system.

This is spot on. Zooming out, a perfectly written implementation that follows all the conventions but misses the mark on its business goal is as, if not more, expensive. I think adding a brief.md artifact to the beginning of the flow (where you store the problem, desired change, primary metric, feature-kill criteria) can go a long way.

There's a great video from "Technology Connections" covering one-pedal driving here [1]. The gist of it is that one-pedal breaking doesn't have a great way to control the break lights, making it difficult for the cars behind you to recognize that you're slowing down, which can cause accidents.

[1] https://youtu.be/U0YW7x9U5TQ?si=7XFO_ZHIwUjd-3Sm&t=195

Thank you for putting the list together! If I may make a suggestion, what you wrote above would be an excellent first paragraph in the readme, as it explains the intent well and the criteria for how you add books to the list.

If you'd like to use something like this in your own APIs to let your clients filter requests or on the CLI (as is the intention with gron), consider giving "json-mask" a try (you'll need Node.js installed):

  $ echo '{"user": {"name": "Sam", "age": 40}}' | npx json-mask "user/age"
  {"user":{"age":40}}

or (from the first gron example; the results are identical)

  $ gron "https://api.github.com/repos/tomnomnom/gron/commits?per_page=1" | fgrep "commit.author" | gron --ungron
  $ curl "https://api.github.com/repos/tomnomnom/gron/commits?per_page=1" | npx json-mask "commit/author"

If you've ever used Google APIs' `fields=` query param you already know how to use json-mask; it's super simple:

  a,b,c - comma-separated list will select multiple fields
  a/b/c - path will select a field from its parent
  a(b,c) - sub-selection will select many fields from a parent
  a/*/c - the star * wildcard will select all items in a field

Yesterday’s thread on the RC release: https://news.ycombinator.com/item?id=23875541

> Where should I start in a migration?

> Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.

Vue's docs are a masterclass in docs-writing, imho. Clear. Concise. Empathetic. Written for humans.

I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.

I’m excited about this. There’s usually a ton unnecessary CPU usage with the current techniques, not to mention the human time waste of re-implementing them in JS. There’s feature detection for this too, so we can gracefully degrade “loading” to existing solutions and take advantage of it right away.

Great news for PWAs buried in the release notes: “Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.”

> What is a Toshi?

> Toshi is a three year old Shiba Inu. He is a very good boy and is the official mascot of this project. Toshi personally reviews all code before it is commited to this repository and is dedicated to only accepting the highest quality contributions from his human. He will though accept treats for easier code reviews.

There are two requirements that I personally don’t feel very comfortable with: the first one is uploading a picture of my ID (How is it stored / backed up. Who has access: third party validator or your team?) and the other is adding logmein to let a proctor control my machine prior to the exam. I saw that one may take the exam in person. I don’t know if it’s allowed by your rules, but I suppose I can set up a VM for this, but either way that just makes it more difficult for me to justify finding the time to do it.

- nuxt (or next if you prefer react) - tailwind (atomic css)

- node - express - passport (Use cookie based auth keeping the session in your storage. I wouldn’t waste time on JWT. There’s a decent amount of complexity if you want both the security of being able to revoke access to a bad actor and the convenience of long lived sessions, and at the end the auth server will most likely need to access storage and use cookies for that anyway (eliminating the benefits of JWT). So I’d start with cookie based auth and build up complexity as needed.)

- postgres - On the Node side, I don’t recommend adding the complexity of an ORM at first (or ever). The node pg driver will give you arrays of objects back for rows. It’s convenient enough not to need the extra overhead of an ORM. - As a side note, Postgres has modules for you to implement a decent first version of a lot of things, such as search for example, before you need to reach for a dedicated solution. This makes it amazing for startups in my opinion, as you can explore ideas very quickly.

- statsd / grafana (to monitor your app and learn from the behavior of your users)

- docker-colpose.yml to make spinning up your dev environment with node / db / stats as simple as “docker-compose up”

- DigitalOcean for hosting - Use their dokku image - Set up daily backups to Spaces since your DB will be hosted here at first too

- dokku for deployment with the Postgres, letsencrypt and grafana modules - deployments are as easy as “git push master dokku”

No surprises here this year: es6 & typescript, react & vue. I think I’d put redux and graphql in different categories as they’re not mutually exclusive. Nevertheless, I’m happy to see excitement for the latter.

Structured design by W.P. Stevens, G.J. Myers, and L.L. Constantine

I follow the check-in model from Adobe [1]. It isn’t a hard set of requirements, but is more of a set of topics that help guide the conversation. It’s especially helpful as a starting point for people new to management, like myself.

A check-in meeting is made up of three parts: (1) setting expectations, (2) providing feedback, (3) having a development conversation.

Status reports are explicitly not a part of this conversation. Those are easy to talk about, but have little value for your employee, and if you’re already doing daily stand-ups, they have little value for you too.

The first two topics are fairly self-explanatory, yet take time to learn to do well. The expectations must be clear, finite and actionable. Much has been written about the art and science of giving good feedback. I use a model where we talk about the Specific thing that happened, followed by Asking questions to understand their perspective, talking about the Impact of their actions on themselves and the people they have affected, and finally talking about what I expect them to Do now or in the future. (aka SAID)

The development conversation is the time for you to listen. This is where you learn about the professional skills they are working on growing (whether it’s public speaking, a particular career path or, say, a machine learning course, to name a few) and finding ways to help and facilitate those. If done right, you learn a lot about the person, their goals, aspirations, and will be in a better position to make a positive meaningful impact on their life.

The check-in is most effective if it’s guided by the employee. This encourages people to come with topics they care about and gives them the ability to focus more time on a particular aspect of the meeting which may be more important at that time.

1. https://www.adobe.com/check-in.html

I think it's a beautiful, thought out, polished and well built set of UI components. If that's what I needed for my next project, I wouldn't hesitate to use it. The docs are excellent too. There's so much attention to detail here. There's an immense amount of love poured into this project, even the code snippets are interactive.

You may like https://techyaks.com — it’s a site with over 80K software development tech talks ranked algorithmically.

The title of this submission is a bit misleading. This script parses the .vue file and extracts the three sections into x-template script, Vue.component script and a style. These are not standalone in the sense that they cannot exist without vue and vue-template on the page (the later is large and unnecessary when compiling with webpack). Essentially this does what the vue webpack plugin does naïvely and without many of the features like support for different template / JS / style language compilation (e.g. Babel and sass).

One thing that caught my attention is Julia’s value of work / life balance and the humanization (if that’s the right word) of programming. She very deliberately didn’t work on this in her spare time (underlining that coding isn’t the only important thing in her life) and when she did build the prototype she explicitly wanted to do it at a weekend coders retreat with other “wonderful” people around (as opposed to secluding oneself in a room and coming out of it with a solution).

Yes, come to think of it, that’s possible either manually or with a PAC file. It seems like a decent compromise too to whitelist the proxied sites the weakened security of which you are willing to tolerate, at least in the case where the alternative is not being able to teach/learn in that area, as in Eric’s case.

It’s possible and is what Charles and MITM proxies do. Specifically, Charles generates its own certificates for sites, which it signs using a Charles Root Certificate. So the clients of this proxy would accept the proxy’s CA and continue as usual. This of course does make browsing less secure, as a compromised proxy negates the security of https of all of the proxied websites. A slightly more secure but less efficient caching solution is to install the proxy locally, but then, of course, the cache isn’t shared.

There was a thread not so long ago about approaching large codebases. I think you might find some of the advice there useful: https://news.ycombinator.com/item?id=16299125

Consider supporting Henry Zhu, the maintainer of Babel. Henry decided to dedicate himself 100% to open-source earlier this year and is one of the main reasons Babel is such an indispensable (albeit invisible) tool. Henry welcomes contributions at https://www.patreon.com/henryzhu/memberships

I’ve been happy with Dokku hosted on DigitalOcean with the Postgres plugin for persistance and the Grafana plugin for stats gathering (optimizing for validated learning). I have a base image of that on DO for new projects. (Also Dokku Postgres takes care of cron-based encrypted backups which it will happily store on DO Spaces; in case anything happens to your server) I use Node on the backend with a simple passport-based session cookie auth and the apollo GraphQL server for APIs. I use nuxt for isomorphic (progressive?) vue components along with the Apollo vue module to communicate with the GQL server.

This strategy takes time, but it works really well:

1. If you can, get an overview from a mentor. This will make the next steps a lot easier. Get: - history - philosophy - design style - high-level flow

2. Get a stack of white paper from the printer and put it in front of you along with a pen. Colored pens and scotch tape are a bonus (There may or may not have been a shortage of both printer paper and colored pens next to them when I started at my last job)

3. Open a debugger with a breakpoint on the first line of code

4. Pick a request flow and initiate a request. Let the debugger guide you through the entire request flow

5. Record the path of the flow as a sequence diagram on your paper

( BONUS ) Record the relationships between the components in the system in a class diagram

Why does this work?

There's software out there for making these diagram, so why draw them by hand? For most people, visual memory is the strongest. So, the idea is you use your strong visual and spacial memory to assist you in recalling random objects, facts. And hey, why not a codebase? And that’s why this works.

When you look at different files that the debugger guides you through, you are engaging your visual memory. You remember how the code is organized and what the files look like.

When you draw the sequence diagram you engage your spatial memory. E.g., the Router class doesn't interact with the Database class and so they are one sheet of paper apart. Visually, you can see what clusters of components work together to make larger structures. This allows you to mentally group the classes into a single concept.

The point is to get this information into your head, and not to produce a diagram on a piece of paper. If all you need is the latter, use software, of course. Seriously, when you're done, throw away the piece of paper; it will be outdated the next day anyway.

I was always curious why Ryan Dahl left the community. He finally answered that question; not the way I thought he would though:

"I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node."

Go may be an excellent choice for massive non-web servers, I don't have enough experience in it to say. For the product I work on, though, Node.js is the way to go. It's the best framework that allows us to use the same exact code on the server and on the client to create a fast progressive site.

The top of the spreadsheet says, "For companies currently hiring, please add your details to the second tab", but I'm seeing the spreadsheet in readme-only mode. Can the creator of this spreadsheet comment on how companies can edit it, please (or whether it's permanently locked now)?