Deploying Machine Learning Models with Vapor and Core ML
Сейчас будет абсолютно непродающий пост.
Еще немного про советы коллегам. Всем молодым ребятам, которые спрашивают нужно ли изучать iOS разработку в 16 лет я говорю — не нужно:)
Будь это знакомые, дети знакомых, родственники. На мой взгляд, популярность мобильной разработки и в целом фронтенда, особенно с развитием ИИ, сильно падает. Прошли те времена, когда за покрашенную кнопку дают кучу бабок. Сейчас мобилка становится сложнее и конкурентнее.
А вот ИИ бабки гребет и следующее десятилетие точно за ней. В среднем, я и мои знакомые только за подписки на курсоры и чатгпт отдают от 100$. Где- пользуются от силы этим всем 20% времени. Что это значит? Что в ии сейчас много пузыря и скама, как когда-то было в мобилках, фронте и бэке. А может быть и больше всех вместе взятых. Каждый ИИ плагин или обертка над чатгпт стоит от 20$ за месяц. Очевидно там много оверпрайса.
Ну в общем статья для тех, кто хочет аккуратно свитчнуться в ML и начинает с внедрения в мобилку
Стоит ли идти в иос разработку в 16 лет? Зависит от цели. Если вам нравится программирование и айфоны - да. Если нужны легкие деньги, то кмк лучше в мл:)
Сейчас будет абсолютно непродающий пост.
Еще немного про советы коллегам. Всем молодым ребятам, которые спрашивают нужно ли изучать iOS разработку в 16 лет я говорю — не нужно:)
Будь это знакомые, дети знакомых, родственники. На мой взгляд, популярность мобильной разработки и в целом фронтенда, особенно с развитием ИИ, сильно падает. Прошли те времена, когда за покрашенную кнопку дают кучу бабок. Сейчас мобилка становится сложнее и конкурентнее.
А вот ИИ бабки гребет и следующее десятилетие точно за ней. В среднем, я и мои знакомые только за подписки на курсоры и чатгпт отдают от 100$. Где- пользуются от силы этим всем 20% времени. Что это значит? Что в ии сейчас много пузыря и скама, как когда-то было в мобилках, фронте и бэке. А может быть и больше всех вместе взятых. Каждый ИИ плагин или обертка над чатгпт стоит от 20$ за месяц. Очевидно там много оверпрайса.
Ну в общем статья для тех, кто хочет аккуратно свитчнуться в ML и начинает с внедрения в мобилку
Стоит ли идти в иос разработку в 16 лет? Зависит от цели. Если вам нравится программирование и айфоны - да. Если нужны легкие деньги, то кмк лучше в мл:)
Teachable
Deploying Machine Learning Models with Vapor and Core ML
Глупый вопрос лучше глупой ошибки
Недавно я опрашивал сообщество и решил узнать какой самый главный навык выделяет джуна от сеньора.
Многие выделили навык умение задавать правильные вопросы.
На дейлике джун молчит — боится показаться глупым. Сеньор не замолкает — боится не понять.
Джун боится показаться глупым. Сеньор знает, что если не спросишь — сделаешь хуже. Джун не уверен, что имеет право на голос. Сеньор чувствует ответственность за результат.
Многие отметили, что спрашивать — это не значит быть глупым. Это значит быть честным, внимательным и готовым учиться.
Такую же проблему я замечал, когда занимался менторством. Новички часто боятся осуждений за вопрос. Не понимают можно ли его задать. Но чаще чем больше вопросов, тем больше пользы приносит процесс изучения.
Недавно я опрашивал сообщество и решил узнать какой самый главный навык выделяет джуна от сеньора.
Многие выделили навык умение задавать правильные вопросы.
Молчание джуна — это не скромность, а упущенная возможность учиться. Настойчивые вопросы сеньора — не самоуверенность, а способ глубже понимать и делать лучше. Учиться — значит задавать вопросы.
На дейлике джун молчит — боится показаться глупым. Сеньор не замолкает — боится не понять.
Джун боится показаться глупым. Сеньор знает, что если не спросишь — сделаешь хуже. Джун не уверен, что имеет право на голос. Сеньор чувствует ответственность за результат.
Многие отметили, что спрашивать — это не значит быть глупым. Это значит быть честным, внимательным и готовым учиться.
Такую же проблему я замечал, когда занимался менторством. Новички часто боятся осуждений за вопрос. Не понимают можно ли его задать. Но чаще чем больше вопросов, тем больше пользы приносит процесс изучения.
Ты не знаешь как делать задачу. Что будешь делать?
Anonymous Poll
29%
Начну делать как понял, потом разберусь
58%
Поищу решение сам
40%
Спрошу у коллег
64%
Спрошу у чатгпт
11%
Пойду в профильные чаты
35%
Вспомню как гуглить
37%
Обсужу с коллегами
4%
Другое
iOS Makes Me Hate
Ты не знаешь как делать задачу. Что будешь делать?
Кстати, заметьте как почти умерли «профильные чаты». Когда раньше форумы и сообщества были источником обмена инфы и поддержки, то с приходом чатгпт начался их закат.
Deeplink Manager по SOLID принципам
Навигация — это отдельная жопаболь любого разраба. В отличие от веба мы не рисуем по F5 дом дерево. У нас стэк из экранов + жизненный цикл приложения. Поэтому это создает кучу проблем, а также решений.
Разрабы пытались придумать кучу решений:
Паттерн Coordinator, который был популярен, а сейчас многими ненавистен. Роутеры, которые открывают экран последовательно. В SwiftUI вообще куча решений, со своими минусами и плюсами.
Для меня любая навигация, где есть огромный enum с экранами, который создает полотно из switch/case — жесткий костыль. Это не должно быть в проде.
Мобилка в итоге пришла к одному из удобных видов навигаций экранов — это диплинки. Каждый экран имеет свой идшник. Например, главная имеет путь yourapp.ru/1/main . Так мы легко управляем состоянием и создаем простую поддержку кода, не зависив от бойлер плейта.
На скриншотах набросал примерную концепцию на мой взгляд идеального диплинк хендлера. Сделаем в будущем мок-воркшоп по систем дизайну как проектировать навигацию в мобилке.
Навигация — это отдельная жопаболь любого разраба. В отличие от веба мы не рисуем по F5 дом дерево. У нас стэк из экранов + жизненный цикл приложения. Поэтому это создает кучу проблем, а также решений.
Разрабы пытались придумать кучу решений:
Паттерн Coordinator, который был популярен, а сейчас многими ненавистен. Роутеры, которые открывают экран последовательно. В SwiftUI вообще куча решений, со своими минусами и плюсами.
Для меня любая навигация, где есть огромный enum с экранами, который создает полотно из switch/case — жесткий костыль. Это не должно быть в проде.
Мобилка в итоге пришла к одному из удобных видов навигаций экранов — это диплинки. Каждый экран имеет свой идшник. Например, главная имеет путь yourapp.ru/1/main . Так мы легко управляем состоянием и создаем простую поддержку кода, не зависив от бойлер плейта.
На скриншотах набросал примерную концепцию на мой взгляд идеального диплинк хендлера. Сделаем в будущем мок-воркшоп по систем дизайну как проектировать навигацию в мобилке.
This media is not supported in your browser
VIEW IN TELEGRAM
Как я вижу всех неработающих блогеров которые дают «ультимативный гайд по росту в карьере». Предлагая джобхоппинг в 2к25….
Тренера не играют?
P.s. На видео, кстати, никого не осуждаю
Тренера не играют?
P.s. На видео, кстати, никого не осуждаю
Обложка для ронина для подписок из бусти
Почему я ими делюсь? Для меня бусти это скорее место моего развитие. Как виртуальный кабинет, библиотека или мастерская, в которых я храню книги и инструменты. В этом месте должна быть особая атмосфера. Заряжающая на поиск знаний и вдохновляющая.
Хочется, чтобы заходя на него, видно было уважение к своему труду и работу. Поэтому каждую обложку мы руками рисуем от 2-3 недель, перебирая множество вариантов. Ты должен быть доволен результатом.
Почему я ими делюсь? Для меня бусти это скорее место моего развитие. Как виртуальный кабинет, библиотека или мастерская, в которых я храню книги и инструменты. В этом месте должна быть особая атмосфера. Заряжающая на поиск знаний и вдохновляющая.
Хочется, чтобы заходя на него, видно было уважение к своему труду и работу. Поэтому каждую обложку мы руками рисуем от 2-3 недель, перебирая множество вариантов. Ты должен быть доволен результатом.
Разбор Систем дизайн интервью в FAANG
System Design — это уже база. Ушли все вопросы про зубрежку теории, теперь сеньор это не тот, кто только глубоко знает платформу, но и круто проектирует систему. Когда систем дизайн был только в 1-2 компаниях, то теперь он у всех. Так еще и усложнен и переосмыслен.
Я много встречаю заблуждений про систем дизайн:
🌟 "System Design — это про запомнить архитектуру Twitter/YouTube".
Многие думают, что нужно выучить «эталонные» решения известных систем. На самом деле важно не знать, как устроен Twitter, а понимать, как принимать архитектурные решения под конкретные требования.
Хорошая практика развивать умение задавать вопросы:
- Какие ключевые функции есть в приложении?
- Нужно ли офлайн-доступ? Если да, к каким данным?
- Есть ли встроенная авторизация? Каким способом?
🌟 "Нужно сразу прыгать в архитектуру"
Начинают рисовать схемы до того, как разобрались с требованиями. На самом деле System Design — это диалог, а не экзамен по рисованию блоков.
Когда я собесился в яндекс на моей секции мы ничего не рисовали, а общались почти 2,5 часа собирая требования в блокноте. На мой вопрос "а мы откроем миро?" интервьюер прямо сказал "мы убрали эту часть, тк многие кандидаты не на том фокусировались". Мне кажется, это правильное решение.
🌟 "Правильный ответ один"
Все ищут «идеальную» архитектуру. На самом деле почти всегда существует несколько решений, и важно уметь аргументировать свой выбор.
🌟 "System Design — это только для Senior-инженеров"
Многие джуны и мидлы думают, что им рано. System Design — это способ мышления, полезный на любом уровне.
В этом видео также очень хорошо разобраны внутренности систем дизайн интервью и их реальную цель
System Design — это уже база. Ушли все вопросы про зубрежку теории, теперь сеньор это не тот, кто только глубоко знает платформу, но и круто проектирует систему. Когда систем дизайн был только в 1-2 компаниях, то теперь он у всех. Так еще и усложнен и переосмыслен.
Я много встречаю заблуждений про систем дизайн:
Многие думают, что нужно выучить «эталонные» решения известных систем. На самом деле важно не знать, как устроен Twitter, а понимать, как принимать архитектурные решения под конкретные требования.
Хорошая практика развивать умение задавать вопросы:
- Какие ключевые функции есть в приложении?
- Нужно ли офлайн-доступ? Если да, к каким данным?
- Есть ли встроенная авторизация? Каким способом?
Начинают рисовать схемы до того, как разобрались с требованиями. На самом деле System Design — это диалог, а не экзамен по рисованию блоков.
Когда я собесился в яндекс на моей секции мы ничего не рисовали, а общались почти 2,5 часа собирая требования в блокноте. На мой вопрос "а мы откроем миро?" интервьюер прямо сказал "мы убрали эту часть, тк многие кандидаты не на том фокусировались". Мне кажется, это правильное решение.
Все ищут «идеальную» архитектуру. На самом деле почти всегда существует несколько решений, и важно уметь аргументировать свой выбор.
Многие джуны и мидлы думают, что им рано. System Design — это способ мышления, полезный на любом уровне.
В этом видео также очень хорошо разобраны внутренности систем дизайн интервью и их реальную цель
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
#FaangTalk 79 - Разбор Систем дизайн интервью
Канал с анонсами https://t.iss.one/faangtalk_news
Чат по подготовке к интервью: https://t.iss.one/faangtalk
В выпуске разбираем Систем Дизайн Интервью в FAANG на Стаф позицию
Видео https://youtu.be/-wqG7ZBoxmc
В гостях
Max Strakhov https://t.iss.one/faang_career
Dima…
Чат по подготовке к интервью: https://t.iss.one/faangtalk
В выпуске разбираем Систем Дизайн Интервью в FAANG на Стаф позицию
Видео https://youtu.be/-wqG7ZBoxmc
В гостях
Max Strakhov https://t.iss.one/faang_career
Dima…
Как мы доверили качество наших приложений AI
Делюсь видосами с Яндекс Dev Day&Night. Там было много крутых докладов, поэтому будет несколько постов.
Когда я говорил, что AI — это геймченджер индустрии, я не шутил. Крупные компании уже его пихают от кодревью кода до упрощения разработки и тестирования.
Начнем с доклада Лёши, где он рассказал, как наши команды использует AI для тестирования приложений.
В докладе вы увидете:
🔘 сможет ли AI заменить QA?
🔘 Плюсы и минусы тестирования апки с LLM
🔘 Насколько упростилось написание тестов?
🔘 Понизился ли порог входа?
🔘 сэкономились ли время и деньги?
Делюсь видосами с Яндекс Dev Day&Night. Там было много крутых докладов, поэтому будет несколько постов.
Когда я говорил, что AI — это геймченджер индустрии, я не шутил. Крупные компании уже его пихают от кодревью кода до упрощения разработки и тестирования.
Начнем с доклада Лёши, где он рассказал, как наши команды использует AI для тестирования приложений.
В докладе вы увидете:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как мы доверили качество наших приложений AI / Лёша Маслобоев
На Яндекс Dev Day&Night Лёша Маслобоев, старший разработчик мобильной платформы iOS, рассказал про продукт QA AI. Лёша показал, как можно использовать LLM для тестирования приложений, как устроена архитектура проекта и какие метрики ребята используют. А ещё…
Навигация — самая частая тема в вопросах по архитектуре. Много спрашивали в комментариях и личке, что почитать по этой теме. Раньше посоветовать было нечего, но теперь готов закрыть этот запрос.
Начинаю новый цикл статей. В нем мы затронем популярные и неочень навигации на UIKit (Coordinator, router, как работает UINavigationController и многое другое). Плавно перейдя в SwiftUI.
В этой же статье мы детально разберем как сделать Deeplink Handler по SOLID. Какие лучшие практики я видел за свой опыт и как мне они помогли.
Этот контент точно поможет не только на System Design секциях, но и в реальной жизни:
И многое другое.
В цикле будет много кода и примеров.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как создатели ARC отказываются от TCA и SwiftUI
Мы уже разбирали критику TCA. О том, что это далеко неидеальная архитектура, где есть баги с удержанием памяти и исполнением бизнес логики только на главном потоке. От чего перфоманс сложных приложений сильно страдает.
Наш подписчик сообщества, лид крупного проекта, даже расписал пост с основными проблемами.
Вот и авторы браузера Arc, в своем прощальном письме о закрытии продукта, написали что в новом продукте отказываются от TCA и SwiftUI. В письме команда объясняет своё решение перейти к разработке нового продукта — Dia. Основная цель — создать более лёгкий, быстрый и отзывчивый браузер, соответствующий современным требованиям и ожиданиям пользователей.
Почему отказались от TCA и SwiftUI:
🔘 Производительность: TCA и SwiftUI, хотя и предоставляют мощные инструменты для разработки, могут приводить к снижению производительности в больших и сложных приложениях.
🔘 Сложность: С увеличением масштаба приложения архитектура TCA может становиться трудно управляемой, особенно из-за отсутствия чётких границ между экшенами и состояниями, что может приводить к ошибкам и затруднениям в поддержке кода.
🔘 Гибкость: Для реализации новых функций и улучшения отзывчивости интерфейса команда решила использовать более лёгкие и гибкие инструменты, позволяющие быстрее адаптироваться к изменениям и требованиям пользователей.
Ну а мы помним, что нет идеальных технологий. Скорость инфляции знаний или инструментов в ит бешенная. Есть технологии, библиотеки, фреймворки, которые решают хорошо только ограниченный список задач, но не являются универсальной пулей.
Мы уже разбирали критику TCA. О том, что это далеко неидеальная архитектура, где есть баги с удержанием памяти и исполнением бизнес логики только на главном потоке. От чего перфоманс сложных приложений сильно страдает.
Наш подписчик сообщества, лид крупного проекта, даже расписал пост с основными проблемами.
Вот и авторы браузера Arc, в своем прощальном письме о закрытии продукта, написали что в новом продукте отказываются от TCA и SwiftUI. В письме команда объясняет своё решение перейти к разработке нового продукта — Dia. Основная цель — создать более лёгкий, быстрый и отзывчивый браузер, соответствующий современным требованиям и ожиданиям пользователей.
Почему отказались от TCA и SwiftUI:
Ну а мы помним, что нет идеальных технологий. Скорость инфляции знаний или инструментов в ит бешенная. Есть технологии, библиотеки, фреймворки, которые решают хорошо только ограниченный список задач, но не являются универсальной пулей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
Letter to Arc members 2025
On Arc, its future, and the arrival of AI browsers — a moment to answer the largest questions you've asked us this past year.
Как я использую ИИ для повышения производительности труда (UPD)
Я уже делился этой статьей ранее, но на днях наш любимый блоггер обновил список. Теперь он поставил на второе место "Быстрое понимание сложной кодовой базы".
А я тоже об этом недавно писал, что Cursor и другие пилоты (если у вас настроен private mode и вы прячете все NDA согласуя с безопасниками), отлично помогает понимать сложный код. Пусть эйфория от АИшек быстро проходит, но их польза становится все более ощутимой.
Например, я уже писал что на проектах, где есть сложный и древний модуль, о котором никто ничего не знает, курсор отлично помогает.
На первых этапах курсор помог мне понять как добавить новые элементы, куда, зачем и даже где вставить нужный код. Тут правда нужно быть аккуратным, ибо иногда он предлагает дичь, но в целом для общего плана это круто. Не нужно пинговать и душить коллег)
В целом, то что изучает джун за полгода, курсор изучает это за минуты.
Кстати, забавно, что чем чаще им пользуешься, тем хуже ответы 🙂
Я уже делился этой статьей ранее, но на днях наш любимый блоггер обновил список. Теперь он поставил на второе место "Быстрое понимание сложной кодовой базы".
А я тоже об этом недавно писал, что Cursor и другие пилоты (если у вас настроен private mode и вы прячете все NDA согласуя с безопасниками), отлично помогает понимать сложный код. Пусть эйфория от АИшек быстро проходит, но их польза становится все более ощутимой.
Например, я уже писал что на проектах, где есть сложный и древний модуль, о котором никто ничего не знает, курсор отлично помогает.
На первых этапах курсор помог мне понять как добавить новые элементы, куда, зачем и даже где вставить нужный код. Тут правда нужно быть аккуратным, ибо иногда он предлагает дичь, но в целом для общего плана это круто. Не нужно пинговать и душить коллег)
В целом, то что изучает джун за полгода, курсор изучает это за минуты.
Кстати, забавно, что чем чаще им пользуешься, тем хуже ответы 🙂
Forwarded from Нейродвиж
Лол, чувак запустил новую нейронку Claude 4 в свой проект, результат убил:
Программисты УМЕРЛИ после этого😁
Claude 4 только что рефакторил всю мою кодовую базу за один вызов.
25 вызовов инструментов. 3000+ новых строк. 12 совершенно новых файлов.
Он все модулировал. Разбил монолиты. Убрал спагетти.
Ничего из этого не работает. Но, боже, как это было прекрасно.
Программисты УМЕРЛИ после этого
Please open Telegram to view this post
VIEW IN TELEGRAM
Решил разобрать этот паттерн, потому что был удивлен, что его мало кто знает. Хотя он встречается в 99% проектах.
Паттерн Interceptor (Перехватчик) — это паттерн, который помогает добавить доп. обработку к вызовам методов — до или после их выполнения, не меняя сам код этих методов. В Swift он особенно полезен, когда нужно добавить функции логирования или авторизации.
Добавим аналогии для понимания.
Допустим, мы идем в офис на работу. По пути нас "перехватывают" несколько служб:
Теперь вернемся в реальную практику. Когда ты делаешь сетевые запросы к API, почти всегда нужен токен авторизации. В простом случае ты добавляешь токен вручную в каждый запрос.
Но если таких запросов десятки, это становится неудобно и неудобно поддерживать. Здесь на помощь приходит Interceptor.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Киря
Вайбкодинг → Метакодинг
Термин «вайбкодинг» появился недавно, но уже успел стать ругательным. Им обозначают бездумное дилетантское программирование с нейронками. Но нейронки — оч мощный инструмент. Если пользоваться ими правильно, можно делать крутые вещи
Сегодня в одной статье я подсмотрел термин «метакодинг» и мне он очень понравился. Статья наполовину написана нейросетью (вайб-редактура, кек), и читается трудно, поэтому ссылку я давать не стану. Да и не в статье дело. Просто она подтолкнула меня поделиться тем, что я на личном опыте узнал за год метакодинга
(если вы не знаете, мы с Женей Власовым пилим, и скоро, я надеюсь, релизнем iOS-приложение «Буков»)
Метакодинг — вдумчивое и грамотное программирование с нейросетями. Код пишет нейросеть, но ты контролируешь каждый этап, вникаешь в архитектуру, внимательно читаешь сопроводительные комментарии нейронки, тестируешь код и постоянно обновляешь документацию и контекст
Вот, какие основные советы я вынес из года метакодинга:
— Проси объяснять на твоём уровне непонимания. Всегда полезно спрашивать, что значат термины, которые тебе пишет нейронка
— Читай, что тебе пишет нейросеть. Не применяй правки бездумно
— Документация — это фундамент. Именно она задаёт контекст нейронке и помогает ей не делать ошибок. У тебя будут сотни чатов. Чем полнее твоя документация, тем проще тебе будет начинать каждый новый чат
— Проси нейронку анализировать код и писать/обновлять документацию в соответствии с этим анализом
— Дели документацию на блоки по функциональным частями твоего приложения
— Записывай все высокоуровневые правила и практики, которым ты хочешь, чтобы нейронка следовала, в отдельный файлик, и добавляй его в контекст или в поле кастомного промта
— Не проси исправлять ошибки больше одного раза. Если первая просьба не сработала, лучше откатись на шаг назад и посмотри, что нужно добавить в промт, чтобы ошибок не было. Добавь это и перегенерируй ответ
— Иногда ошибки уходят, если тупо перегенерировать ответ заново или сменить модель
— Не скупись на самые новые модели. Иногда качество кода существенно повышается просто из-за подбора правильной модели
— Но! Новые модели не обязательно лучше. Мы сталкивались с ситуациями, когда Sonnet 3.5 писал код гораздо лучше Sonnet 3.7 или даже GPT 4o, хотя по синтетическим тестам они слабее
— Экономь окно контекста. Следи за тем, чтобы в контекст не попадала ненужная информация. Если даёшь нейронке логи, убирай из них лишнее. Это и деньги экономит, и качество ответов повышает
(эти советы легко могут устареть через полгода, но пока так)
Многие думают, что нейронка — это такое волшебное окно, куда ты пишешь «сделай круто» и она так и делает. А это просто новый инструмент. Если нейронка что-то написала не так — это твоя ответственность и вина. Это не машина тупая, а ты плохо поставил задачу. Она просто делает то, что ты просишь. Garbage in — garbage out
КОРОЧЕ: Метакодинг — база, и он доступен всем, кто готов проявить усидчивость и терпение
Термин «вайбкодинг» появился недавно, но уже успел стать ругательным. Им обозначают бездумное дилетантское программирование с нейронками. Но нейронки — оч мощный инструмент. Если пользоваться ими правильно, можно делать крутые вещи
Сегодня в одной статье я подсмотрел термин «метакодинг» и мне он очень понравился. Статья наполовину написана нейросетью (вайб-редактура, кек), и читается трудно, поэтому ссылку я давать не стану. Да и не в статье дело. Просто она подтолкнула меня поделиться тем, что я на личном опыте узнал за год метакодинга
(если вы не знаете, мы с Женей Власовым пилим, и скоро, я надеюсь, релизнем iOS-приложение «Буков»)
Метакодинг — вдумчивое и грамотное программирование с нейросетями. Код пишет нейросеть, но ты контролируешь каждый этап, вникаешь в архитектуру, внимательно читаешь сопроводительные комментарии нейронки, тестируешь код и постоянно обновляешь документацию и контекст
Вот, какие основные советы я вынес из года метакодинга:
— Проси объяснять на твоём уровне непонимания. Всегда полезно спрашивать, что значат термины, которые тебе пишет нейронка
— Читай, что тебе пишет нейросеть. Не применяй правки бездумно
— Документация — это фундамент. Именно она задаёт контекст нейронке и помогает ей не делать ошибок. У тебя будут сотни чатов. Чем полнее твоя документация, тем проще тебе будет начинать каждый новый чат
— Проси нейронку анализировать код и писать/обновлять документацию в соответствии с этим анализом
— Дели документацию на блоки по функциональным частями твоего приложения
— Записывай все высокоуровневые правила и практики, которым ты хочешь, чтобы нейронка следовала, в отдельный файлик, и добавляй его в контекст или в поле кастомного промта
— Не проси исправлять ошибки больше одного раза. Если первая просьба не сработала, лучше откатись на шаг назад и посмотри, что нужно добавить в промт, чтобы ошибок не было. Добавь это и перегенерируй ответ
— Иногда ошибки уходят, если тупо перегенерировать ответ заново или сменить модель
— Не скупись на самые новые модели. Иногда качество кода существенно повышается просто из-за подбора правильной модели
— Но! Новые модели не обязательно лучше. Мы сталкивались с ситуациями, когда Sonnet 3.5 писал код гораздо лучше Sonnet 3.7 или даже GPT 4o, хотя по синтетическим тестам они слабее
— Экономь окно контекста. Следи за тем, чтобы в контекст не попадала ненужная информация. Если даёшь нейронке логи, убирай из них лишнее. Это и деньги экономит, и качество ответов повышает
(эти советы легко могут устареть через полгода, но пока так)
Многие думают, что нейронка — это такое волшебное окно, куда ты пишешь «сделай круто» и она так и делает. А это просто новый инструмент. Если нейронка что-то написала не так — это твоя ответственность и вина. Это не машина тупая, а ты плохо поставил задачу. Она просто делает то, что ты просишь. Garbage in — garbage out
КОРОЧЕ: Метакодинг — база, и он доступен всем, кто готов проявить усидчивость и терпение