Same AI, two developers: why the experienced one spends fewer tokens
---
title: "Same AI, two developers: why the experienced one spends fewer tokens"
published: true
description: "Everyone can build an app with AI now. Give the same model and the same prompt to a first-time builder and an experienced engineer: day 1 looks identical, day 30 doesn't. Where the tokens go, what makes AI-written code last, and a playbook for working like the second one."
tags: ai, productivity, softwareengineering, career
canonical_url: ayushwing.com
cover_image: ayushwing.com
series: "Staff-level judgment"
---
Everyone is building apps with AI now. My cousin built one. Your manager built one. Somebody built one during a meeting about whether we should build one.
That's genuinely great. But it raises a fair question: if a first-time builder and an engineer with ten years of experience use the same model with the same prompt, what's actually different?
Let's run the experiment in our heads. Two developers, same AI, same request:
> "Build me a task-tracker app with user login."
Meet Nia, the native AI builder: smart, fast, has never shipped software before. And Sam, the seasoned engineer, who has broken production enough times to be careful.
Day 1: no difference at all
Both get a working demo in an afternoon. Login page, task list, a nice dark theme, a little confetti when you finish a task. Both post a screenshot. Both get 40 likes.
If you only look at day 1, experience doesn't matter. This is the part of the story everyone's excited about, and they're right to be. The AI did in an afternoon what used to take a week.
The difference shows up later, the way it always does in software: in the second month, when you change things.
Where the tokens go
Here's Nia's day 3. A user reports that tasks sometimes disappear.
Nia: tasks disappear sometimes, fix it
AI: (rewrites the storage layer)
Nia: now login is broken
AI: (rewrites the auth flow)
Nia: login works but tasks still disappear
AI: (adds a retry, a cache, and a second database "for reliability")
Nia: it's slower now and still broken. FIX IT PROPERLY
AI: (apologises, rewrites the storage layer again)
Every one of those messages drags the whole conversation and a growing chunk of the codebase into context again. Every fix touches more files than the bug lives in. After a week the app works most of the time, nobody knows why, and the token bill looks like a phone number.
Sam's day 3, same bug:
Sam: Read CLAUDE.md. Tasks occasionally disappear after editing.
Don't change code yet: find where tasks are written and list
the ways two writes could race.
AI: Two tabs saving the same task: last write wins, no version check.
Sam: Write a failing test that reproduces it with two concurrent saves.
AI: (test fails, as expected)
Sam: Fix it with a version column and a conditional update. Keep the diff small.
AI: (12-line change, test passes)
Sam: (reads the diff, commits)
Four messages. One small diff. A test that will catch the bug if it ever comes back. Sam spent fewer tokens than Nia, not more. Experience didn't make Sam write better prompts in some magic way. It made Sam ask for smaller, checkable steps.
(If that bug looks familiar, it's the same race I wrote about in Model business workflows as state machines. AI doesn't remove these problems. It just reaches them faster.)
!Two loops. Prompt and pray: ask for a whole feature, run it, see something broken, say fix it, repeat. Plan, test, ship: plan, write a failing test, make one small change, read the diff, commit, then take the next step.
Same model, two loops. Only one of them ends. Explore the interactive diagram
The side-by-side
| | Nia (first-time builder) | Sam (experienced engineer) |
| --- | --- | --- |
| First prompt | "Build the whole app" | "Plan the app; don't write code yet" |
| Size of each request | A feature, or "fix everything" | One change you can review in two minutes |
| Context | Re-explains the project every session | A project instructions file the AI reads every time |
| Definition of done | "It looks like it works" | A test passes, and the diff makes sense |
| When it breaks | "Fix it" (again) | "Explain why before changing anything" |
| Tools | Pastes logs and docs into the chat | Gives the AI tools: skills, plugins, MCP servers |
| Dependencies | Whatever the AI suggested | Asks why each one is needed |
| Secrets | API key in the code, "temporarily" | Environment variables from the start |
| Git | One giant commit called "final" | A commit after every green step |
| Day 30 | Afraid to touch it | Adds features on a Friday |
None of Sam's column is about AI. It's just engineering: small steps, tests, version control, knowing what "done" means. AI is a multiplier, and it multiplies whatever habits you bring.
What makes AI-written code sustainable
"Sustainable" is a fancy word for one question: can someone change this code next month without breaking it? "Someone" includes you, and it includes the AI.
Four things decide the answer:
1. Tests that describe behaviour. A test suite is the only spec the AI can't misread. With tests, "refactor this" is safe. Without them, every change is a gamble the AI makes with confidence.
2. Small, readable diffs. If you can't explain a change in a sentence, you can't review it, and unreviewed code is how plausible-but-wrong bugs ship. My favourite: a refund endpoint that retries on timeout and pays twice. It looks perfectly correct in a diff (here's how to prevent it).
3. Written-down decisions. A project instructions file (CLAUDE.md, AGENTS.md, .cursorrules, whatever your tool reads) that says: how to run the tests, what the architecture is, what not to touch. The AI stops rediscovering your codebase every session, and that's most of the token savings right there.
4. Boring choices. One database, not five. A library everyone knows, not the one the AI half-remembers. AI is very good at writing glue for popular tools and very bad at debugging an obscure one.
Skills, plugins and tools: stop pasting, start equipping
The biggest token sink I see is pasting: the same error log, the same docs page, the same "here's how our project works" paragraph, over and over.
Experienced developers give the AI tools instead:
- Skills and plugins package a repeatable way of doing something, such as a review checklist, a deploy process or an audit, so you don't explain it every time.
- MCP servers let the AI read your tickets, query a staging database or check a deploy itself, instead of you copying the output in. (I built one for Java services for exactly this reason.)
- Your own scripts: a test command, a screenshot script, a linter. The AI can run them and check its own work.
A real example: this site. While building it with an AI assistant:
- Archify drew the diagrams, with its own validation checks, instead of the AI hand-placing boxes.
- An SEO audit skill (claude-seo) ran its checklist against the built site and found a real bug: robots.txt pointed at a sitemap that no longer existed.
- Every visual change was screenshotted in a headless browser before it shipped, which caught a meme overflowing on phones and a diagram that rendered as a broken image.
- And the homepage stack section went through two designs I didn't like. Before the third attempt, I was asked to pick a concept from four sketches. That one stuck.
That last one isn't a tool at all. It's the oldest engineering habit there is: agree on what you're building before you build it. It turns out it works on AI too.
Signs you're vibe coding
Score yourself honestly. One point each:
- [ ] Your most-used prompt is "fix it".
- [ ] You've said "PLEASE" to a compiler in capital letters.
- [ ] Your app has 3 state-management libraries and you know the name of one.
- [ ] There is a file called utils2_final_REAL.ts.
- [ ] Your git history is one commit: "init".
- [ ] You don't know what happens if two users click Save at the same time.
- [ ] The AI added a cache "for performance" and you were too scared to ask why.
- [ ] Your API key is in the frontend, but "only for now".
0–2: you're Sam. 3–5: you're on the way. 6–8: you're Nia, and that's fine. Every Sam started as a Nia. The good news is that every habit in Sam's column can be learned, and the AI will happily help you learn it if you ask it to explain instead of just fix.
The playbook
If you want to work like Sam starting tomorrow, here's the whole thing:
1. Plan before code. Ask for a plan and push back on it before any code exists.
2. Write a project instructions file on day 1: how to run, how to test, the rules.
3. One change per request, small enough to review in two minutes.
4. Test first for anything that matters: write the failing test, then the fix.
5. Read every diff. If you don't understand it, ask "why" before you accept it.
6. Commit after every green step, so you can always go back.
7. Equip, don't paste: skills, plugins, MCP servers and scripts the AI can run.
8. When stuck, ask for a diagnosis, not a fix. "Explain why this fails" costs less than five rewrites.
Takeaways
- On day 1, AI makes everyone equal. By day 30, habits make the difference.
- Experienced developers often spend fewer tokens, because small steps, tests and saved context beat "fix it" loops.
- Sustainable AI-written code has tests, small diffs, written decisions and boring choices.
- Give the AI tools, not copy-paste.
- Experience isn't about typing faster anymore. It's about knowing what to ask for, and knowing when the answer is wrong.
---
Originally published at ayushwing.com.
1 comment
Archify: Turn any idea, plan, or codebase into a beautiful interactive diagram (86k stars)
What it does
All text below is quoted directly from the project README.
>Turn any idea, plan, or codebase into a beautiful interactive diagram. An agent skill for Claude Code, Codex, and more.
Why Archify:
- Layout judgment over generic auto-layout: the agent chooses hierarchy, spacing, routes, and emphasis; shared automatic endpoints spread deterministically instead of piling arrows on one midpoint.
- Typed JSON IR: every renderer-backed mode has a schema and reproducible source.
- Atomic validation before delivery: schema, layout, HTML/SVG, route, and label-to-route clearance checks must all pass before a showcase artifact replaces the last known good output.
- Failures come with a repair receipt: validate --json and deliver --json return stable rule codes, the exact subject, measured evidence, and only supported repair controls instead of a Node stack or an unstructured retry guess.
- Last-good live preview: an optional desktop loop watches one JSON file, refreshes only after the latest candidate passes every gate, and keeps the previous verified diagram visible when a save is incomplete or invalid.
- Truthful interaction: focus, upstream/downstream reach, exact routes, role comparison, and stories reuse authored nodes and relationships instead of inventing topology or claiming runtime impact.
- Source evidence, only when requested: Evidence-backed Architecture nodes mark themselves SRC n and open Git-verified files and line ranges pinned to one public commit; ordinary artifacts stay source-free.
- Portable by default: the result is one HTML file; exports remain full-diagram and free of temporary viewer state.
>npx skills add tt-a1i/archify -g
Repository
tt-a1i/archify
Repository stats
|Metric|Value|
|:-|:-|
|Stars|86,013|
|Forks|5,858|
|Last release|v3.2.0 (2026-10-19)|
|Languages|JavaScript 90.8%, CSS 4.5%, HTML 3.2%|
|Contributors|90|
|AI contributor accounts (Claude / Codex / Cursor / Copilot)|cursoragent: 10, claude: 25|
|AI co-authored commits|Claude: 30, Cursor: 10|
Main contributor
|Field|Value|
|:-|:-|
|GitHub|@tt-a1i|
|Commits to this repo|780 (top contributor)|
|X / Twitter|@t20000622yy|
|Followers|2106|
|Public repos|66|
|On GitHub since|2019-07-21|
──────────────────────────────
📌 How many great GitHub repos have you discovered and completely forgotten about?
Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week.
📬 Never lose track of great repos again. Subscribe free.
446 points · 9 comments
Mentions
Same AI, two developers: why the experienced one spends fewer tokens --- title: "Same AI, two developers: why the experienced one spends fewer tokens" published: true description: "Everyone can build an app with AI now. Give the same model and the same prompt to a first-time builder and an experienced engineer: day 1 looks identical, day 30 doesn't. Where the tokens go, what makes AI-written code last, and a playbook for working like the second one." tags: ai, productivity, softwareengineering, career canonical_url: ayushwing.com cover_image: ayushwing.com series: "Staff-level judgment" --- Everyone is building apps with AI now. My cousin built one. Your manager built one. Somebody built one during a meeting about whether we should build one. That's genuinely great. But it raises a fair question: if a first-time builder and an engineer with ten years of experience use the same model with the same prompt, what's actually different? Let's run the experiment in our heads. Two developers, same AI, same request: > "Build me a task-tracker app with user login." Meet Nia, the native AI builder: smart, fast, has never shipped software before. And Sam, the seasoned engineer, who has broken production enough times to be careful. Day 1: no difference at all Both get a working demo in an afternoon. Login page, task list, a nice dark theme, a little confetti when you finish a task. Both post a screenshot. Both get 40 likes. If you only look at day 1, experience doesn't matter. This is the part of the story everyone's excited about, and they're right to be. The AI did in an afternoon what used to take a week. The difference shows up later, the way it always does in software: in the second month, when you change things. Where the tokens go Here's Nia's day 3. A user reports that tasks sometimes disappear. Nia: tasks disappear sometimes, fix it AI: (rewrites the storage layer) Nia: now login is broken AI: (rewrites the auth flow) Nia: login works but tasks still disappear AI: (adds a retry, a cache, and a second database "for reliability") Nia: it's slower now and still broken. FIX IT PROPERLY AI: (apologises, rewrites the storage layer again) Every one of those messages drags the whole conversation and a growing chunk of the codebase into context again. Every fix touches more files than the bug lives in. After a week the app works most of the time, nobody knows why, and the token bill looks like a phone number. Sam's day 3, same bug: Sam: Read CLAUDE.md. Tasks occasionally disappear after editing. Don't change code yet: find where tasks are written and list the ways two writes could race. AI: Two tabs saving the same task: last write wins, no version check. Sam: Write a failing test that reproduces it with two concurrent saves. AI: (test fails, as expected) Sam: Fix it with a version column and a conditional update. Keep the diff small. AI: (12-line change, test passes) Sam: (reads the diff, commits) Four messages. One small diff. A test that will catch the bug if it ever comes back. Sam spent fewer tokens than Nia, not more. Experience didn't make Sam write better prompts in some magic way. It made Sam ask for smaller, checkable steps. (If that bug looks familiar, it's the same race I wrote about in Model business workflows as state machines. AI doesn't remove these problems. It just reaches them faster.) !Two loops. Prompt and pray: ask for a whole feature, run it, see something broken, say fix it, repeat. Plan, test, ship: plan, write a failing test, make one small change, read the diff, commit, then take the next step. Same model, two loops. Only one of them ends. Explore the interactive diagram The side-by-side | | Nia (first-time builder) | Sam (experienced engineer) | | --- | --- | --- | | First prompt | "Build the whole app" | "Plan the app; don't write code yet" | | Size of each request | A feature, or "fix everything" | One change you can review in two minutes | | Context | Re-explains the project every session | A project instructions file the AI reads every time | | Definition of done | "It looks like it works" | A test passes, and the diff makes sense | | When it breaks | "Fix it" (again) | "Explain why before changing anything" | | Tools | Pastes logs and docs into the chat | Gives the AI tools: skills, plugins, MCP servers | | Dependencies | Whatever the AI suggested | Asks why each one is needed | | Secrets | API key in the code, "temporarily" | Environment variables from the start | | Git | One giant commit called "final" | A commit after every green step | | Day 30 | Afraid to touch it | Adds features on a Friday | None of Sam's column is about AI. It's just engineering: small steps, tests, version control, knowing what "done" means. AI is a multiplier, and it multiplies whatever habits you bring. What makes AI-written code sustainable "Sustainable" is a fancy word for one question: can someone change this code next month without breaking it? "Someone" includes you, and it includes the AI. Four things decide the answer: 1. Tests that describe behaviour. A test suite is the only spec the AI can't misread. With tests, "refactor this" is safe. Without them, every change is a gamble the AI makes with confidence. 2. Small, readable diffs. If you can't explain a change in a sentence, you can't review it, and unreviewed code is how plausible-but-wrong bugs ship. My favourite: a refund endpoint that retries on timeout and pays twice. It looks perfectly correct in a diff (here's how to prevent it). 3. Written-down decisions. A project instructions file (CLAUDE.md, AGENTS.md, .cursorrules, whatever your tool reads) that says: how to run the tests, what the architecture is, what not to touch. The AI stops rediscovering your codebase every session, and that's most of the token savings right there. 4. Boring choices. One database, not five. A library everyone knows, not the one the AI half-remembers. AI is very good at writing glue for popular tools and very bad at debugging an obscure one. Skills, plugins and tools: stop pasting, start equipping The biggest token sink I see is pasting: the same error log, the same docs page, the same "here's how our project works" paragraph, over and over. Experienced developers give the AI tools instead: - Skills and plugins package a repeatable way of doing something, such as a review checklist, a deploy process or an audit, so you don't explain it every time. - MCP servers let the AI read your tickets, query a staging database or check a deploy itself, instead of you copying the output in. (I built one for Java services for exactly this reason.) - Your own scripts: a test command, a screenshot script, a linter. The AI can run them and check its own work. A real example: this site. While building it with an AI assistant: - Archify drew the diagrams, with its own validation checks, instead of the AI hand-placing boxes. - An SEO audit skill (claude-seo) ran its checklist against the built site and found a real bug: robots.txt pointed at a sitemap that no longer existed. - Every visual change was screenshotted in a headless browser before it shipped, which caught a meme overflowing on phones and a diagram that rendered as a broken image. - And the homepage stack section went through two designs I didn't like. Before the third attempt, I was asked to pick a concept from four sketches. That one stuck. That last one isn't a tool at all. It's the oldest engineering habit there is: agree on what you're building before you build it. It turns out it works on AI too. Signs you're vibe coding Score yourself honestly. One point each: - [ ] Your most-used prompt is "fix it". - [ ] You've said "PLEASE" to a compiler in capital letters. - [ ] Your app has 3 state-management libraries and you know the name of one. - [ ] There is a file called utils2_final_REAL.ts. - [ ] Your git history is one commit: "init". - [ ] You don't know what happens if two users click Save at the same time. - [ ] The AI added a cache "for performance" and you were too scared to ask why. - [ ] Your API key is in the frontend, but "only for now". 0–2: you're Sam. 3–5: you're on the way. 6–8: you're Nia, and that's fine. Every Sam started as a Nia. The good news is that every habit in Sam's column can be learned, and the AI will happily help you learn it if you ask it to explain instead of just fix. The playbook If you want to work like Sam starting tomorrow, here's the whole thing: 1. Plan before code. Ask for a plan and push back on it before any code exists. 2. Write a project instructions file on day 1: how to run, how to test, the rules. 3. One change per request, small enough to review in two minutes. 4. Test first for anything that matters: write the failing test, then the fix. 5. Read every diff. If you don't understand it, ask "why" before you accept it. 6. Commit after every green step, so you can always go back. 7. Equip, don't paste: skills, plugins, MCP servers and scripts the AI can run. 8. When stuck, ask for a diagnosis, not a fix. "Explain why this fails" costs less than five rewrites. Takeaways - On day 1, AI makes everyone equal. By day 30, habits make the difference. - Experienced developers often spend fewer tokens, because small steps, tests and saved context beat "fix it" loops. - Sustainable AI-written code has tests, small diffs, written decisions and boring choices. - Give the AI tools, not copy-paste. - Experience isn't about typing faster anymore. It's about knowing what to ask for, and knowing when the answer is wrong. --- Originally published at ayushwing.com.
30 Best Claude Plugins on GitHub (Sorted by Your Job) 30 Claude plugins with 3.9 million GitHub stars between them, sorted into 5 rows so you only need yours: coding, research, saving tokens, design, and writing + video. Don't add all 30. Pick the row that fits your week, add one plugin, and open its repo first to check what it can touch on your machine. 💬 Comment ANYLANCER and I'll send you all 30 links, or grab them here: 1) You write code • Superpowers: obra/superpowers • Matt Pocock's Skills: mattpocock/skills • ECC: affaan-m/ECC • Karpathy Skills: multica-ai/andrej-karpathy-skills • Ponytail: DietrichGebert/ponytail • Agent Skills: addyosmani/agent-skills 2) You research big things • Graphify: Graphify-Labs/graphify • Agent Reach: Panniantong/Agent-Reach • Understand Anything: Egonex-AI/Understand-Anything • Last 30 Days: mvanhorn/last30days-skill • Career Ops: career-ops-hq/career-ops • REA: morluto/rea 3) Huge projects, few tokens • gstack: garrytan/gstack • Caveman: JuliusBrussee/caveman • Claude-Mem: thedotmack/claude-mem • Headroom: headroomlabs-ai/headroom • GSD: gsd-build/get-shit-done • BMAD Method: bmad-code-org/BMAD-METHOD 4) Design & visuals • UI UX Pro Max: nextlevelbuilder/ui-ux-pro-max-skill • Taste: Leonxlnx/taste-skill • Archify: tt-a1i/archify • Impeccable: pbakaus/impeccable • PPT Master: hugohe3/ppt-master • Diagram Design: cathrynlavery/diagram-design 5) Writing & video • Anthropic Skills: anthropics/skills • OpenMontage: calesthio/OpenMontage • HyperFrames: heygen-com/hyperframes • Humanizer: blader/humanizer • I Have ADHD: ayghri/i-have-adhd • Marketing Skills: coreyhaines31/marketingskills Built a skill people would pay for? Sell it on Anylancer: anylancer.com Which row are you? 👇 Star counts from GitHub on Oct 29, 2026. This video was made with HyperFrames. #ClaudeCode #AIAgents #GitHub #Shorts
5 проектов с GitHub, которые прокачают Claude Code 5 проектов с GitHub, которые прокачают Claude Code youtube.com Пять бесплатных дополнений для Claude Code с GitHub: батрак из Warcraft сообщает, что работа готова, Claude говорит как пещерный человек и тратит меньше лимитов, помнит прошлые чаты, рисует схемы и превращается в игровую студию из 49 агентов. 1. peon-ping: PeonPing/peon-ping 2. caveman: JuliusBrussee/caveman 3. claude-mem: thedotmack/claude-mem 4. archify: tt-a1i/archify 5. Claude Code Game Studios: Donchitos/Claude-Code-Game-Studios Ссылки и как поставить в моём Telegram: t.me Звёзды на 28.10.2026. «На треть меньше» у caveman: замеры авторов проекта. Реплики батрака: набор peon из peon-ping (Warcraft III). #ClaudeCode #GitHub #shorts [en-US] 5 GitHub Projects to Supercharge Claude Code 5 GitHub projects that will boost Claude Code youtube.com Five free add-ons for Claude Code from GitHub: a Warcraft farmhand announces when work is complete, Claude speaks like a caveman and spends less than his spending limits, remembers past chats, draws diagrams, and transforms into a 49-agent game studio. 1. peon-ping: PeonPing/peon-ping 2. caveman: JuliusBrussee/caveman 3. claude-mem: thedotmack/claude-mem 4. archify: tt-a1i/archify 5. Claude Code Game Studios: Donchitos/Claude-Code-Game-Studios Links and how to add them in my Telegram: t.me Stars as of October 28, 2026. Caveman has "a third less": measurements by the project authors. Farmhand lines: peon set from peon-ping (Warcraft III). #ClaudeCode #GitHub #shorts
가상 손님 100명이 먼저 답한다, 클로드(Claude) 스킬 파운더 외 4개 | 깃허브 인기 AI 스킬 깃허브에서 별을 많이 모은 클로드(Claude) 스킬 다섯 개가 실제로 무엇을 내놓는지 — 조사 last30days(레딧 · 유튜브 · 틱톡의 최근 30일 반응을 한 장으로) · 기획 archify(한 문장 → 눌러 보는 그림) · 정리 answer-me-with-html(긴 답 → 그림 있는 한 페이지) · 검증 founder-skill(가상 손님 100명 · 가상 이사회 · 본전 계산) · 마무리 humanizer(영어 글의 AI 티 35가지를 찾아 고치기). 화면의 숫자 · 예시는 각 저장소 안내문(README) 기준이고, 별 수는 10/25 기준입니다. 저장소 주소와 설치 문장은 고정 댓글과 소개 페이지에 있습니다. 공식 도움말 기준 웹(claude.ai)에서는 맞춤설정 → 스킬에서 압축 파일(ZIP)을 올리고, 코드 실행이 켜져 있어야 합니다. 믿을 만한 곳의 스킬만 설치하고, 켜기 전에 파일을 읽어 보십시오. 출처 - Claude 도움말 — Using Skills in Claude (2026-10-25) support.claude.com - 깃허브 — mvanhorn/last30days-skill (2026-10-25) mvanhorn/last30days-skill - 깃허브 — tt-a1i/archify (2026-10-25) tt-a1i/archify - 깃허브 — QingYunA/answer-me-with-html (2026-10-25) QingYunA/answer-me-with-html - 깃허브 — Jakeschincariol/founder-skill (2026-10-25) Jakeschincariol/founder-skill - 깃허브 — blader/humanizer (2026-10-25) blader/humanizer #AI #클로드 #Claude #클로드스킬 #깃허브 #AI스킬 #shorts
Describe your system in one sentence and your AI agent draws an interactive architecture diagram. 🔗 tt-a1i/archify Credits: tt-a1i/archify #archify #javascript #opensource
Archify: Turn any idea, plan, or codebase into a beautiful interactive diagram (86k stars) What it does All text below is quoted directly from the project README. >Turn any idea, plan, or codebase into a beautiful interactive diagram. An agent skill for Claude Code, Codex, and more. Why Archify: - Layout judgment over generic auto-layout: the agent chooses hierarchy, spacing, routes, and emphasis; shared automatic endpoints spread deterministically instead of piling arrows on one midpoint. - Typed JSON IR: every renderer-backed mode has a schema and reproducible source. - Atomic validation before delivery: schema, layout, HTML/SVG, route, and label-to-route clearance checks must all pass before a showcase artifact replaces the last known good output. - Failures come with a repair receipt: validate --json and deliver --json return stable rule codes, the exact subject, measured evidence, and only supported repair controls instead of a Node stack or an unstructured retry guess. - Last-good live preview: an optional desktop loop watches one JSON file, refreshes only after the latest candidate passes every gate, and keeps the previous verified diagram visible when a save is incomplete or invalid. - Truthful interaction: focus, upstream/downstream reach, exact routes, role comparison, and stories reuse authored nodes and relationships instead of inventing topology or claiming runtime impact. - Source evidence, only when requested: Evidence-backed Architecture nodes mark themselves SRC n and open Git-verified files and line ranges pinned to one public commit; ordinary artifacts stay source-free. - Portable by default: the result is one HTML file; exports remain full-diagram and free of temporary viewer state. >npx skills add tt-a1i/archify -g Repository tt-a1i/archify Repository stats |Metric|Value| |:-|:-| |Stars|86,013| |Forks|5,858| |Last release|v3.2.0 (2026-10-19)| |Languages|JavaScript 90.8%, CSS 4.5%, HTML 3.2%| |Contributors|90| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|cursoragent: 10, claude: 25| |AI co-authored commits|Claude: 30, Cursor: 10| Main contributor |Field|Value| |:-|:-| |GitHub|@tt-a1i| |Commits to this repo|780 (top contributor)| |X / Twitter|@t20000622yy| |Followers|2106| |Public repos|66| |On GitHub since|2019-07-21| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.
8위 아키파이 tt-a1i/archify 7위 버셀 리액트 베스트 프랙티스 vercel-labs/agent-skills 6위 애디 오스마니 에이전트 스킬 addyosmani/agent-skills 5위 맷 포콕 스킬 mattpocock/skills 4위 에브리씽 클로드 코드 affaan-m/everything-claude-code 3위 지스택 garrytan/gstack 2위 슈퍼파워스 obra/superpowers 1위 REA morluto/rea
2026년 개발자들이 선택한 오픈소스 TOP8 개발부문 #shorts 2026 GitHub 트렌드 총결산 [개발편] — 추천 스킬·도구 8개 8위 아키파이 tt-a1i/archify 7위 버셀 리액트 베스트 프랙티스 vercel-labs/agent-skills 6위 애디 오스마니 에이전트 스킬 addyosmani/agent-skills 5위 맷 포콕 스킬 mattpocock/skills 4위 에브리씽 클로드 코드 affaan-m/everything-claude-code 3위 지스택 garrytan/gstack 2위 슈퍼파워스 obra/superpowers 1위 REA morluto/rea #깃허브 #AI코딩 #클로드코드 #개발자 #shorts Song : Joakim Karud - Clouds soundcloud.com Music promoted by 프리뮤직 Vlog Copyright Free Music [en-US] TOP 8 Open Source Tools Chosen by Developers in 2026 #shorts 2026 GitHub Trends Wrap-up [Development Edition] — 8 Recommended Skills & Tools 8th Place: Archify tt-a1i/archify 7th Place: Vercel React Best Practices vercel-labs/agent-skills 6th Place: Ady Osmani Agent Skills addyosmani/agent-skills 5th Place: Matt Pocock Skills mattpocock/skills 4th Place: Everything Claude Code affaan-m/everything-claude-code 3rd Place: Gstack garrytan/gstack 2nd Place: Superpowers obra/superpowers 1st Place: REA morluto/rea #GitHub #AICoding #ClaudeCode #Developer #shorts Song : Joakim Karud - Clouds soundcloud.com Music promoted by Free Music Vlog Copyright Free Music [id] TOP 8 Open Source Pilihan Pengembang Tahun 2026 di Bidang Pengembangan #shorts Ringkasan Tren GitHub 2026 [Edisi Pengembangan] — 8 Keterampilan & Alat yang Direkomendasikan Peringkat ke-8: Archify tt-a1i/archify Peringkat ke-7: Praktik Terbaik React Vercel vercel-labs/agent-skills Peringkat ke-6: Keterampilan Agen Ady Osmani addyosmani/agent-skills Peringkat ke-5: Keterampilan Matt Pocock mattpocock/skills Peringkat ke-4: Semua tentang Claude Code affaan-m/everything-claude-code Peringkat ke-3: Gstack garrytan/gstack Peringkat ke-2: Superpowers obra/superpowers Peringkat ke-1: REA morluto/rea #GitHub #AICoding #ClaudeCode #Pengembang #shorts Lagu: Joakim Karud - Clouds soundcloud.com Musik dipromosikan oleh Free Music Vlog Copyright Free Music
Archify 已经 8.3 万 Star 了，这次又加了 5 种图，做了个视频给佬友们看看效果 Archify 3.1 更新了，先给佬友们看看这次新增的几种图，下面是用 Claude 加上定制的封面做的视频： []( github.com/user-attachments/assets/478f49bf-7cfb-…) [▶ 点击播放视频（ 30 秒）]( github.com/user-attachments/assets/478f49bf-7cfb-…) 这次一共新增了 5 种图： - ER 图：梳理数据库的表和关系 - 类图：梳理类、接口和它们之间的关系 - 树图：查看项目结构和层级 - 时间线：整理事件经过、项目进展 - 瀑布图：展示请求或任务各阶段的耗时 一些别的场景合适的也可以用这些图例去表示 加上原有的架构图、流程图、时序图、数据流图和生命周期图，现在一共支持 10 种图例了，已经基本能够覆盖绝大部分的画图需求了，如果有一些新的图例需求佬友们也可以在评论区反馈 不止是自然语言，把手绘草图交给 AI ，都可以用 Archify 生成可交互的 HTML 图解。可以放大、查看细节，也能继续通过对话修改。 很多社区的用户向我反馈，比较常见的场景是会用 Archfiy 理解项目、讨论方案、梳理流程、做汇报。甚至有的用户还用 Archify 来做小红书的旅游攻略，看今年剩余的假期，等等各种各样我从来没想到的场景，作为一名毕业刚一年的职场新人，看到这个项目一点一点成长起来也是非常的感慨和难以置信，从去年因为专升本找不到工作，到现在这个项目也给我带来了很多很多。 得到很多朋友喜欢的同时，对我而言也是一种责任，把这个项目打磨的更好，不辜负社区里来自世界各地的用户的期待。 GitHub： tt-a1i/archify 版本说明： github.com/tt-a1i/archify/releases/tag/v3.1.0
好几个 CLI Agent 同时在终端窗口里各忙各的，谁在干什么、谁收工了、谁卡住了，全凭瞎猜？ Hive，就是奔着补这个缺口来的。 🔗 tt-a1i/hive 路子很直白： 1️⃣ Agent 照旧是你本地跑的真实 CLI 进程，没有黑箱 2️⃣ Hive 在外头套一层"团队壳"，让其中一个当 Orchestrator 分派活 3️⃣ 其余 Agent 当 Worker 各干各的，靠 team send 和 team report 互相通状态 4️⃣ 所有任务状态汇总到一份 markdown 文件里，扫一眼就全清楚 说穿了，就是给 AI 团队装了个调度中枢，不再各干各的、互相看不见。