Дарья Лоскутова

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

Когда люди говорят, что интернет сломался, чаще всего проблема оказывается не в кабелях, не в серверах и даже не у провайдера. Очень часто виноват DNS система, о существовании которой большинство пользователе вообще не задумывается. Но что будет, если представить невероятную ситуацию: весь DNS в мире перестанет работать на целые сутки? На первый взгляд может показаться, что ничего страшного не произойдет. Интернет же никуда не денется. Провода останутся на месте, серверы продолжат работать, дата-центры не отключатся от электричества. Однако реальность окажется намного интереснее. DNS можно сравнить с телефонной книгой интернета...

Переезд на новую базу данных или смену архиектуры в режиме zero-downtime часто сравнивают с заменой колёс у автомобиля на полной скорости. Однако на практике, когда за плечами годы управления архитектурными изменениями и координации крупных релизов, этот процесс превращается из зоны повышенного риска в предсказуемую инженерную задачу. Главный вывод, к которому приходишь после десятков успешного запущенных систем. Залог отсутствия даунтайма - это не столько сложный код, сколько жёсткая последовательность этапов и готовность инфраструктуры к компромиссам. Ключевой принцип безопасной миграции заключается в том, что старая и новая схема данных обязаны сосуществовать в продакшене параллельно...

Почему люди устали от постоянных обновлений интерфейсов Еще лет десять назад обновление приложения или сайта воспринималось как что-то хорошее. Если выходил новый дизайн значит, сервис развивается, становится современнее, удобнее, быстрее. Люди ждали изменений, обсуждали их, изучали новые функции. Сейчас реакция все чаще другая: Опять всё поменяли, Где теперь нужная кнопка?, Зачем ломать то, что работало?. И я прекрасно понимаю эту усталость. Потому что современный интерфейс все чаще перестает быть инструментом для человека и превращается в бесконечный эксперимент над вниманием пользователя. Интерфейсы больше не успевают устояться Раньше дизайн программ менялся медленно...

Постоянно мне задают вопрос, за что программистам так много платят. Хочу раз и навсегда разрешить этот вопрос. Нам платят не за тыкание по кнопочкам, а за бизнес-велью и колоссальную ответственность. Современный мир полностью держится на софте, и если условный банк или сервис доставки ляжет, бизнес потеряет миллионы. И именно айтишниr в три ночи будет с красными глазами разгребать этот ад. Наша зарплата - это плата за умение решать критические проблемы и за то, что мы берём этот удар на себя. К тому же, на рынке дикий дефицит мозгов, а технологии меняются с бешеной скоростью. Нельзя один раз выучить язык разработки и расслабиться...

Автоматизация CI/CD похожа на уборку в квартире, кажется, что проще переступать через хлам, чем разложить всё по полочкам, но в какой то момент ты понимаешь, что больше не можешь найти в этом хаосе даже ключи от релиза. В моей практике был период, когда деплой напоминал сакральный ритуал, где каждый шаг сопровождался молитвами и ручной проверкой конфигов. Мы решили, что хватит это терпеть, и начали выстраивать пайплайны так, чтобы человеческий фактор перестал быть главной угрозой стабильной системы. Переход на полную автоматизацию изменил не только скорость доставки кода, но и саму культуру внутри команды...

Обычно, когда сервис тормозит, все бегут переписывать код или докупать память. Я же пошла по пути цифр. Имели Python-микросервис, задержки по 800 мс и кучу споров в команде. Вместо гадания я достала py-spy и построила flame graph. Выяснилось невероятное, 60% времени тратилось не на бизнес логику, а на парсинг тяжёлых JSON стандартной библиотекой. Она просто не справлялась с объёмом. Решение - замена на orjson. Скорость сразу выросла, но это было только начало. Вторым шагом я подключила scalene. Он подсветил тяжёлую синхронную функцию внутри асинхронного цикла asyncio. Она блокировала весь поток на 50 мс, заставляя остальные запросы стоять в очереди...

Тема, которая уже пару лет не выходит из обсуждений: ИИ скоро заменит программистов. Звучит громко, местами даже тревожно. Особенно если ты сам пишешь код и видишь, как инструменты вроде Copilot, ChatGPT и других систем начинают уверенно генерировать функции, тесты и даже целые модули. Сегодня искусственный интеллект действительно может: Для начинающего разработчика это вообще выглядит как магия: написал задачу, получил готовый код. Но есть важный момент: ИИ работает на основе того, что уже было создано людьми. Он не понимает задачу в человеческом смысле. Он предсказывает наиболее вероятное продолжение текста и кода, опираясь на огромные массивы данных...