tgindex

Работая в айтишечке

описание

Канал о том, как эффективно работать в IT: простые объяснения технических вещей, лайфхаки, лучшие практики и полезные инструменты для повседневных задач. Автор: @Shevtsoff

← к каналу@workinginit
1 468
подписчиков
Охват к подписчикам
61,3%
ERR
Реакции к просмотрам
1,52%
901 на 50 постов
Пересылки к просмотрам
2,21%
1 311
Постов в день
0,4
всего 68

Где отзываются чаще

доля реакций к просмотрам
  • 14 авг.Пятничный мем #memes6,73%
  • 14 авг.без подписи4,85%
  • 12 авг.без подписи3,96%
  • 22 янв.☕️ Букмарклеты: мощные кнопки в вашей панели закладок Вы когда-нибудь сталкивались с ситуацией, когда нужно постоянно делать одни и те же действия на веб-страницах? Копировать информацию из разных мест, преобразовывать текст или скрывать чувствительные данные перед скриншотом? Сегодня расскажу про букмарклеты, которые решат эти проблемы за один клик. Букмарклет (bookmarklet) — это скрипт на JavaScript, сохраненный как обычная закладка в браузере. Вместо URL-адреса в нем хранится код, который выполняется на текущей странице при клике. 🔥 Мой кейс Нужно было собирать данные с разных страниц сайта. Написал букмарклет через LLM: — Закинул HTML страницы — Описал, что хочу на выходе — Модель сама нашла нужные элементы и сгенерировала код — Теперь за клик копирую отформатированный текст в буфер! 🛡 Ещё кейс (см. скрины) Букмарклет для "засекречивания" цифр в дашбордах. Перед скриншотом кликаю — все числа заменяются на █. Идеально для презентаций! Вот код (можете сохранить себе): javascript:(function(){function replaceDigitsInNode(node) {if (node.nodeType === Node.TEXT_NODE) {const originalText = node.textContent;const modifiedText = originalText.replace(/\d/g, '█');if (originalText !== modifiedText) {const newNode = document.createTextNode(modifiedText);node.parentNode.replaceChild(newNode, node);}}}function processElement(element) {const walker = document.createTreeWalker(element, NodeFilter.SHOW_TEXT, null, false);const nodesToReplace = [];let node;while (node = walker.nextNode()) {nodesToReplace.push(node);}nodesToReplace.forEach(replaceDigitsInNode);}processElement(document.body);})(); 💡 Как создать свой? 1. Опишите задачу LLM (например: "Напиши код букмарклета в одну строку, который..."). Идеально если ещё дадите модели скачанную html-страницу (Ctrl + s) 2. Скопируйте готовый код из javascript: (() => { // Your code here! })(); 3. Создайте закладку, вставьте код в URL — готово! 🚀 Что ещё можно — Скрывать блоки рекламы — Переключать тёмную тему — Сохранять выделенный текст в Notion/Telegram — Анализировать цены на маркетплейсах — что угодно, загляните сюда чтобы попробовать 💬 Попробуйте! Самые унылые рутинные задачи в браузере решаются одной закладкой. А какие моменты вас бесит больше всего? Может, придумаем букмарклет прямо в комментах? 😉 P.S. Спасибо Руслану, что рассказал про букмарклеты в своём канале) 👀 Смотрите также — What are Bookmarklets? How to Use — 15 Useful Bookmarklets for Web Devs — Набор букмарклетов для аудита доступности a11y (чтобы сохранить себе, перетащите ссылку в закладки) #lifehacks #tools #llm #dev3,86%
  • 5 июн.Пятничный мем #memes3,75%
  • 5 нояб.без подписи3,66%
  • 25 авг. 2025 г.без подписи3,64%
  • 14 янв.☕️ Миграция между системами Сколько лет работаю в ИТ, постоянно сталкиваюсь с необходимостью "закапывания" (sunsetting) изживших себя сервисов и миграции на новые. Я столько раз "хоронил" старые сервисы, что уже чувствую себя похоронным агентом цифровых систем 😄 Каждый раз казалось, что это последняя миграция в моей жизни, но рынок не стоит на месте — технологии устаревают, требования меняются, и снова приходится собирать команду для "переезда". Почему это всегда больно? Потому что за каждой системой стоят реальные люди, привыкшие к определенному интерфейсу, горячим клавишам, автоматизациям. Потому что в старых сервисах живет наша бизнес-память — данные, история взаимодействий, наработанные процессы. И когда приходится говорить команде: "С завтрашнего месяца мы переходим на новую платформу", внутри всегда тревога: получится ли сделать это без потерь и слез? В этих карточках я попытался собрать реальные этапы и работы, с которыми неизбежно столкнется любой, кто берется за миграцию. Это то, что я выстрадал на своих проектах, проверил на ошибках, и что сегодня помогает мне планировать такие переходы с минимальным стрессом для пользователей и максимальной сохранностью данных. Сохраняйте себе — пригодится, когда ваш руководитель скажет: "Нам нужно переехать на новую систему до конца квартала".😉 P.S. Решил написать этот пост, т.к. в работе как раз есть ещё один кандидат на закапывание 🪦 #lifehacks #howto #guides3,55%
  • 9 апр.☕️ LLM Wiki от Карпаты Андрей Карпаты (ex-Tesla AI, ex-OpenAI) опубликовал паттерн, который кажется очевидным — но почему-то так никто не делал. И все паблики прорвало - пишут, что это бомба! )) Обычно как: загружаешь документы в ChatGPT, NotebookLM или любой RAG — модель каждый раз заново ищет куски, склеивает ответ и забывает. Завтра всё по новой. Ничего не накапливается. Идея Карпапты простая: пусть LLM не ищет по документам, а строит из них вики. Добавил новый источник → агент прочитал, написал саммари, обновил связанные страницы, пометил противоречия. Один документ может затронуть 10-15 страниц. В такой системе выделяется три слоя: — Сырые источники (неизменяемые) - raw — Вики (markdown, который LLM пишет и обновляет) — Схема (правила для агента — как вести вики) Почему работает Люди бросают вики, потому что их обслуживание — боль. Обновить ссылки, актуализировать саммари, пометить что устарело — никто не хочет этим заниматься. А LLM не устаёт. Человек направляет и думает. LLM ведёт всю рутину. Как сделать у себя Нужна папка с markdown + любой агент (Claude Code, Qwen Code, Codex) + файл с правилами. Никакой инфраструктуры. Я просто взял и попросил агента Давай попробуем применить предложенные в данном документе концепции к нашему проекту https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f Работает, черт возьми! Рекомендую) 👀 Смотрите также – Andrej Karpathy Just 10x’d Everyone’s Claude Code – Karpathy Just Replaced RAG With Obsidian + Claude Code #ai #llm #wiki3,46%
  • 30 мар.без подписи3,40%
  • 18 июн.☕️ Кем станет аналитик, когда ИИ научился писать SQL Сейчас модно рассуждать на тему того, как кого-то заменит ИИ. Решил посмотреть на роль аналитиков - так как они являются основными пользователями моих продуктов. Начнем с главного — заменят не аналитика — заменят кусок работы: накидать черновик запроса, собрать табличку, поймать аномалию глазами, нарисовать первый график. Это ИИ уже делает быстрее аналитиков. Но профессия от этого не исчезает. У неё смещается центр тяжести. Раньше единицей работы был ответ на вопрос. Теперь — система, которая отвечает на вопросы сама. Вот как это выглядит на практике. Сегодня к аналитику приходят с «почему просела конверсия?», он лезет в данные, считает, объясняет. Завтра первым на этот вопрос ответит ассистент. И работа аналитиков будет — не ответить, а сделать так, чтобы ИИ ответил правильно: взял ту метрику, что нужно, не перепутал корреляцию с причиной, честно показал ограничения и сам поднял руку, когда вопрос слишком рискованный для автоответа. Аналитик перестанет быть тем, кто отвечает на каждый вопрос. Он станет тем, кто проектирует смысл: как считается метрика, что такое «активный пользователь», какие разрезы вообще допустимы, где проходит граница между «ИИ ответит сам» и «тут нужен человек». Как, по-моему, будет выглядеть рабочий день: — не «закрыть 10 ad hoc-запросов», а посмотреть, на чём ассистент путается, и починить это в корне — не «сделать ещё один разрез по просьбе бизнеса», а превратить повторяющийся вопрос в готовый сценарий, который дальше крутится без вас — не «построить дашборд», а владеть определениями метрик так, чтобы человек, дашборд и ИИ понимали их одинаково И вот тут интересное. Чем дешевле сгенерировать ответ, тем дороже за него отвечать. Раньше кривую цифру видел один заказчик. Теперь кривую трактовку ассистент разошлёт сразу сотне людей. Поэтому самый ценный навык — не «написать запрос», а «понять, что ответ неверный, хотя выглядит он чертовски убедительно». Что из этого следует: — SQL не умирает, меняется вопрос на собесе. Было: «умеешь писать?». Стало: «умеешь увидеть, где ИИ написал ерунду?» — дорожают не технические скиллы, а постановка правильного вопроса, проектирование метрик, причинно-следственное мышление и умение довести анализ до решения, а не до графика — появляются новые роли: владелец метрик, куратор качества ответов ассистента, decision partner — тот, кто помогает бизнесу не «посмотреть данные», а выбрать действие и проверить, что из него вышло Аналитик будущего меньше похож на того, кто выдаёт отчёты по запросу, и больше — на того, кто строит и поддерживает доверие к данным. ИИ забирает скорость и черновики. За человеком остаётся смысл, проверка и ответственность за решение. И это, честно говоря, работа поинтереснее, чем десятая выгрузка за день. #thoughts #ai #llm3,20%
  • 17 апр.☕️ Как управлять контекстом AI-агентов Сейчас в Авито мы делаем супер-пупер-мега AI-first аналитическую платформу, активно внедряем агентский воркфлоу во все инструменты. И я в последние недели закопался в тему того «как сделать AI-агентов полезными, как передавать в них контекст». Посмотрел, как эту задачу решают лидеры — Hex, Databricks Genie, Snowflake Cortex Analyst, Notion AI, Dust, плюс системы памяти Graphiti/Zep, Mem0, Letta. Почитал, попытался разложить по полочкам. В 6 карточках разложил слои и приёмы — там всё коротко (👀 см. карточки ↑). Проблема одна. Голый LLM про вашу компанию ничего не знает. Он не в курсе, что у вас за DWH, какие метрики считаются, что решил лид вчера в Slack, как устроен деплой. Практика такая: без доменного контекста агенты выдают около 25%(если не больше) откровенно неверных ответов — и это не про качество модели, а про нехватку специфики. Что делают все "лидеры" одинаково: — Контекст подаётся слоями: компания → проект → пользователь. У всех минимум три уровня. У агентов для разработки слой проекта хранится в git, у остальных — в базе данных — Ядро знаний — всегда при агенте, объёмные документы — только когда нужны. Никто не заливает всё в промпт целиком — Единый словарь метрик — обязателен. Snowflake Cortex, ThoughtSpot, Tableau Pulse — все строят такой слой. Без него модель придумывает SQL из головы — Нужные правила подтягиваются автоматически — по теме вопроса, по типу файла, по связям. Cursor, Claude Code, Continue — все делают так, чтобы не загружать всё вручную — Контекст курируют, а не пишут раз и навсегда. Проверенные эталоны, оценки 👍👎, автоматическое запоминание. Это живая база знаний — Формулы побеждают прозу. Genie прямо говорит: готовый SQL-сниппет лучше текстового правила, которое можно понять по-разному — Агент уважает права доступа. Glean, Dust, Notion AI не отдадут документ, к которому у вас нет доступа. В крупных компаниях без этого никак Как начать у себя — Опишите слои от компании до текущего диалога. Под каждый — где лежит правда и кто за неё отвечает — Правила функции и продукта — markdown-файлы в git. По образцу CLAUDE.md или Cursor rules. Никаких баз данных на старте — Метрики домена — словарь в YAML плюс гайды, которые подтягиваются по описанию — Историю изменений храните только там, где реально нужно «было/стало» — например, как менялся расчёт метрики. Для остального хватит истории коммитов — Сразу закладывайте кураторов и голосование. Без этого база устареет за месяц Ключевое. Шесть слоёв — необходимый минимум для платформы на уровне всей компании. Меньше — потеряете либо разницу между функциями (HR и аналитика — это разные миры), либо разницу между продуктами (у каждого свои правила), либо домен данных (где живут метрики). Начинать поэтапно: первый результат за 4 недели, полная платформа — два квартала с одной командой. #ai #agents #llm #vibecoding2,87%