Kurgan-Telecom Ru | Информационные технологии

В эпоху ИИ-хайпа многие обещают, что теперь кодить не нужно — достаточно «поговорить» с моделью. Автор решил проверить это на практике: за три вечера, используя только бесплатные версии Claude и Qwen, он создал прототип приложения для мониторинга игровых событий в реальном времени через чтение памяти процесса Royal Quest.

Путь оказался тернистым: от неактуальных логов и зашифрованного трафика — к CheatEngine, Wine на macOS, PyInstaller и проблемам с кодировкой. Чат-модели помогли быстро сгенерировать ядро приложения, реализовать экспорт в JSON/TXT и даже простой дашборд, но каждая итерация сопровождалась багами, потерей контекста и переписыванием кода с нуля.

Делюсь честным опытом: где ИИ действительно ускорил разработку, а где превратил её в бесконечный цикл «запрос → правка → провал». В финале — практические рекомендации: как структурировать проект для ИИ, сохранять контекст и избегать типичных ловушек.

Результат — рабочий MVP, открытый на GitHub, и убедительный вывод: ИИ — мощный соавтор, но пока ещё не замена внимательному разработчику.

Когда релиз раскатан не на всех, классическая схема "до" и "после" начинает рушиться: метрика растет или падает одновременно из-за сезонности, внешнего фона и изменений в каналах, а не только из-за продукта. При этом AB теста может не быть, но данные по группам есть почти всегда: по гео, сегментам, кластерам, витринам.

В этой статье разбираю два практических подхода, которые позволяют оценить эффект релиза в таких условиях. Первый - diff-in-diff: сравниваем, насколько изменилась метрика в затронутой группе относительно контрольной, и тем самым вычитаем общий фон, который влияет на всех. Второй - синтетический контроль: строим базовую линию для затронутой группы как сумму метрик нескольких контрольных групп с весами, подобранными так, чтобы до релиза эта конструкция максимально повторяла историю затронутой группы.

Отдельный акцент на том, что обычно искажает выводы: заметный рост или падение разницы между группами до релиза, изменения состава, локальные акции или технические инциденты в контрольных группах, а также ситуации, когда базовая линия плохо повторяет период до релиза и тогда мы измеряем в основном ошибку модели, а не эффект релиза. В конце показываю, какие проверки стоит сделать, чтобы результат не держался на удачно выбранных границах периода или на одной контрольной группе.

Если в первой части мы работали с одной временной линией метрики, то здесь переходим к более распространенному случаю: несколько групп, частичная раскатка и необходимость отделить влияние релиза от общего шума.

RedOS - это импортзамещанная ОС, по сути - пряморукая центосообразная сборка.

Sway - это тайлинговый оконный менежер.

По умолчанию RedOS идет с DE Mate. Есть также сборки на Gnome и KDE. А вот тайлинговых сборок по умолчанию не предлагается, к сожалению. Давайте поставим sway.

Спойлер. Я ожидал, что будет штурм и превозмогание, а оказалось, что все встало просто на раз, как родное. И Wayland, и сам sway, и все родные апплеты от Mate.

Привет, Хабр! Мой путь в мире IT официально начался относительно недавно: в октябре 2025 года. До этого программирование вообще не выходило за рамки увлечений. Но однажды я решил испытать удачу и выйти на тропу приключений, после которой я уже не вернулся прежним...

В Японии порядка 140 предприятий, которым более 500 лет. Они пережили десятки войн, императоров, катастрофические землетрясения, цунами, депрессии, и так далее.

Эти сверхпрочные старинные предприятия называются «shinise». Исследования показывают, они, как правило, имеют одну общую характеристику: у них много наличных денег и почти нет долгов. Так они выдерживают столетия постоянных бедствий и черных лебедей.

Одна из самых частых и болезненных проблем в IT-командах — коммуникация с внутренними заказчиками. Со стороны разработки заказчики выглядят как генераторы сырых ТЗ, вечных правок и нереалистичных сроков. Со стороны бизнеса IT-специалисты кажутся «черным ящиком», который работает медленно, негибко и допускает ошибки.

До аналитики я три года руководил клиентским сервисом, где сформировал методологию работы с клиентами. Этот опыт помог мне найти ключ к гармонии: работать с заказчиками как с клиентами. Разница в том, что клиента мы стремимся не потерять, а значит, ведем себя более ответственно и проактивно.

В этой статье я собрал 11 принципов, которые помогут выстроить такую коммуникацию.

В любой более менее большой компании разработчиков вы найдете и человека на "окошках", и трушного линуксоида, и любителя лавандового рафа на альтернативном с яблоком на крышке ноутбука. И если человек с windows с большей вероятностью будет пользоваться WLS (подсистему linux), то вот человек с macOS попробует запустить проект у себя нативно, и это может привести к проблемам с совместимостями некоторых библиотек. Также, учитывая что с высокой долей вероятности ваше приложение будет крутиться в docker контейнере на сервере, не плохо было бы понимать то, как оно работает конкретно в нем. Поэтому зачастую решением которое подойдет всем для корректной разработки приложения без проблем с совместимостью, это запуск и отладка приложения на компьютере разработчики в независимости от установленной ОС прямо в docker. И так я описал мотивацию, перейдем же к настройке вышесказанного.

Для начала необходимо добавить установку библиотеки debugpy для работы отладчика в наше приложение. вы пожете добавить ее в общий фаил requirements.txt или добавить команду DockerFile.

Писать надо только тогда, когда не можешь не писать (С) Л.Н. Толстой

Задача, которая заняла бы 2 - 3 месяца классической разработки, была решена за 2 дня с помощью Claude и n8n. Автоматизировал валидацию конфигураций шкафов управления освещением, делегировав написание проверок самим инженерам через промпт-инжиниринг. Кейс про то, как AI меняет не только код, но и процессы.

Искусственный интеллект всё чаще воспринимают как универсальное решение: он обещает заменить людей, сократить издержки и ускорить бизнес-процессы. Но на практике компании всё чаще сталкиваются с обратным эффектом — ростом сложности, затрат и числа инцидентов.

Эта статья не против ИИ. Она про зрелость, ответственность и честный разговор о том, где ИИ действительно помогает бизнесу, а где делает больнее.

Когда я был разработчиком я задавался вопросами: как разделить код на классы? какие модули выделить?

Когда я стал архитектором я задавался вопросами: зачем же мы наплодили 200 микросервисов? стоит ли выделять новый или пора объединять?

Когда я стал руководителем я задавался вопросами: как разделить людей на команды разработки? стоит ли создавать новый отдел или расширить ответственность старого?

И всё это хотелось сделать оптимальным эффективным образом.

И я понял, что все эти вопросы сводятся к ряду единых принципов о том как делить, которые можно применять на любом уровне. И этим важным для себя осознанием, после 20 лет в разработке, я хочу поделиться.

Для любых компаний, создающих различного рода продукты, важными составляющими является аналитика и оценка того, как продукт развивается, как влиять на его развитие, управлять и отслеживать положительные и негативные изменения.

Быстрота изменений UX/UI дизайна, функциональности, влияния запусков конкурентов, предоставляющих аналогичный продукт, внешние факторы – все это отражается на метриках удержания и сроке пользования продуктом, а значит и на тех деньгах, которые продукт зарабатывает по P&L.

Человеческий мозг эволюционировал, чтобы отслеживать камни, инструменты, животных, лица - вещи с краями. Вещи, которые толкают другие вещи. Это служило нам верой и правдой сотни тысяч лет.

И большинство из нас всё ещё неправильно применяют эту интуицию к науке и технологиям, включая то, как мы думаем об ИИ. Даже высококвалифицированные инженеры делают то же самое: пытаются впихнуть квадратные колышки в круглые отверстия, а потом не могут понять ошибки в ИИ-системах, которые строят.

Это несоответствие между интуицией и наукой не ново.

Небольшая история из жизни — о реалистичности иллюзий и переживаний, которые наш мозг в состоянии генерировать «для внутреннего использования», и которая могла бы стать ещё одной главой фильма «Игры разума». А ещё — поводом основательно задуматься на темы более концептуальные. Например — попробуйте теперь доказать себе — вы не голограмма в своей же голове.

Мой молодой коллега Алексей часто бывал у дома у пожилого профессора психологии, помогал разбираться с архивами, набирал под диктовку статьи и книги на компьютере.
Однажды профессор запнулся у себя дома и несильно, но чувствительно ударился виском об мебель. Вроде бы, всё ограничилось лёгкой ссадиной и, вроде, без последствий.

Недели через полторы-две, когда случай уже забылся, Алексей приехал для продолжения работы над статьёй, профессор вошел в комнату и спросил:
— Зачем вы повесили сюда ковёр? Где вы его взяли?
— Какой ковёр?
— Ну, вот же, на стене висит.
— Тут нет ковра...
— Чего вы дурачите меня, вот же ковёр!

Для разрешения конфликта была призвана помощница по хозяйству и аспирант, который пришёл на консультацию. Все подтвердили — стена пуста, никакого ковра нет.
— Вы сговорились!

Профессор в гневе стал ощупывать стену, замолчал, сел в кресло и спокойным голосом продолжил диктовать очередную статью с того места, на котором он остановился в прошлый раз.

Тема ковра возникала ещё несколько раз в течении месяца, каждый раз возникал скандал. Все домашние и близкие были крайне обеспокоены ментальным здоровьем профессора. Подозрения возникали всякие, все они упирались в одно «но»: это была единственная странность, во всём остальном профессор сохранял великолепный — очень высокий! — интеллект, адекватность, тёплый уровень отношений с окружающими. И его очень едкий саркастический юмор — тоже был неизменным.

Привет, Хабр! Я Senior Angular Developer. И я хочу рассказать вам о своём недавнем опыте, который похож на сцену из киберпанк-триллера, но разворачивается в обычном интерфейсе hh.ru. Открываешь отклик на вакансию, а вместо формы для ввода текста — диалог с ИИ-ассистентом рекрутера. Он задаёт вопросы по стеку, проектам, архитектуре. И вместо того, чтобы в сотый раз пересказывать своё резюме, я сделал логичное, на мой взгляд, действие: поручил ответы своему ИИ-ассистенту.

Так началось интервью, где вопросы генерировала одна нейросеть, а ответы — другая. Моя роль свелась к модерации: «Да, это ок. Нет, исправь». Что из этого вышло, почему это одновременно эффективно и тревожно, и не пора ли нам всем смириться, что первый этап отбора теперь — это «Тьюринг-тест на максималках»? Разбираемся под катом.

Технологический сюрреализм: ATS умер, да здравствует AI-Screening?

Помните эпоху ATS (Applicant Tracking Systems), когда мы оптимизировали резюме под ключевые слова? Каменный век. Теперь системы эволюционировали: они не просто сканируют, они ведут диалог. «А использовали ли вы NgRx в продакшене?», «Опишите опыт реализации micro-frontend архитектуры» — вопросы генерируются на лету LLM, проанализировавшей описание вакансии.

Абсурд и ирония ситуации в её чистоте: две нейросети пытаются найти «мэтч» между двумя текстовыми файлами — вакансией и резюме. Человек-рекрутер и человек-соискатель вынесены за скобки первичного акта коммуникации. Мы наблюдаем рождение нового протокола взаимодействия на рынке труда: machine-to-machine screening.

Моя технарская душа порой просит какого-нибудь интересного челленджа: найти смартфон на городской свалке и привести его в идеальный вид, выкупить устройство из утиля после воды и восстановить материнскую плату, или просто купить что-то очень бюджетное и затем попытаться замоддить. Обычно я пишу только о тех девайсах, которые мне удалось отремонтировать собственными руками, однако сегодняшний смартфон настолько уникален, что я решил написать о нём отдельную статью даже несмотря на неудачную попытку ремонта...

Еще одна библиотека строк для Python? Легко - если у вас есть ИИ-помощник.

Рассказываю, что хотел сделать (действительно, ленивые строки), что получилось, как использовал ИИ, с какими проблемами столкнулся, какие выводы для себя сделал.

Есть несколько практик в разработке ПО, которые, с одной стороны, являются практически неотъемлемой частью пейзажа, а с другой - довольно уродливы, если вдуматься, и сильно вредят всем (некоторые вредят AI Code-ассистентам). В этом посте я хочу поныть про автоматические тесты - священную корову разработки ПО последних как минимум 10 лет. И особенно поныть про unit-тесты.

Эта статья проведёт вас через классический проект по машинному обучению — анализ датасета Titanic. Мы разберём полный цикл работы: от первоначального знакомства с данными и их очистки до построения и валидации первых предсказательных моделей. Вы узнаете, как преобразовывать категориальные признаки, создавать новые переменные, бороться с пропущенными значениями и оценивать качество моделей через ключевые метрики. На примере Random Forest и логистической регрессии наглядно показываю, как разные алгоритмы решают одну задачу и почему выбор модели зависит от поставленной цели.

Камера, о которой сегодня пойдёт речь — невероятно красивая, но за «хипстерской» внешностью скрывается довольно мощное устройство, готовое удивлять даже сейчас, в 2026 году. Отличные JPG-снимки без обработки, удобная работа с мануальной оптикой, рабочее мобильное приложение — поверьте, не каждая современная камера настолько душевная, как этот «Фуджи»!

Любой, кто пытался прикрутить LLM к реальному продакшену в узком домене (медицина, право, инженерия), проходил стадию отрицания: "Да ладно, сейчас промпт подкручу, RAG прикручу — и полетит".

Не полетит.