#prompt
I used these Perplexity and Gemini prompts and analyzed 10,000+ YouTube Videos in 24 hours. Here's the knowledge extraction system that changed how I learn forever
We all have a YouTube "Watch Later" list that's a graveyard of good intentions. That 2-hour lecture, that 30-minute tutorial, that brilliant deep-dive podcast—all packed with knowledge you want, but you just don't have the time.
What if you could stop *watching* and start *knowing*? What if you could extract the core ideas, secret strategies, and "aha" moments from any video in about 60 seconds?
This guide will show you how. We'll use AI tools like Perplexity and Gemini to not only analyze single videos but to deconstruct entire YouTube channels for rapid learning, creator research, or competitive intelligence. A simple "summarize this" is for beginners. We're going to teach the AI to think like a strategic analyst.
# The "Super-Prompts" for Single Video Analysis
This is your foundation. Choose your tool, grab the corresponding prompt, and get a strategic breakdown of any video in seconds.
# Option A: The Perplexity "Research Analyst" Prompt
Best for: Deep, multi-source analysis that pulls context from the creator's other work across the web.
The 60-Second Method:
1. Go to perplexity.ai.
2. Copy the YouTube video URL.
3. Paste the following prompt and your link.
Perplexity Super-Prompt
# Option B: The Gemini "Strategic Analyst" Prompt
Best for: Fluent, structured analysis that leverages Google's native YouTube integration for a deep dive into the video itself.
The 60-Second Method:
1. Go to gemini.google.com.
2. Go to Settings \> Extensions and ensure the YouTube extension is enabled.
3. Copy the YouTube video URL.
4. Paste the following prompt and your link.
Gemini Super-Prompt
The Gemini prompt is my favorite for analyzing videos in 60 seconds and really pulling out the key points. Saves so many hours I don't have to watch videos where people often have a few good points but go on and on about a lot of nothing.
I used these Perplexity and Gemini prompts and analyzed 10,000+ YouTube Videos in 24 hours. Here's the knowledge extraction system that changed how I learn forever
We all have a YouTube "Watch Later" list that's a graveyard of good intentions. That 2-hour lecture, that 30-minute tutorial, that brilliant deep-dive podcast—all packed with knowledge you want, but you just don't have the time.
What if you could stop *watching* and start *knowing*? What if you could extract the core ideas, secret strategies, and "aha" moments from any video in about 60 seconds?
This guide will show you how. We'll use AI tools like Perplexity and Gemini to not only analyze single videos but to deconstruct entire YouTube channels for rapid learning, creator research, or competitive intelligence. A simple "summarize this" is for beginners. We're going to teach the AI to think like a strategic analyst.
# The "Super-Prompts" for Single Video Analysis
This is your foundation. Choose your tool, grab the corresponding prompt, and get a strategic breakdown of any video in seconds.
# Option A: The Perplexity "Research Analyst" Prompt
Best for: Deep, multi-source analysis that pulls context from the creator's other work across the web.
The 60-Second Method:
1. Go to perplexity.ai.
2. Copy the YouTube video URL.
3. Paste the following prompt and your link.
Perplexity Super-Prompt
Act as an expert research analyst and content strategist. Your goal is to deconstruct the provided YouTube video to extract its fundamental components, core message, and strategic elements. From this YouTube video, perform the following analysis:
1. **Hierarchical Outline:** Generate a detailed, hierarchical outline of the video's structure with timestamps (HH:MM:SS).
2. **Core Insights:** Distill the 5-7 most critical insights or "aha" moments.
3. **The Hook:** Quote the exact hook from the first 30 seconds and explain the technique used (e.g., poses a question, states a shocking fact).
4. **Actionable Takeaways:** List the most important, actionable steps a viewer should implement.
5. **Holistic Synthesis:** Briefly search for the creator's other work (blogs, interviews) on this topic and add 1-2 sentences of context. Does this video expand on or contradict their usual perspective?
Analyze this video: [PASTE YOUR YOUTUBE VIDEO LINK HERE]
# Option B: The Gemini "Strategic Analyst" Prompt
Best for: Fluent, structured analysis that leverages Google's native YouTube integration for a deep dive into the video itself.
The 60-Second Method:
1. Go to gemini.google.com.
2. Go to Settings \> Extensions and ensure the YouTube extension is enabled.
3. Copy the YouTube video URL.
4. Paste the following prompt and your link.
Gemini Super-Prompt
Act as a world-class strategic analyst using your native YouTube extension. Your analysis should be deep, insightful, and structured for clarity.
For the video linked below, please provide the following:
1. **The Core Thesis:** In a single, concise sentence, what is the absolute central argument of this video?
2. **Key Pillars of Argument:** Present the 3-5 main arguments that support the core thesis.
3. **The Hook Deconstructed:** Quote the hook from the first 30 seconds and explain the psychological trigger it uses (e.g., "Creates an information gap," "Challenges a common belief").
4. **Most Tweetable Moment:** Identify the single most powerful, shareable quote from the video and present it as a blockquote.
5. **Audience & Purpose:** Describe the target audience and the primary goal the creator likely had (e.g., "Educate beginners," "Build brand affinity").
Analyze this video: [PASTE YOUR YOUTUBE VIDEO LINK HERE]
The Gemini prompt is my favorite for analyzing videos in 60 seconds and really pulling out the key points. Saves so many hours I don't have to watch videos where people often have a few good points but go on and on about a lot of nothing.
I then built an app with Lovable, Supabase and the Gemini API and started analyzing entire YT channels to understand the best videos, what content gets the most views and likes, and I also studied the viral hooks people use in the first 30 seconds of a video that makes or breaks the video engagement.
I was really able to learn quite a lot really fast. From studying 100 channels about AI I learned that the CEO of NVIDIA's keynote in March 2025 was the most watched AI video in YouTub with 37 million views.
I was really able to learn quite a lot really fast. From studying 100 channels about AI I learned that the CEO of NVIDIA's keynote in March 2025 was the most watched AI video in YouTub with 37 million views.
Forwarded from Ruslan Senatorov | Реверс-Инжиниринг Data Science
#prompt #prompthelp #promptFAQ
В эпоху вайб-кодинга, нужно уметь хорошо промптить, чтобы модель делала что ты хочешь.
Таблица основных промптов🔥
⏺️ Подсказки для инженеров (222+ подсказки)
⏺️ Подсказки для создания контента (70 подсказок)
⏺️ Подсказки для маркетологов (150 подсказок)
⏺️ Подсказки для операторов (105 подсказок)
⏺️ Подсказки для продавцов (90 подсказок)
⏺️ Подсказки для поиска работы (50 подсказок)
⏺️ ChatGPT в образовании (110+ подсказок)
⏺️ Подсказки для отдела кадров (90 подсказок)
⏺️ Подсказки Excel (20 подсказок)
⏺️ Подсказка для терапевтов (20 подсказок)
⏺️ Подсказка для журналистов (20 подсказок)
⏺️ Подсказка для бухгалтеров (20 подсказок)
⏺️ Подсказки для финансовых аналитиков (20 подсказок)
⏺️ Подсказки для юристов (20 подсказок)
⏺️ Подсказки для дизайнеров сайтов (20 подсказок)
⏺️ Подсказки для графических дизайнеров (25 подсказок)
⏺️ Подсказки для предпринимателей (25 подсказок)
⏺️ Подсказки для авторов бестселлеров (25 подсказок)
⏺️ Подсказки для коммерческих архитекторов (25 подсказок)
⏺️ Подсказки для тренера по менталитету (20 подсказок)
⏺️ Подсказки для тренера по отношениям (20 подсказок)
➡️ Бесплатный курс по работе с chatGPT и LLM
Ютуб | Школа Data Science | Чат | Live
В эпоху вайб-кодинга, нужно уметь хорошо промптить, чтобы модель делала что ты хочешь.
Таблица основных промптов
Ютуб | Школа Data Science | Чат | Live
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всеволод Викулин | AI разбор
Продолжаем грызть науку LLM-строения.
В прошлых 5 публикациях мы поняли, из каких кубиков состоит LLM-система. Сейчас пришло время из них что-то собирать.
А как собирать?
Тема 6. Этапы LLM-проекта
Я делю разработку на 4 этапа:
1) Бизнес постановка
2) Создание прототипа
3) Упрощение протототипа
4) Деплой системы и мониторинг качества
Бизнес постановка
Нам нужны частотные и дорогие задачи. Важно, чтобы была толерантность к ошибкам — близкое к 100% качество у LLM бывает разве что в простой классификации. Классические примеры:
- Бот поддержки клиентов — большой объем, средняя толерантность, средняя стоимость операции
- Copilot для разработчика — средний объем, высокая толерантность (copilot же), высокая стоимость операции
- Автоматизация документооборота— средний объем, средняя толерантность, средняя стоимость операции
Создание прототипа
Проблема подавляющего большинства ИИ-проектов: когда начинается плотная разработка никто не понимает, что надо сделать. И начинают выдумывать на ходу, когда надо не выдумывать, а надо уже делать. Подумать надо было заранее. И все ваше подумывание отразить в прототипе.
Цель прототипа: получить продуктовый ориентир, что наша система должна уметь. При этом там могут быть какие угодно большие модели, он может работать час на запрос и ломаться от промпт-инъекций. Не ругайте его. Он исправится на следующем этапе. Признак успеха этого этапа: человек, который делал бизнес постановку скажет: "вот сделайте такое, только быстро, и я буду счастлив".
Важно: прототип могут и должны собирать люди, которые участвовали в этапе бизнес постановки. Иначе у вас получится опять сферическая LLM в вакууме. Про это читайте пост.
Упрощение протототипа
Здесь сильные технические люди крутят-вертят LLM. Чтобы прототип не стоил, как запуск ракеты Илона Маска.
Большое разнообразие различных вариантов:
1) Дистилляция. Большие модели нужно сжать в модели поменьше. Качество может теряться, но если мы решаем конкретную узкую задачу, должно упасть не сильно. Вот тут подробный разбор метода.
2) Дообучение. Можно не дистиллировать, а просто взять модель поменьше. Но тогда придется их покрутить, так как они справляться будут хуже. Здесь приходит на помощь дообучение (особенно Reinforcement Learning). Вот тут много примеров по дообучению разных LLM разными методами.
3) Работа с контекстом окном. Убирание лишнего из контекста, суммаризация (я пока не устал шутить про контекст-инженера)
4) Оптимизации. Тут отдельный мир: размер батча/квантизация/спекулятивный декодинг. Про это есть отдельная методичка в этом посте.
И еще куча-куча всего. Тут живет мощная LLM-инженерия.
Деплой и мониторинг качества
Здесь происходит классическая разработка. Пишется сервис, в котором работает наша эффективная система. Самое важное: нам нужно контролировать качество этого сервиса. При чем не разово, а постоянно. Зачем?
Во-первых, мы могли где-то набагать при написании сервиса. Во-вторых, мы можем набагать попозже. И еще есть distribution shift, когда пользователи по-другому начинаются пользоваться системой, и она начинает хуже работать. Про это неплохо написано в моем любимом учебнике по DL.
Литература для обязательного изучения
- Довольно понятная (мне) моя статья. Часть материала пересекается с постом.
- Гайд, как быстро улучшать AI-продукты
- Очень крутая статья про мониторинг и distribution shift
Как всегда, жду вопросы в комментариях или в личных сообщениях.
Дальше будем разбирать методы оценки качества для LLM, готовьтесь.
#llm_system_design
В прошлых 5 публикациях мы поняли, из каких кубиков состоит LLM-система. Сейчас пришло время из них что-то собирать.
А как собирать?
Тема 6. Этапы LLM-проекта
Я делю разработку на 4 этапа:
1) Бизнес постановка
2) Создание прототипа
3) Упрощение протототипа
4) Деплой системы и мониторинг качества
Бизнес постановка
Нам нужны частотные и дорогие задачи. Важно, чтобы была толерантность к ошибкам — близкое к 100% качество у LLM бывает разве что в простой классификации. Классические примеры:
- Бот поддержки клиентов — большой объем, средняя толерантность, средняя стоимость операции
- Copilot для разработчика — средний объем, высокая толерантность (copilot же), высокая стоимость операции
- Автоматизация документооборота— средний объем, средняя толерантность, средняя стоимость операции
Создание прототипа
Проблема подавляющего большинства ИИ-проектов: когда начинается плотная разработка никто не понимает, что надо сделать. И начинают выдумывать на ходу, когда надо не выдумывать, а надо уже делать. Подумать надо было заранее. И все ваше подумывание отразить в прототипе.
Цель прототипа: получить продуктовый ориентир, что наша система должна уметь. При этом там могут быть какие угодно большие модели, он может работать час на запрос и ломаться от промпт-инъекций. Не ругайте его. Он исправится на следующем этапе. Признак успеха этого этапа: человек, который делал бизнес постановку скажет: "вот сделайте такое, только быстро, и я буду счастлив".
Важно: прототип могут и должны собирать люди, которые участвовали в этапе бизнес постановки. Иначе у вас получится опять сферическая LLM в вакууме. Про это читайте пост.
Упрощение протототипа
Здесь сильные технические люди крутят-вертят LLM. Чтобы прототип не стоил, как запуск ракеты Илона Маска.
Большое разнообразие различных вариантов:
1) Дистилляция. Большие модели нужно сжать в модели поменьше. Качество может теряться, но если мы решаем конкретную узкую задачу, должно упасть не сильно. Вот тут подробный разбор метода.
2) Дообучение. Можно не дистиллировать, а просто взять модель поменьше. Но тогда придется их покрутить, так как они справляться будут хуже. Здесь приходит на помощь дообучение (особенно Reinforcement Learning). Вот тут много примеров по дообучению разных LLM разными методами.
3) Работа с контекстом окном. Убирание лишнего из контекста, суммаризация (я пока не устал шутить про контекст-инженера)
4) Оптимизации. Тут отдельный мир: размер батча/квантизация/спекулятивный декодинг. Про это есть отдельная методичка в этом посте.
И еще куча-куча всего. Тут живет мощная LLM-инженерия.
Деплой и мониторинг качества
Здесь происходит классическая разработка. Пишется сервис, в котором работает наша эффективная система. Самое важное: нам нужно контролировать качество этого сервиса. При чем не разово, а постоянно. Зачем?
Во-первых, мы могли где-то набагать при написании сервиса. Во-вторых, мы можем набагать попозже. И еще есть distribution shift, когда пользователи по-другому начинаются пользоваться системой, и она начинает хуже работать. Про это неплохо написано в моем любимом учебнике по DL.
Литература для обязательного изучения
- Довольно понятная (мне) моя статья. Часть материала пересекается с постом.
- Гайд, как быстро улучшать AI-продукты
- Очень крутая статья про мониторинг и distribution shift
Как всегда, жду вопросы в комментариях или в личных сообщениях.
Дальше будем разбирать методы оценки качества для LLM, готовьтесь.
#llm_system_design
Forwarded from Daniilak — Канал
Журнал Inc. Russia составил карту российских ИИ-сервисов. Карта свежая, продукты представлены в 15 категориях — от разработки кода и RAG до генерации презентаций и HR-инструментов
incrussia.ru
Карта российского ИИ - Инк.
Рубрика Карта российского ИИ.
Forwarded from Daniilak — Канал
Новое - это хорошо забытое старое. Вероятно, скоро появится во всех ИИ-IDE — спецификации
Идея спецификаций простая: мы не ставим нейросети общую задачу «сделай хорошо», а просим её сначала написать спецификацию проекта (
Такой подход задаст новый вектор в вайб-кодинге
Идея спецификаций простая: мы не ставим нейросети общую задачу «сделай хорошо», а просим её сначала написать спецификацию проекта (
requirements.md), потом — технические решения (design.md) и, наконец, на её основе — план (tasks.md), как именно она собирается эти требования выполнять. Это — развитие стандартного промптового приёма «цепочка мыслей»Такой подход задаст новый вектор в вайб-кодинге
Forwarded from что-то на инженерном
Пылесосим таблицы в Greenplum
Замечали ли вы когда-нибудь, что ваша таблица выросла с 10 ГБ до 30 ГБ, но при этом количество строк увеличилось всего на 20%? Или ещё хуже, после массового удаления половины данных таблица как занимала 100 ГБ, так и продолжает занимать?
Если знакомо, то добро пожаловать в мир «призрачных» строк и раздувшихся таблиц.
В чём суть проблемы?
Из-за MVCC (многоверсионного управления параллелизмом) при UPDATE и DELETE старые версии строк физически не удаляются, а помечаются как «мёртвые». Со временем таблицы раздуваются, производительность падает. Чтобы это исправить, обращаемся к VACUUM.
🟣 VACUUM - это SQL-команда для «сборки мусора», унаследованная Greenplum от PostgreSQL. Она освобождает место, занимаемое удалёнными или устаревшими строками. Есть два основных типа вакуумирования:
➡️ VACUUM (обычный): просто освобождает занятое место для повторного использования, работает быстро, может выполняться параллельно с другими операциями.
➡️ VACUUM FULL: полностью переписывает таблицу, реально удаляя мусор и уменьшая физический размер файла таблицы, но требует эксклюзивного доступа и работает заметно дольше.
◀️ Как запустить VACUUM
Ключевые особенности:
⭐️ Выполняется параллельно на всех сегментах кластера
⭐️ Обычный VACUUM не блокирует таблицу
⭐️ VACUUM FULL блокирует и физически перезаписывает файлы
⭐️ Не работает с external/foreign таблицами
⭐️ Для таблиц append-only необходимо свободное место на диске ≥ размера самого большого сегмента
Когда запускать VACUUM
🟣 После массовых DELETE/UPDATE операций
🟣 Для таблиц с высокой частотой изменений
🟣 Регулярно для системных каталогов
🟣 После значительных изменений данных (для обновления статистики)
Избегать:
🟣 VACUUM FULL в пиковые часы
🟣 Частое использование VACUUM FULL (только в критических случаях)
🟣 Запуск на огромных таблицах без окна обслуживания
▪️ Важно: VACUUM FULL требует двойного объёма свободного места, так как создаёт полную копию таблицы. Альтернативное решение: удалить старую таблицу и заново создать ее.
Что в итоге?
VACUUM - критически важная операция для поддержания производительности Greenplum. Регулярное выполнение предотвращает деградацию системы и избавляет от аварийных ситуаций.
➡️ Читать подробнее: Сборка мусора и очистка таблиц в Greenplum с командой VACUUM
©️ что-то на инженерном
Замечали ли вы когда-нибудь, что ваша таблица выросла с 10 ГБ до 30 ГБ, но при этом количество строк увеличилось всего на 20%? Или ещё хуже, после массового удаления половины данных таблица как занимала 100 ГБ, так и продолжает занимать?
Если знакомо, то добро пожаловать в мир «призрачных» строк и раздувшихся таблиц.
В чём суть проблемы?
Из-за MVCC (многоверсионного управления параллелизмом) при UPDATE и DELETE старые версии строк физически не удаляются, а помечаются как «мёртвые». Со временем таблицы раздуваются, производительность падает. Чтобы это исправить, обращаемся к VACUUM.
-- Обычная очистка (без блокировки)
VACUUM my_table;
-- Полная очистка (с блокировкой, возвращает место ОС)
VACUUM FULL my_table;
-- С обновлением статистики
VACUUM ANALYZE my_table;
Ключевые особенности:
Когда запускать VACUUM
Избегать:
В Greenplum нет глобального автоматического вакуума для пользовательских таблиц, поэтому нужно планировать и запускать его вручную. Для системных таблиц autovacuum работает автоматически.
Что в итоге?
VACUUM - критически важная операция для поддержания производительности Greenplum. Регулярное выполнение предотвращает деградацию системы и избавляет от аварийных ситуаций.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Находки в опенсорсе
Снимок экрана 2025-07-25 в 16.38.01.png
454.8 KB
Делаем бесплатный курс по vscode?
Довольно часто последнее время наблюдаю, как программируют другие люди. На собесах в своем окружении, в паре со мной, на ютюбе и тд. И вот что я замечаю. Очень много людей страдает от базовых вещей, которые можно сделать простыми и удобными. Я хочу помочь.
Тем более видосы с нарезкой моего подкаста на данную тему с @t0digital собрали много обсуждений и даже возмущений. А значит – тема горячая :)
Будем делать из второй картинки третью.
О чем поговорим?
- Почему DX важен?
- Почему vscode, а не vim / pycharm / emacs / тд. И как применить такие же подходы к другим средам
- О минимализме. Для успешной работы вам нужно меньше инструментов, а не больше
- О том, как сделать минимальное количество полезных горячих клавиш, которыми вы реально будете пользоваться
- Как навигироваться по коду, файлам, важным местам в проекте
- Какие принципы позволят вам сделать свой уникальный рабочий сетап, который удобен вам
- Как можно делать свои крутые инструменты, как пример для работы со сложными кейсами в git: https://github.com/sobolevn/fzf-simple-git
- Как писать свои темы, плагины. И когда их не писать
Будет крайне полезно, чтобы писать код быстрее и проще.
Мои конфиги за ~10 лет работы всегда можно посмотреть тут: https://github.com/sobolevn/dotfiles
Собираем донат goal на +16 человек – и начинаем! Все будет бесплатно и на ютюбе. Подписка на https://boosty.to/sobolevn стартует со 100 рублей.
Холивар про IDE объявляется открытым в комментах 🌚
Довольно часто последнее время наблюдаю, как программируют другие люди. На собесах в своем окружении, в паре со мной, на ютюбе и тд. И вот что я замечаю. Очень много людей страдает от базовых вещей, которые можно сделать простыми и удобными. Я хочу помочь.
Тем более видосы с нарезкой моего подкаста на данную тему с @t0digital собрали много обсуждений и даже возмущений. А значит – тема горячая :)
Будем делать из второй картинки третью.
О чем поговорим?
- Почему DX важен?
- Почему vscode, а не vim / pycharm / emacs / тд. И как применить такие же подходы к другим средам
- О минимализме. Для успешной работы вам нужно меньше инструментов, а не больше
- О том, как сделать минимальное количество полезных горячих клавиш, которыми вы реально будете пользоваться
- Как навигироваться по коду, файлам, важным местам в проекте
- Какие принципы позволят вам сделать свой уникальный рабочий сетап, который удобен вам
- Как можно делать свои крутые инструменты, как пример для работы со сложными кейсами в git: https://github.com/sobolevn/fzf-simple-git
- Как писать свои темы, плагины. И когда их не писать
Будет крайне полезно, чтобы писать код быстрее и проще.
Мои конфиги за ~10 лет работы всегда можно посмотреть тут: https://github.com/sobolevn/dotfiles
Собираем донат goal на +16 человек – и начинаем! Все будет бесплатно и на ютюбе. Подписка на https://boosty.to/sobolevn стартует со 100 рублей.
Холивар про IDE объявляется открытым в комментах 🌚
Forwarded from ITипичные аспекты Артёма
Предыдущее тут
3/5 пост =)
Среда-Четверг, 10+11=21ч
Был получен минимальный рабочий сценарий с файлами. Весь день посвящён структурированию бэка, разделению логики web бэкенда и аналитического бэкенда на разные сервисы, devops активностям, закладыванию моделей БД. Затянуты Mongo - основная БД, Minio - локальный S3 и Redis как БД коммуникации и шеринга состояний между сервисами
Моей ошибкой, унёсшей ~4 часа времени стала попытка сделать по-быстрому локальное хранилище вместо S3. ИИ запутался в папках и роутинг раздачи файликов не взлетел.
Нужно было сразу брать minio и на лету перепиливать S3 на S3 по сути. Пришлось отбросить/вырезать некоторое количество кода. Слава Git
Переработал LLM суммаризацию. Основная работа заключалась в вынесении конфига и ограждению курсора от попыток сменить схему SO с рабочей на нерабочую. В исходной кодбазе с неё всё было хорошо
На конец дня реорганизованный минимальный пайплайн работал на более стабильных и понятных основах, полностью собирался и обновлялся в докере. от легаси кода бэка и фронта осталось в лучшем случае 20%
Инсайты
- ИИ имеет свойство плодить кривые конфиги в разных местах. Это должно подвергаться контролю за счёт Rules, темплейтов проекта
- Нельзя вайбкодить сложную задачу. (вайбкод - не вдумываясь принимать изменения ИИ). С каждой следующей итерацией и уточнением, особенно если что-то не получается, ИИ заходит всё дальше в дебри и пишет всё более локальноориентированный структурно хреновый код
И это как будто бы базовое правило coding with AI. Ты должен вмешаться, проанализировать и выбрать корректный подход прежде чем ИИ затронет слишком многое. Возможно принять решение запустить всё с самого начала.
- Генеративный подход - когда создаёшь новый код над старым, в разы менее затратен с ИИ чем обратный, где нужно рефакторить/убирать излишки старого. Для меня, как человека, проще работать с существующим на изученной кодбазе
- ИИ затрагивает широкий набор изменений в рамках своей работы, часто работаешь над 2-3 параллельными задачами/направлениями изменений. Это осложняет классическую историю ведения гита. Очень важно регулярно уделять внимание регрессу и делать отсечки, которые пойдут коммитом в гит.
В курсоре можно откатываться на чекпоинты чатиков, но это не всегда работает и неудобно.
Уверенность, что я могу надёжно откатиться на рабочую версию - залог спокойной работы
Как итог, считаю, что мастхэв должен быть шаблон проекта, адаптированный под ИИ, где уже организована и тщательно описана желаемая организация проекта:
* Конфиги и их место
* Лучшие практики инфры вплоть до шаблонов докеров,
* Заложены примеры привычных схем, ролей, моделей.
* Подключены на уровне низкоуровневых адаптеров человекописные базовые внешние модули типа БД, web-сессий, сокетов и т.д.
* Продумана и заложена механика проброса зависимостей и централизованной инициализации модулей.
* Оно позволяет вносить изменения уже отсраиваясь от лучших практик, более точечно
ИИ склонен тупо херачить глобальные объекты и начинает творить лютую дичь как только ловит от этого сложности
На конец четверга, четвёртый физический день работы, уже проходили все базовые сценарии проекта, завязанные непосредственно на ЛК и обработку звуковых файлов. UI принял околофинальные очертания, вырисовалась более стройная организация и инфраструктурная обвязка. Проект билдился в докер и запускался на сервере
3/5 пост =)
Среда-Четверг, 10+11=21ч
Был получен минимальный рабочий сценарий с файлами. Весь день посвящён структурированию бэка, разделению логики web бэкенда и аналитического бэкенда на разные сервисы, devops активностям, закладыванию моделей БД. Затянуты Mongo - основная БД, Minio - локальный S3 и Redis как БД коммуникации и шеринга состояний между сервисами
Моей ошибкой, унёсшей ~4 часа времени стала попытка сделать по-быстрому локальное хранилище вместо S3. ИИ запутался в папках и роутинг раздачи файликов не взлетел.
Нужно было сразу брать minio и на лету перепиливать S3 на S3 по сути. Пришлось отбросить/вырезать некоторое количество кода. Слава Git
Переработал LLM суммаризацию. Основная работа заключалась в вынесении конфига и ограждению курсора от попыток сменить схему SO с рабочей на нерабочую. В исходной кодбазе с неё всё было хорошо
На конец дня реорганизованный минимальный пайплайн работал на более стабильных и понятных основах, полностью собирался и обновлялся в докере. от легаси кода бэка и фронта осталось в лучшем случае 20%
Инсайты
- ИИ имеет свойство плодить кривые конфиги в разных местах. Это должно подвергаться контролю за счёт Rules, темплейтов проекта
- Нельзя вайбкодить сложную задачу. (вайбкод - не вдумываясь принимать изменения ИИ). С каждой следующей итерацией и уточнением, особенно если что-то не получается, ИИ заходит всё дальше в дебри и пишет всё более локальноориентированный структурно хреновый код
И это как будто бы базовое правило coding with AI. Ты должен вмешаться, проанализировать и выбрать корректный подход прежде чем ИИ затронет слишком многое. Возможно принять решение запустить всё с самого начала.
- Генеративный подход - когда создаёшь новый код над старым, в разы менее затратен с ИИ чем обратный, где нужно рефакторить/убирать излишки старого. Для меня, как человека, проще работать с существующим на изученной кодбазе
- ИИ затрагивает широкий набор изменений в рамках своей работы, часто работаешь над 2-3 параллельными задачами/направлениями изменений. Это осложняет классическую историю ведения гита. Очень важно регулярно уделять внимание регрессу и делать отсечки, которые пойдут коммитом в гит.
В курсоре можно откатываться на чекпоинты чатиков, но это не всегда работает и неудобно.
Уверенность, что я могу надёжно откатиться на рабочую версию - залог спокойной работы
Как итог, считаю, что мастхэв должен быть шаблон проекта, адаптированный под ИИ, где уже организована и тщательно описана желаемая организация проекта:
* Конфиги и их место
* Лучшие практики инфры вплоть до шаблонов докеров,
* Заложены примеры привычных схем, ролей, моделей.
* Подключены на уровне низкоуровневых адаптеров человекописные базовые внешние модули типа БД, web-сессий, сокетов и т.д.
* Продумана и заложена механика проброса зависимостей и централизованной инициализации модулей.
* Оно позволяет вносить изменения уже отсраиваясь от лучших практик, более точечно
ИИ склонен тупо херачить глобальные объекты и начинает творить лютую дичь как только ловит от этого сложности
На конец четверга, четвёртый физический день работы, уже проходили все базовые сценарии проекта, завязанные непосредственно на ЛК и обработку звуковых файлов. UI принял околофинальные очертания, вырисовалась более стройная организация и инфраструктурная обвязка. Проект билдился в докер и запускался на сервере
Forwarded from ITипичные аспекты Артёма
4/5 пост, дальше только выводы
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.