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

В Go 1.27 появились дженерик-методы, и часть сообщества считает это концом простоты Go задумывался как язык, который учат за выходные: минимум синтаксиса, никаких хитростей. В 1.18 в него добавили дженерики, но только для функций и типов — методам параметры типа не полагались. Аргумент был технический: дженерик-методы интерфейсов трудно скомпилировать эффективно, а раз так, то и конкретным методам они ни к чему. 26 августа Марк Фримен из команды Go объяснил в блоге, почему это решение пересмотрели. Методы служат не только для реализации интерфейсов: они ещё и способ сгруппировать функциональность вокруг типа. Раньше преобразование списка приходилось выносить в пакетную функцию и писать вызовы «наизнанку»: MapList(MapList(NewList(0, 2, 4), add(2)), divideBy(2)). В 1.27 то же пишется слева направо: NewList(0, 2, 4).Map(add(2)).Map(divideBy(2)). Ограничение осталось: параметры типа разрешены только конкретным методам. У интерфейсов их по-прежнему нет — компилятору пришлось бы порождать инстанциации на все возможные типы-аргументы через границу пакета, потому что при раздельной компиляции он не знает, как чужой пакет распорядится вашим значением. Через два дня в r/golang собрал 176 голосов пост «Я ненавижу, куда движется Go»: автор жалуется, что видит в коде req.GetSomething.OrDefault(2) и что язык превращается в Java с Kotlin. Голосов «за» там 69%, для r/golang это необычно спорно, и верхние комментарии на стороне дженериков: «итераторы и дженерики улучшают читаемость и намерение кода», «никто не заставляет вас эти возможности использовать». #go #обсуждение

Архитектор решений: кто это, откуда туда приходят и что спрашивают на собеседовании Сеньор упирается в потолок и слышит «иди в архитекторы». А что там делать? Руководитель направления архитектуры в крупном банке ответил на вопросы новичков по всей дорожной карте: чем архитектор решений отличается от корпоративного, системного и технического; три задачи, за которые он отвечает лично; что случается с бюджетом и сроками, если он забыл одну систему. Внутри: откуда приходят архитекторы (не только из разработки), какие практические знания ценятся, как проходит собеседование и первый год, из чего состоит рабочий день и какой документ считается результатом работы. Если думаете, куда расти без управления людьми, это карта.

Почему агент «тупит» чаще из-за обвязки, чем из-за модели В нашем Нейроканале разобрали harness engineering: всё, что вокруг модели в Claude Code или Codex, называется harness, и именно его настраивают, когда результат не устраивает. Два типа контролей: guides до действия (AGENTS․md, skills, скрипты) и sensors после (тесты, линтеры, ревью другим агентом), плюс правило «ошибка повторилась дважды — добавь контроль, а не чини руками». Полный разбор с примерами, что в какую категорию класть.

Игру для Nintendo 64 декомпилировали за 84 дня вместо 596. ИИ-агенты помогли, но заслуга не только их Крис Льюис восстановил исходники Snowboard Kids из ROM: для всех 2 145 функций написан C-код, который компилируется в байт-в-байт тот же машинный код. Сиквел он разбирал 596 дней, первую часть закончил за 84. Откуда взялась семикратная скорость, автор разбирает честно, без «это всё ИИ». Агенты в четырёх git worktree параллельно матчили функции, уверенно закрывали библиотечный libultra и вели файл DECOMPILATION_LEARNINGS․md с причудами компилятора для следующих запусков. Codex стабильно обгонял Claude, GLM 5.2 автор бросил из-за задержек. Но игра собрана проприетарным SGI IDO 5.3, который перекраивает код в несколько проходов: мелкая правка C меняет распределение регистров. Здесь буксовали и человек, и модели, около 4,8% матчей вытянули эксперты сообщества. Pilotwings 64 люди декомпилировали за 74 дня без агентов. Автор разбирает вклад каждого фактора. #ии

Писать код и делать софт — разные работы. ИИ сделал разницу заметной Эссе, которое сегодня разбирают на 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, когда новая система оплетает монолит и забирает его задачи модуль за модулем. Главная мысль: для одной системы не нужен один подход. Стабильный модуль не трогают, забытую интеграцию удаляют, авторизацию выносят постепенно. Перед тем как предлагать переписывание, сверьте каждый кусок по шести критериям из статьи: как часто меняется, сколько ест поддержки, от чего зависит, есть ли тесты, сколько может лежать и есть ли люди, которые его понимают.