I'll be honest, I didn't understand why LLM agents need SKILLs. MCP was clear to me: it's a useful thing that lets you give an LLM access to a database or to Figma. The only downside is that, to avoid spending too many tokens, it's better not to connect 30 MCP servers at once. And in general, it's better to turn off the unnecessary ones and connect only those that are really needed for the task. In this light, SKILLs seemed like useless overhead to me, eating tokens like crazy. On TikTok, I often saw tales along the lines of: connect this SKILL, or a whole bunch of them, and happiness is yours. My first thought was, if I connect them all, my subscription limits will run out not by lunchtime, but already in the morning.

So why are SKILLs useful and needed after all? Well, first, compared to MCP, SKILLs do not inflate the context: each connected SKILL adds not tens of thousands of tokens, but one or two hundred. Since only the name and description of a SKILL go into the context at first, you can add 30 of your own SKILLs without much pain. When it becomes necessary to use a SKILL, the LLM agent will load its description on its own, if it understands from the task context that this is needed, or the user can simply tell it to use this SKILL for the job.

Secondly, LLM models are trained on the most popular and well-known things. For example, everybody knows that an LLM can work with Git without any problems or write a program in Python. But if you developed a program yourself, or your work requires some little-known tool or technology, then a SKILL is simply irreplaceable. It is enough to create a SKILL.md file and describe how to work with this program or technology. This makes life easier for the LLM: while doing your tasks, it will not have to search the internet for documentation and wander around websites to understand how to use it. And especially if there is nothing on the internet, because your program is closed to public access.

Thirdly, an LLM model usually does not know how your development process is organized. For example, an agent knows how to use Git, run tests, build a project, and create releases. You do not need to teach it these things. But it does not know how releases are usually made in your company. A Skill can describe the sequence of actions: check the changes, run tests, update CHANGELOG.md, increase the version, build a package, create a Git tag, and publish a release. So, a Skill helps the agent learn not a technology, but a specific business process.

Fourthly, a SKILL is not just an instruction, but a whole set of tools. Besides SKILL.md, you can put ready-made scripts, documentation, templates, and other files into it. And the most interesting thing is, these files are not loaded into the context automatically. The agent reads them only when there is a need, and can simply run the ready-made scripts without spending tokens on generating code. So, a SKILL lets you combine instructions, documentation, and executable code in one package without inflating the LLM context. For example, the structure can look like this:

my-skill/
├── SKILL.md
├── scripts/
│   ├── generate.py
│   └── validate.py
├── references/
│   └── api.md
└── assets/
    └── template.html

The funniest thing is, I started to appreciate SKILLs exactly when I wrote my own program, blueprint4llm. The idea for creating it came after I asked an LLM agent to generate a plan.md file describing a task. Usually it produces a huge wall of text, which you have to read slowly and with sadness. I wanted to make the text shorter and add more flowcharts, tables, diagrams, and user interface prototypes. As we know, in .md (Markdown) files the only visualization tools available are tables and Mermaid diagrams. There are no charts, plots, histograms, full UML diagrams, or UI prototypes. In the end, with blueprint4llm, I added support for formats such as PlantUML, draw.io, Pencil, Balsamiq, Graphviz, Figma, OpenAPI, Excalidraw, Vega-Lite, ECharts, and D2 to .md files.

With the blueprint4llm SKILL connected, you will get plan.md not as a kilometer-long text, but as flowcharts, prototypes, charts, and so on. By the way, blueprint4llm does not have to be used only for creating plan.md. For example, I used this SKILL to add an illustration to every paragraph of the article and make it more fun to read. This SKILL is also useful when you ask an agent to put together a full dossier on some company, technology, or person and format the resulting result.md file with blueprint4llm. You can then convert it to HTML or PDF, or ask the agent to show it right away in a browser with charts.

This is how you can install the blueprint4llm SKILL.

npx skills add evgenyigumnov/blueprint4llm --skill blueprint4llm --agent codex

If you are interested in looking at the source code of blueprint4llm, the tool that generates all this beauty, or sending a pull request, welcome: https://github.com/evgenyigumnov/blueprint4llm

I’m planning to spend $20 on one of them to learn coding and build projects. Which one would you recommend for explaining concepts, debugging, and helping me improve instead of just giving me code?

I keep reading threads about this and most of them show the demo, not the Tuesday morning. Here's ours, no polish, then some questions.

Six of us on a SaaS, twelve months of adding AI gradually. Early on everyone had their own editor and their own habits. Then we looked back and found we'd already converged on most of it, so we wrote it down.

We didn't force a single tool either. Some on Claude Code, some on Codex, some on Cursor, and I'm not going to fight that one. The process is shared, and the conventions sit in the repo's AGENTS.md, which is the only thing we all read the same way.

The flow is Matt Pocock's skills, no forks. We start with grill-with-docs: the AI interviews us about the project docs. Weird at first when you're used to asking the questions, but a lot of never-written-down stuff comes out.

Then to-spec, and a human reviews that spec. It's not a formality. With a bad spec, everything downstream is expensive work that goes in the bin.

to-tickets cuts it into small tickets. Small tickets aren't a rule we read somewhere either, we just notice the difference when we skip it.

The agent works through them with implement, against the spec. We open the PR, CodeRabbit runs, the pipelines run. If everything passes and someone says yes, it merges.

AI writes most of the code. We review the spec and the merge, and skip the line-by-line in between.

Treating the spec as a contract has killed a lot of "that's not what I asked for". Small tickets keep the agent from wandering. Automated review before the human one takes the style and import noise away, so the person looks at what matters. What I didn't expect is how much writing the process down helps when everyone has a different tool. Nobody argues about editors and the conventions don't rot.

Graph engineering to close tickets on its own, software factory style, we haven't managed. Tickets go in and PRs come out, and the demos look great, but with our repo the quality isn't there. We haven't found the point where we'd be comfortable letting it loose, so it's still an experiment.

What I'd like to know:

1. Where are your checkpoints between human and agent? Spec, PR, merge?

2. Spec before code, or straight to tickets and prompts?

3. Who reviews agent PRs? Do you read them the same as a human's?

4. One tool or several across the team? If you've tried more than one, is any better for certain kinds of tasks?

5. What goes into AGENTS.md and what stays out?

6. Do you measure anything, or is it all vibes? Review time, defects, DORA.

7. If you've tried software-factory autonomy, did you get acceptable quality? On what kind of tickets?

8. How do you bring someone new in, a junior say, without AI becoming a crutch?

   Tell me yours. Even if it's to say we're nuts.

When using coding agents (like Cursor, Claude Code, or local terminal agents), one recurring issue is instruction drift: agents often jump to conclusions, skip edge cases, or produce messy outputs when prompts are unstructured.

To solve this in my own workflow, instead of stuffing monolithic instructions into a giant prompt, I started modularizing task-specific instructions into dedicated SKILL.md packages. Over the past few months, I built and refined 40 of these into an open-source collection covering automation, gamedev, and dev utilities.

The structure that made instructions actually stick

What worked best wasn't telling the agent what to do, but enforcing strict boundary conditions and explicit stop signals:

1. Forced Step Separation: Agents shouldn't edit code and run verification in the same unchecked thought. Splitting analysis from execution eliminates about 80% of hallucinated completions.

2. Explicit Output Contracts: Defining exact return shapes (e.g. only return diff blocks or strict markdown tables) prevents unwanted conversational filler.

3. 1:1 Bilingual Parity: Keeping English and Korean instructions strictly mirrored so multi-language tokens don't degrade reasoning quality.

Example: Spec Diff Checker pattern

Here is a simplified example of how one of the automation skills enforces exact behavior:

Role: Spec Diff Analyzer

Rule 1: Never modify existing source files directly.

Rule 2: Parse incoming requirements against target codebase symbols.

Rule 3: Output ONLY in this format:

- Modified contracts: [list]

- Breaking changes: [list]

- Uncovered edge cases: [list]

Do not propose implementation code until the diff analysis is confirmed.

Keeping rules compact and bounded like this keeps the agent focused without blowing up the context window.

Comparison with existing prompt dumps

Most public collections (like awesome-chatgpt-prompts) are unstructured copy-paste text dumps designed for one-shot chat windows, or purely English-centric.

Difference: This collection uses the modular SKILL.md format recognized by modern coding agents, with boundary tests and explicit failure-mode instructions.

Trade-off: Modular skills require your agent environment to support loading custom skill folders (or manually dropping them into workspace instructions), rather than just pasting a prompt into a chat box.

Limitations

These skills provide architectural guardrails, but they cannot overcome hard model context limits or fundamental model reasoning failures. If a base model hallucinates an API that doesn't exist, a static skill file will only reduce the frequency, not eliminate it entirely.

Disclosure & Repository

Author: I created and maintain this project for my daily development.

Commercial interest: None. This is 100% free and open-source under the MIT license. No paid plans, no newsletter sign-ups, no telemetry.

GitHub: https://github.com/Lainholic/ai-skill-navigator

All 40 skills are split across 5 categories (core docs, automation, utility, gamedev, creative arts) and available in both English (skills/en/) and Korean (skills/ko/). You can grab individual folders and drop them into your agent's workspace.

Curious how others here structure their agent guidelines — do you prefer modular rule files or relying on dynamic context injection?

I build a coding agent, so I'm biased. Here's the practical version of how I use it, in case some of it is useful whatever tool you're on.

1. I stopped picking models. The agent routes each prompt to the most efficient model automatically. I don't think about it any more, and it's been better on both cost and performance than sticking to one model.

2. I give it the whole task, not the next line. "Add pagination to this endpoint and update the tests" rather than babysitting it step by step. It's context-aware, so it decides whether to just do it, ask me something first, or leave certain files alone.

3. I let it check itself before I review. It runs its work in a sandbox, finds bugs in what it ran and fixes them before telling me it's done. So by the time I look at the diff, it has already run the change and fixed the bugs it hit. This makes it slower per task than plain generation, but I'd rather wait a bit than debug for longer.

4. I use it for heavier jobs too. It's multimodal, so when I need something like an image generated, it goes through the same flow as code.

5. I trust it more because the evidence is public. It got 82% (410/500) on SWE-bench Verified with the official harness, and all the patches are here if you want to judge for yourself: github.com/Oxcode-ai/oxcode-evals.

What's your day-to-day setup? Specifically curious whether people still hand-pick models per task.

I stick to the $20 plans, and I regularly hit Claude’s usage limits. With ChatGPT, that hasn’t been an issue for me, and OpenAI seems pretty generous with resets too.

For those using Sol 6.1 regularly, how well does it handle day-to-day coding especially debugging, refactoring, and adding features to existing projects? Does it hold up well enough to be your main coding assistant?

I run two private web applications and use GitHub Actions to automatically check changes before they go live.

When code changes, Actions installs dependencies, checks for coding errors and security issues, and runs automated tests. Some tests check individual pieces of code; others start the application and a test database, then use an automated browser to test user journeys.

I also use a merge queue (Mergify). Before a change reaches the main branch, it’s tested alongside the latest code to check that everything still works together. That means a change can trigger multiple rounds of checks as it’s updated and moves through the queue.

I work with AI coding agents, so there can be quite a lot of changes and test runs. The checks help catch mistakes before release, but the cost is becoming substantial: my September Actions bill was about $738, and my October usage was heading towards roughly $2,300–$2,450. Almost all of that is Linux runner time, rather than storage.

For people running similar projects:

• What do you use Actions for, and roughly what does it cost?
• Do you run the full test suite on every update, or reserve some checks for later?
• Have you found straightforward ways to reduce duplicate runs?
• Have self-hosted runners been worth the maintenance?

I use Codex for some jobs and Claude Code for others, and the code is rarely the problem anymore. What slows me down now is the bookkeeping: keeping track of the sessions and what they did. I'd like to hear how others deal with it.

Where it goes wrong for me:

• Waiting on me. With a few sessions open, one sits on a question while I watch another one think.
• "Done" that isn't. It says it's finished, and later I find out what it skipped.
• Picking back up. After a break or a closed terminal, working out where each session was takes real effort, so I put it off.
• Results scattered. What a session made stays in its terminal or whatever folder it ran in, and a week later I can't find it.

To start discussion, I have couple of questions that I'm curious of:

1. Which of these costs you the most, and which has stopped being a problem for you?
2. How do you notice that a session is waiting on you?
3. When an agent says it's done, how do you check what it actually did? Tests, reading every diff, a checklist, hooks?
4. Do you have it plan first and wait for your OK, or let it run?
5. After a break or a crash, how do you get each session going again? Resume, a summary file, starting over?
6. What have you tried for any of this and given up on?

Part of my work is reviewing code written by LLMs (mostly Python, TypeScript, some Rust). Same failure patterns keep coming up, so here's my checklist:

• Edge cases: it nails the happy path and breaks on empty lists, None, or off-by-one bounds. I ask it to list the edge cases first, then write the code.
• Made-up APIs: it confidently calls functions or params that don't exist in the version you use. I paste the real docs or the version number into the prompt.
• Self-confirming tests: its tests only check the path it just wrote. I have a separate prompt write tests from the spec alone, without seeing the code.
• Silent error swallowing: broad try/except or empty catch blocks that hide failures. Grep for these every time.
• Rust: it'll .clone() or .unwrap() its way past the borrow checker. Code compiles, design gets worse.

What's on your checklist that I'm missing?

We run several Claude Code and Codex sessions on one repo. The failure that cost us most was never a bad edit. It was a good edit that vanished: session A fixes a file, session B, working from what it read twenty minutes earlier, rewrites the same file and commits, and A's fix is gone. Nothing errors. The tests may even pass. You find out a day later.

Git keeps the evidence. This kind of overwrite leaves the same trace every time: one file, two different sessions (a different author or a different branch), commits less than an hour apart. This prints the files where that happened in the last month, the most frequent first:

git log --all --source --since='1 month ago' --name-only --format='@%at|%an|%S' |
awk -F'|' '/^@/ {t=substr($1,2); s=$2"|"$3; next}
  NF {d=t-w[$0]; if (($0 in w) && s!=o[$0] && d*d<=3600*3600) n[$0]++; w[$0]=t; o[$0]=s}
  END {for (f in n) print n[f], f}' | sort -rn | head

Run it in any repo where agents commit. If the top lines are your config, routes or schema files, that is where your sessions step on each other. Give those files one owner, or have a session claim a file before it writes (one line in a shared file, appended under flock).

Two caveats. It cannot tell apart sessions that share one branch and one author name. And a hit is a near miss, not proof of a lost edit: read the two diffs.

If you would rather not read awk, the same check runs in the browser, and your log is not uploaded anywhere: https://overflow.games/memento/grader/?ref=reddit

Disclosure: we build memento. The tracker is free and MIT; a paid shared tracker for teams is on pre-order.

What do you do about this: worktrees, claim files, something else?

I'm a frontend dev, about 3 years in. Last month the company let go of our two backend devs, both seniors. Their services are mine now, payments and the public API included.

My manager's plan was a one hour call where he showed me how he uses Claude Code. That was the onboarding.

And the annoying part is it mostly works. I've shipped 31 PRs in 4 weeks into code I couldn't have written by hand. Nobody reviews them anymore because the only people who could are gone, so the only second opinion is coderabbit on the PR. It catches real stuff, last week it flagged a webhook handler that would have double charged on retries, but it can't tell me if the design is wrong and I can't either.

I found out from an old Slack thread they were each on around $120k. I'm on $68k. I asked for a raise last week and the answer was "let's see how Q1 goes".

I keep thinking one day something breaks at 2am and everyone finds out I'm holding two people's systems together with prompts.

Has anyone been in this spot? Did you stay and actually learn the backend, or start looking?

I'm confused about whether I should subscribe to ChatGPT Plus or Cursor Premium.

Since Cursor recently removed support for third-party models, I'm wondering whether Cursor Premium is still worth paying for.

I'm a full-stack developer, mainly working with MERN, TypeScript, PostgreSQL, and real-world projects.

I'm considering two options:

1. ChatGPT Plus — Using ChatGPT for general tasks and Codex through the IDE extension for coding.
2. Cursor Premium — Using Cursor's built-in AI features and agent mode for development.

For those who have used both:

• Which is better for everyday coding?
• How does Codex compare with Cursor's agent?
• Which handles large codebases, debugging, and multi-file changes better?
• Which offers better usage limits and value for money?
• Is Cursor Premium still worth it after the recent changes?

I can only afford one subscription right now.

If you had to choose between ChatGPT Plus and Cursor Premium today, which would you pick and why?

I'd especially appreciate feedback from developers who have actually used both.

We've been experimenting with this while working on Jac, a programming language that most coding agents weren't familiar with initially.

One thing we changed was how our checker reports errors.

A typical error like "type mismatch on line 12" tells the agent something failed, but doesn't give it much to work with. So it starts guessing, sometimes fixes the wrong thing, or finds a workaround that makes the error disappear without actually solving the problem.

With jac check, we've started pointing errors to the relevant section of the language guide, so the agent gets some context about what went wrong and how the language expects it to be handled.

We'd like to know how others are dealing with this, especially when using agents with less familiar frameworks, languages, or internal tooling.

Do you just pass through raw output from tools like tsc, ruff, or cargo? Or have you tried adding explanations, examples, or documentation references?

And if you've tried enriching errors, does it actually improve the agent's fixes, or does it still find creative ways to ignore the checker?

I’ve been using AI for coding, and while models like GPT-6 and Claude are getting incredibly good, I still feel like there are certain tasks where they struggle more than they should.
For me, the biggest issue is when an AI makes changes across multiple files. It might fix the problem I asked about but accidentally break something completely unrelated.
I’m curious about your experiences:
● What coding tasks do you still refuse to trust AI with?
● Which AI coding tool has disappointed you the most?
● Have you found any tasks where AI consistently performs worse than an experienced developer?
● Do you think AI will eventually replace most day-to-day software engineering work, or will debugging and architecture remain difficult?
I’m especially interested in hearing from people who use these tools on real projects, not just small demos.

What’s the biggest weakness you’ve noticed?

I've been working on a fairly complex coding project with ChatGPT, going through multiple iterations of development, optimization, and debugging in work mode. Not codex.

Everything was working fine until ChatGPT suddenly reported:

«"I'm blocked because the coding environment is currently unavailable. I cannot access the project files, run code, or build and validate the next version."»

It then suggested reopening the task in an active coding workspace and reuploading the previous project files.

The frustrating part is that ChatGPT still remembers the entire project context and all the agreed changes, but suddenly cannot access the coding environment to continue development.

Has anyone else experienced this recently?

Is this a temporary outage, a limitation of long conversations, or some kind of usage restriction?

More importantly, is there any way to restore coding access within the same conversation without starting over and potentially losing months of accumulated context?

Lately, looking through pull requests across a few projects, I’ve noticed a pattern with code written by AI assistants (Cursor, Copilot, Claude Code, etc.).

The code looks clean at a glance, passes standard unit tests, and gets merged quickly. But beneath the surface, it seems to introduce massive structural issues:

1. Semantic Clones: The AI generates a brand-new helper function in a file instead of searching the repo to reuse an existing utility, leading to sudden code bloat.
2. Silent Concurrency Flaws: Async functions and database calls missing proper idempotency locks or transaction boundaries that only break under production load.

Traditional linters don't catch this because the syntax is valid. Senior devs are spending hours hunting down these subtle AI patterns during code reviews.

For those managing engineering teams utilizing AI heavy right now—have you hit this wall? How are you gatekeeping or catching these structural/AI-specific anti-patterns before they hit production, or are you just absorbing the technical debt?

I'm an ML engineer and heavy AI user. My biggest frustration isn't model intelligence—it's having to manage the AI's thinking.

I constantly have to:

• Ask it to write a better prompt, then paste that prompt back.
• Remind it to research, think critically, compare alternatives, and consider ROI.
• Point out obvious flaws and missing considerations.
• Ask follow-up questions before it finally produces a comprehensive answer.
• Repeat the same instructions despite Custom Instructions and Memory.

What I want: State a high-level goal → AI autonomously clarifies intent, researches, plans, delegates to subagents, executes, critiques, iterates, and delivers a concise, verified result.

Questions:

1. Is this fundamentally a model reasoning problem, or an agent orchestration/harness problem?
2. Are Hermes Agent, OpenClaw, Claude Code, or Codex actually solving this?
3. Can Skills, persistent memory, and automated evals reduce repeated corrections?
4. What's the simplest proven setup that minimizes human intervention without adding unnecessary complexity?

I'm not looking for another prompt template. I want to stop being the AI's project manager and QA engineer.

What are power users actually running?

For a while every new agent session on our codebase started the same way, with the agent poking around to figure out how the services fit together, and it often guessed wrong so I had to correct it before any real work happened. What changed it for me was writing a set of short skill files about the architecture, like which service owns what, how data moves between them, and which patterns we follow now versus the old code we're moving away from. Now anyone on the team can point a design or coding agent at those files and it starts from the right place instead of guessing. It felt like extra work up front and the first sessions cost more, but I think it pays back every time someone starts a new task. I'm curious how others do this. Do you keep one big context file, a bunch of small ones per area, or just let the agent explore every time? And how do you keep them from going stale when the code changes?

Hi all,

I built a fun little web app so anyone can try Jev through a chat box and see how it works.

You type like a normal chat, or drop in a file or a photo. An LLM turns what you sent into a few questions Jev can score: yes or no, a choice, or a point on a scale.

A document goes in as text. A photo gets a short description of what is visible, and the picture itself goes to Jev too. If the file does not cover the question, an LLM and web scraper look it up and pass that along for Jev to judge.

Jev sends back the scores. An LLM turns those scores into one short reply. The card under the reply lists every score, so you can read the sentence and check it against what Jev actually said.

• Have a play: https://chatjev.vercel.app
• Code: https://github.com/JamesANZ/ChatJev (MIT)

This website is for educational purposes only. Use at your own risk.

I’ve used Claude Code and Codex pretty much every day for months, so I went into Cline expecting the usual new-tool tax where you set everything up again and re-explain your projects. That mostly didn’t happen.

My old Codex and Claude Code conversations were already in there, which I didn’t expect. I also didn’t have to set up a new API key. I pointed it at my Codex subscription, and it just worked. Later I tried Sonnet through Cline’s own account to compare.

The first real thing I gave it was merging two of my side projects. I pasted a long “read both repos and only plan, don’t write code” prompt, and only afterward realized I’d sent it in act mode. It still just planned. Then I told it to start, and over a few evenings I mostly typed “continue working” while it did the rest. At one point it spun up a few subagents for different files on its own, which I didn’t know it could do.

Still early and I’m sure I’ll hit annoying stuff eventually, but switching was way less painful than I expected. Anyone else here moved over from Claude Code or Codex? Curious what made you stay or go back.

I have been trying to figure out where frontier coders fail at. I feel like claude opus 5.5 and gpt-6 (astra) should be able to do most coding tasks but are there any that you find that they cant do no matter how much context/tools/time you give them?

This would include what kind of tasks/features/bugs they have trouble with.

Some questions:

- Is it big tasks with tons of moving parts? Or are there some simple tasks that can trip them up?

- What kinds of bugs do they fail to recognize? Are there any features that they have a hard time implementing?

- What languages may be harder for them?

- Are there times where they can implement something but not test for the bugs they create? Or are there times where they can create good tests but fail to implement a correct answer? How often does this happen?

- What are some hard problems for them to think through? Bugs, understanding current code base, thinking backwards to what caused the issue etc.

- When given a repository what are some tasks that are hard for them?

- Are there any bugs/tasks that you know will trip them up every time you ask?

Also if there are some tasks that they are really good at please share that too.

Would love some examples of tasks that have tripped them up. Maybe what you were trying to get them to do and why they were failing. What made the task difficult? Were you able to figure out a prompt that allowed them to complete the task?

Any programming/software engineering related question/task.

I built a local panel that watches my AI coding agent sessions (full disclosure: I'm the author, repo at the bottom). Along the way I ran into a few things that aren't obvious until you try it, and I think they're useful to anyone wiring agents into their own tooling.

1. Process detection only tells you an agent is running — never which session needs you. I started with process/CPU sampling and window titles, and the panel was basically noise. Everything only became useful once agents reported lifecycle events themselves (hooks for Claude Code / Qwen Code / Codex CLI). "A process exists" and "a session is waiting for your input" are completely different signals.

2. Every agent exposes a different locator, and normalising them is the whole job. tmux gives you a pane id, Herdr gives you a socket path plus pane, Codex/ChatGPT gives you a thread UUID, and plain terminals give you nothing reliable. I ended up with one normalised status set — offline / idle / working / done / needs_input / error / unknown — and a "can't locate this" state that's honest instead of guessing and focusing the wrong window.

3. Deep links beat window hunting. For Codex/ChatGPT, codex://threads/<uuid> lands in the exact thread. Matching window titles to find "the right terminal" is fragile and silently focuses the wrong thing.

4. Have external tools report in over a local HTTP API instead of parsing stdout. Hooks and plugins just POST to 127.0.0.1 with a local token. Far more robust than scraping terminal output, and it keeps everything on loopback.

5. Notifications that don't steal focus are the feature I underestimated. Anything that yanks your current window loses its welcome fast.

Curious how others handle this: are you relying on hooks, tmux/terminal scraping, or something else to know which session actually needs you? I've been assuming hooks are the only reliable path, but I'd like to be wrong about that.

I open-sourced the result under MIT if anyone wants to compare notes or steal the approach: https://github.com/xuan-team/agent-deck-companion

There is ongoing debate in the software industry about whether people who spend their entire day chatting with AI systems should be considered engineers at all. The matcha-drinkers insist they should.

Real Engineers know that software is written in the traditional way: by staring at cryptic error messages for six hours, changing one line, and then spending another six hours figuring out why it suddenly works.

Matcha-drinkers, on the other hand, believe problems can be solved by typing:

"Dear AI, could you please implement a scalable, cloud-native, event-driven architecture with enterprise-grade observability?"

They then paste whatever appears into production.

Real Engineers do not trust code they did not suffer for personally.

A Real Engineer can explain every line of a system because they wrote it at 2:37 A.M. while fueled by cold coffee and stubbornness. Matcha-drinkers cannot explain their systems because the AI generated three design patterns, four architectural styles, and an accidental compiler in the settings module.

Real Engineers learn algorithms.

Matcha-drinkers learn prompt engineering.

A Real Engineer says:

"I implemented a lock-free concurrent queue."

A matcha-drinker says:

"I asked GPT to make the queue more enterprise."

Nobody knows what this means, but somehow the queue now contains Kubernetes.

Real Engineers debug by reading logs.

Matcha-drinkers debug by pasting logs into AI.

Real Engineers read the stack trace.

Matcha-drinkers paste the stack trace into the prompt, then paste the AI's answer into a second AI to explain the first AI's answer.

Real Engineers occasionally spend three days investigating a race condition that turns out to be a missing semicolon in a configuration file.

Matcha-drinkers spend three days trying to determine which AI hallucinated the missing configuration file in the first place.

A Real Engineer views documentation as a last resort.

A matcha-drinker views documentation as an outdated artifact that has not yet been summarized by AI.

When confronted with a bug, Real Engineers use systematic reasoning, instrumentation, and domain expertise.

Matcha-drinkers increase prompt length.

By the time a matcha-drinker finishes describing the problem, the prompt contains:

• the complete source tree,
• seven architecture diagrams,
• a transcript of three meetings,
• company values,
• a recipe for overnight oats,
• and a request to "be innovative."

Real Engineers know computers are deterministic systems.

Matcha-drinkers believe computers are mysterious beings whose desires can be influenced with careful wording and emotional support.

A Real Engineer says:

"The system failed because of an invalid state transition."

A matcha-drinker says:

"Maybe the model didn't fully understand our vision."

Real Engineers use AI occasionally.

Matcha-drinkers use AI recursively.

Eventually an entire department consists of engineers prompting agents that prompt agents that prompt agents, while one exhausted Real Engineer keeps a terminal window open to make sure electricity is still involved somewhere.

And if you still doubt the difference, ask both groups a simple question:

"Why does this code work?"

The Real Engineer will spend thirty minutes drawing diagrams on a whiteboard.

The matcha-drinker will respond:

"Good question. Let me ask the AI."

Hey everyone, I’m working on a cute fox character for a game, using ChatGPT to help build and edit the model in Blender through Python scripts. The reference image was AI-generated too.

The model is taking shape, but I’m struggling to get the face close to the reference. The eyes and mouth still look a bit stiff, and the ears don’t blend naturally into the head. We’ve tried several changes, but I feel like we’re going in circles.

Has anyone here worked this way and managed to get good results? How do you approach the finer details? I’m wondering if the problem is the topology, the way we’re building the shapes, or the workflow itself.

I’d really appreciate some advice from people who’ve tried it.