smixs/pohuy: a Russian profanity response style for AI coding agents

What pohuy changes, and who it is aimed at

The README frames the project around a linguistic claim rather than a performance one: Russian mat is generative morphology, so four roots plus prefixes and suffixes carry more meaning per word than plain English. The pitch is that one word, наебнулось, covers what English spells out as "the service has unexpectedly crashed and requires investigation", and the reader knows the situation from the first word.

The target user is narrow and specific. You are running an AI coding agent, you read Russian, and you find the default assistant register (hedged, apologetic, padded with recommendations) slower to scan than a blunt one. The README's before/after table is the whole argument: same technical content, different voice. The package description in package.json calls it a "Session-scoped Russian engineering response style for Pi", which is the most precise statement of scope in the repository. It is a response style. It is not a linter, not a prompt compressor, and not a translation layer for your codebase.

How the extension actually hooks into the agent

pohuy ships as a Pi package. The pi key in package.json declares a single extension entry point, ./extensions/pohuy.ts, and the peer dependencies are @earendil-works/pi-coding-agent and @earendil-works/pi-tui. That tells you the mechanism: the agent loads the extension, the extension shapes responses, and it can use the TUI package to render them. The description says session-scoped, so the style applies to the session rather than to a saved project config.

The repository layout shows more than one delivery path. There is a .claude-plugin/ directory, a codex/ directory, an output-styles/ directory, a skills/ directory, a hooks/ directory, and a commands/ directory. Two shell installers sit at the top level, install.sh and install-codex.sh, and the v1.1.0 release is titled "Codex CLI" while v1.0.0 is titled "родной формат" (native format). So the project started as a native Pi extension and later added a Codex CLI route. The README does not document what each of those directories contains, and it does not describe the hook or skill wiring in prose. Treat the directory names as the map and read the files before assuming behaviour.

The package version field says 0.1.0 while the releases are tagged v1.0.0 and v1.1.0. That mismatch is worth knowing before you script anything against the version string.

Installing pohuy and running your first session

The repository provides install.sh for the Pi path and install-codex.sh for the Codex CLI path. The README does not print the install commands, so the honest instruction is to read the script before running it, then run it:

./install.sh

For Codex CLI, use the second installer instead:

./install-codex.sh

If you are installing as a package rather than from a clone, package.json declares the peer dependencies you need present:

npm install @earendil-works/pi-coding-agent @earendil-works/pi-tui

Node 22.19.0 or newer is required, per the engines field. The package also exposes two scripts you can run from a clone to check your environment before relying on the extension:

npm run typecheck
npm test

The first runs tsc --noEmit. The second runs the extension's own test file through tsx. After installing, start your agent session as usual; the extension is session-scoped, so the change should be visible in the replies themselves rather than in a config file you edit. The README does not document an uninstall step, so plan for that before you install.

The token-saving claim the README refuses to make

This is the part most similar tools get wrong, and pohuy handles it unusually. The badge at the top advertises roughly 96% root savings, and the bench image is labelled КОРНИ-BENCH V1 with the line that pohuy beats frontier models on root economy by seven times. Then the README undercuts its own badge: "Спойлер: токенов не экономит нихуя", a spoiler that it does not save tokens at all, with a pointer to ЧЕСТНЫЕ-ЦИФРЫ.md.

Root economy is a measure of how few distinct word roots carry the message. Token economy is what shows up on your bill. They are different numbers, and the README says the second one does not improve. If you are evaluating pohuy to cut context or cost, you are evaluating it for the wrong reason, and the project tells you so before you install it.

The SWE-Bench Pro image claims Fable + pohuy at 80.3% against Fable at 69.2%, a plus of 11.1 points. That is a screenshot in the README, not a methodology, and there is no harness in the repository layout that would let you reproduce it. Treat it as a claim from the project, not as evidence you can check.

Where pohuy is the wrong tool

The 18+ marker is not decoration. The output is Russian profanity by design, and the README's own examples include insults aimed at code and at whoever wrote it. Any pipeline that forwards agent output to a customer, a public issue tracker, a compliance log, or a colleague who did not choose this style will carry that language with it. The extension changes the register of everything the agent says in the session, not just the parts you find funny.

There is a second, quieter failure mode. The style rewards brevity, and brevity is exactly what you do not want during an incident review or a security write-up, where the sequence of events matters more than the verdict. A response that opens with "мастер лёг, реплики отстали на час" reads well in a terminal and badly in a postmortem document.

Finally, the documentation is thin in places that matter for adoption. There is no documented rollback, no configuration reference in the README, and no description of how the hooks, skills, and output-styles directories interact. You are reading TypeScript and shell scripts to answer questions the README leaves open.

How it differs from caveman and from plain prompt instructions

The README credits caveman as the inspiration and states the distinction directly: caveman saves words, pohuy saves roots. Both are response-style layers for coding agents, and both trade polish for density. The difference is what gets dropped. A word-saving style removes articles, pronouns, and connective tissue while keeping English vocabulary. pohuy keeps the sentence structure and swaps the vocabulary for a morphological system where a small set of roots plus affixes covers a wide range of states. That is why the README can claim the same technical precision at a different register rather than a lossy summary.

The cheaper alternative is a system prompt telling the agent to be terse and informal. That costs nothing to install and needs no peer dependencies. What it does not give you is a maintained set of output styles, a test file, and a Codex CLI installer. Whether that packaging is worth a dependency on @earendil-works/pi-coding-agent is the actual decision, and it depends on whether you already run Pi.

Maintenance, licence, and what an upgrade costs you

The last push to main was on 2026-09-16, and the repository is not archived, so the project is current as of that date. Releases are recent: v1.1.0 on 2026-08-07 added the Codex CLI path, v1.0.0 the same day established the native format. The gap between the package.json version (0.1.0) and the release tags (v1.1.0) means you should pin by git tag or commit rather than trusting the version field if you vendor this.

Licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is the standard reading; it is not legal advice, and if you ship the extension inside a product you should have someone confirm the notice requirements for your distribution format.

Upgrade cost is low in code and non-trivial in review. The shipped surface is a TypeScript extension, a test file, shell installers, and several style and hook directories. Every upgrade is a chance for the output style to change in ways you will notice only in a live session, because the README does not publish a changelog of phrasing. Diff the extensions and output-styles directories between tags before you pull.

Editorial conclusion

Adopt pohuy only if every human reading the agent's output is a Russian-speaking engineer who wants the register change and is comfortable with 18+ language in the terminal. Do not adopt it if output is pasted into tickets, client reports, or any channel with people who did not opt in, and do not adopt it expecting a token or cost win, because the README states plainly that it saves nothing on tokens. Before installing, check the Node version against the engines field (>=22.19.0), read ЧЕСТНЫЕ-ЦИФРЫ.md for what the project itself claims, and confirm whether you are wiring the Pi extension (extensions/pohuy.ts) or the Codex CLI path added in v1.1.0, since those are two different install routes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. smixs/pohuy on GitHub