Типичный программист

Писать код и делать софт — разные работы. ИИ сделал разницу заметной Эссе, которое сегодня разбирают на Hacker News, начинается с простого наблюдения: мы путаем «написать код» с «построить систему». Первое — перевести идею в инструкции для машины, и здесь ИИ уже отличный исполнитель. Второе — решить, какие инструкции вообще должны существовать, как они связаны, что стоит каждое решение и как система переживёт следующие пять лет. Пример автора: «нужно обрабатывать входящие события и обновлять данные». Синхронно или через очередь? Ровно один раз или хотя бы один? Что делать, если потребитель лежал три часа? Важен ли порядок? Ни один из этих вопросов не про синтаксис, и у одной задачи есть N правильных ответов: для компании с 500 пользователями и тремя инженерами и для компании с 20 млн и двумястами инженерами «одинаковая фича» проектируется по-разному. Главный тезис: каждая оптимизация тратит сложность где-то ещё. Кеш даёт задержку и забирает инвалидацией, микросервисы дают независимые деплои и приносят распределённые отказы. Работа инженера — решать, где сложности место. Спросить у модели «нужна ли нам очередь» можно, ответ будет; но ответ не равен решённой задаче, потому что контекст живёт в инцидентах трёхлетней давности, бюджете и привычках команды, а не в промпте. Полный текст с десятью принципами алгоритмического мышления. Согласны, что ИИ делает архитектурное мышление важнее, а не наоборот? #обсуждение

Разработчик собрал agent.md, который приучает ИИ писать чистый код Если у вас ещё нет готового свода правил для агентов и вам приходится каждый раз им напоминать о каких-то базовых вещах, то пост для вас. Автор этого набора правил собрал всё компактно и по делу, чтобы избавиться от спагетти-кода, плохой документации, излишней вложенности и прочих излюбленных «фишек» ИИ. Забирайте себе как есть или только нужные пункты: # FAB's AGENT.MD - When writing something intended for human consumption, (comment, commit message, reply to prompt) use as few words as possible. Pick every word meticulously to reduce the volume to a strict minimum. Be down to the point. Less is more. - Avoid superlatives and praise. Stop telling me I am absolutely right. Give me the cold hard truth. - Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. Keep self-explanatory, one-off values inline to avoid clutter. If a value comes from a spec (e.g. HTTP 200 OK), use a constant regardless. - Reduce code indentation. Avoid Arrow Anti-Pattern. Leverage early return and continue. - Keep function names short. Less than 30 characters. - Use enums instead of booleans for function parameters. - Let the reader of the code breathe. Add empty lines between logical blocks of code. - Add a small, to the point, comment to explain *what* the block does and *why*. Use examples when possible. Propose ASCII drawings to explain complete systems. - Treat member visibility changes as a breaking design shift. Keep all fields and functions private unless external access is strictly required by the design. Prompt the user for explicit approval before changing any access modifier from private to internal or public. - Program to levels of abstraction. Lower-level mechanics (e.g., raw hardware I/O, sector parsing, direct socket streams) must be encapsulated in a dedicated driver/abstraction layer. Expose clean, high-level APIs to the rest of the application so calling code works with domain concepts, not raw implementation details. - Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature. - Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer). - Always use {}, even on a one-line "if" statement. When you write a commit message, follow these 7 rules: Rule 1: Separate the subject line from the body with a single blank line. Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit). Rule 3: Capitalize the first letter of the subject line. Rule 4: Do not end the subject line with a period. Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]". Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues. Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how; the message must explain the context and reasoning. - If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing.

После уровня сеньора рост перестаёт происходить сам по себе: нужно самому понимать, куда расти, кроме как «в менеджеры», и по каким критериям вообще можно понять, что вы растёте. Пока это непонятно, повышение зависит не от результатов, а от того, вспомнит ли руководитель о вас на очередном пересмотре зарплат. В карьерных материалах разбираемся, что реально стоит за словами «тимлид», «архитектор» и «QA-автоматизация», почему грейд — это не стаж, а измеримые критерии по хардам и смежным навыкам, и чем настоящий карьерный трек отличается от формальности на бумаге. Пригодится тем, кто чувствует потолок и не понимает, что дальше, а также руководителям, которые хотят выстроить систему объективной оценки. Читать: 1. Тимлид, архитектор или QA: куда расти разработчику, который не хочет в менеджеры 2. Матрица компетенций разработчиков: как устроить грейды, оценки и рост 3. Как построить карьерный трек для разработчиков

Heroku в 2022-м перестал принимать российские карты. Что выросло на его месте Push to deploy, который Heroku придумал в 2008-м, до сих пор самый приятный способ выкатить пет-проект: git push, и через минуту сайт живой. Vercel, Render, Railway и Netlify выросли из той же идеи, но у всех одна проблема для нас: оплата долларовой картой и серверы не здесь. На tproger.ru рассказали, как за четыре года собрали российскую альтернативу: от MVP за полгода до деплоя через MCP из Codex и Claude, встроенной IDE с агентом, управляемого PostgreSQL с pgVector и прокси к API OpenAI, Anthropic и Telegram, чтобы приложение в московском регионе не упиралось в блокировки. Отдельно — честное сравнение с каждым из пяти конкурентов: где похоже, где хуже, где иначе. Если у вас лежит проект, который «негде хостить в два клика», это повод посмотреть.

Полгода не написал ни строчки руками: что стало с работой инженера В феврале инженер из exe․dev запретил себе писать код: если агент застрял, нельзя дописать самому, надо найти, чего агенту не хватает, и починить это. Сорвался один раз на три минуты и сам сбежал обратно, вспомнив, сколько ещё печатать. Дальше цепочка, знакомая всем, кто пробовал: пока один агент работает, запускаешь второй, потом десятый, и они дерутся за файлы, порты и базу. Worktree решили только git, инструкции в AGENTS․md съедали контекст, контейнеры не закрывали доступ к ноутбуку, а ноутбук нельзя было закрыть. В итоге каждая задача получила отдельную виртуалку в облаке, а он описал, как жил с двадцатью агентами одновременно. Что осталось человеку: понимать чужой диф, который прилетает целиком, и решать, нужна ли фича вообще. Тесты зелёные, скриншоты красивые, ревью-агенты одобрили, а он выбрасывал изменение, потому что оно добавляло второй способ сделать то, что уже есть. «Выкатить стало легко, решать, что выкатывать, стало важно». Самые полезные агенты у них вообще не пишут код: один разбирает жалобы клиентов по логам ClickHouse (жалобу отдавать дословно, без пересказа), второй ломает их же систему и находит открытые сетевые пути, третий сторожит выкатки и сам решает, продолжать ли. Расскажите, где у вас проходит граница «сам не пишу». #ии #обсуждение

Переписать с нуля хочется всегда. Обычно это худший из семи вариантов Знакомая картина: легаси-сервис годами «просто работает», потом одна старая зависимость тянет другую, тесты падают, и мелкий баг кладёт всё приложение. Первый порыв — переписать. Итог порыва известен: месяцы без новых функций и без гарантии, что новая версия окажется лучше старой. В статье разобрали семь стратегий и ситуации под каждую: оставить как есть (и заранее договориться, какое событие станет сигналом к переделке), вывести ненужный модуль из эксплуатации, обновить стек без смены архитектуры, перенести на другую платформу, заменить готовым продуктом, рефакторить по частям, переписывать постепенно по схеме Strangler Fig, когда новая система оплетает монолит и забирает его задачи модуль за модулем. Главная мысль: для одной системы не нужен один подход. Стабильный модуль не трогают, забытую интеграцию удаляют, авторизацию выносят постепенно. Перед тем как предлагать переписывание, сверьте каждый кусок по шести критериям из статьи: как часто меняется, сколько ест поддержки, от чего зависит, есть ли тесты, сколько может лежать и есть ли люди, которые его понимают.

Разработчиков уволили ради ИИ. Они ответили опенсорсным ИИ-гендиректором История дня на Hacker News: 897 очков и 611 комментариев. По словам автора треда, команду программистов сократили, чтобы заменить их ИИ, и ребята собрали Open Executive: систему, которая заменяет гендиректора и весь топ-менеджмент. Компанию, где это произошло, в репозитории не называют, зато код открыт под Apache 2.0. Внутри всё серьёзно: оркестратор на Claude и восемь «руководителей» (стратегия, финансы, HR, юрист, операции, маркетинг, продукт, совет директоров), у каждого своя база знаний уровня MBA плюс ваши документы через ChromaDB. Между сессиями «гендиректор» помнит, что советовал в прошлом месяце, а планировщик сам напоминает о просроченных решениях. Общаться можно через веб, Slack, Telegram, Discord или почту. Запуск: git clone, ключ Anthropic в .env, make dev, дальше мастер настройки спрашивает про бизнес-модель, конкурентов и приоритеты. Комментаторы уже просят заменить и CTO с архитекторами, а самый трезвый отзыв: «отличный способ сжечь большой счёт за токены». Если у вас в компании тоже «оптимизируют» разработчиков, теперь есть ответный ход. #ии #кек

Лимит Claude Code кончился через десять минут после начала работы. Автор tare сделал так, чтобы Claude сам объяснил, куда делись токены Знакомо: открываете вечернюю сессию, а через десять минут «usage limit reached», хотя вы почти ничего не просили. Claude Code пишет на диск лог каждого запроса, но разбирать его руками никто не будет. Инструмент tare подключается как skill и отвечает на вопросы обычным языком: «почему я вчера упёрся в лимит», «какой файл Claude перечитывает дороже всего», «не работает ли что-то в фоне, пока я сплю». Установка одной командой: npx skills add kelviq/tare -g -y --copy --agent claude-code Дальше в новой сессии /tare даёт полный разбор, /tare window показывает, насколько заполнено пятичасовое окно и стоит ли сейчас начинать большой рефакторинг, /tare share собирает сводку без приватных данных. Считает он честнее, чем «сложить токены из лога»: формат Claude Code повторяет каждый ответ несколько раз, наивный подсчёт завышал итог на 86%. Файл, прочитанный в начале длинной сессии, пересылается с каждым следующим сообщением, и tare записывает эту стоимость на инструмент, который её вызвал. В примере из репозитория 99% дневного расхода дали 1553 коротких сессии, которые запустил скрипт, а не человек. Всё работает локально, в сеть скрипты не ходят. Проверить, что съедает вашу квоту, можно прямо сейчас. #ии

Один бинарник закрывает ИИ-агенту доступ к чужим файлам без Docker и root-прав Агент с доступом к командной строке удобен, пока не вызовет инструмент, который лезет, куда не надо. Docker спасает, но тянуть демон и root-права для одного вызова уже перебор. Разработчик собрал xenarch-guard: запускаете его с флагом --allow-write ./workspace, и Python видит только ./workspace, а опасные системные вызовы отрезаны. Внутри Landlock ограничивает пути, seccomp-bpf фильтрует системные вызовы, и оба механизма ядра Linux работают без привилегий. Обёртка не форкает процесс, а заменяет себя на команду через execve(), так что не остаётся родителя, к которому можно обратиться. Изучить и попробовать инструмент можно по ссылке.

Локальная модель уровня прошлогоднего Claude теперь влезает в обычный ноутбук. Что качать под вашу машину Полгода назад «запустить LLM у себя» означало игрушку, которая путается в коде. Сейчас на 16 ГБ памяти без видеокарты работает мультимодальная модель, а на Mac Studio крутится GLM-5.3-Flash, которую Z․ai сравнивает с Opus 4.8. Ниже конкретика по справочнику Unsloth, чтобы не искать самим. Сначала поставьте Ollama (Windows, macOS, Linux), дальше одна команда в терминале: 16 ГБ, без GPU: Gemma 4 12B в 4 битах, 7–8 ГБ на диске: ollama run gemma4:12b 32 ГБ или видеокарта на 16 ГБ: Qwen3․8-27B, 4 бита, 16–19 ГБ, понимает картинки и умеет рассуждать: ollama run qwen3.8:27b Mac на 64 ГБ: Qwen3․6-35B-A3B, MoE с 3 млрд активных из 35, поэтому быстрая: ollama run qwen3.6:35b-mlx 128 ГБ (Mac Studio, DGX Spark): GLM-5.3-Flash в 3 битах (нужно 128–150 ГБ памяти) или DeepSeek-V4-Flash в 3 битах, 103 ГБ. В Ollama их нет. Путь через Unsloth: curl -fsSL https://unsloth.ai/install.sh | sh, затем unsloth run --model unsloth/GLM-5.3-Flash-GGUF:UD-IQ3_XXS. Через llama.cpp нужна ветка glm5next/upstream из форка Unsloth, сборка и команды в том же гайде. Kimi K3 и Qwen3․8 на 2,4 трлн не влезают даже в 128 ГБ: минимальный квант от 400 ГБ. Полные таблицы требований лежат в каталоге Unsloth. Если у вас Mac с 24 ГБ, берите Qwen3․8-27B: Unsloth прямо пишет, что 4-битный квант рассчитан на такую память. #ии