Вайбкодинг → Метакодинг

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

Сегодня в одной статье я подсмотрел термин «метакодинг» и мне он очень понравился. Статья наполовину написана нейросетью (вайб-редактура, кек), и читается трудно, поэтому ссылку я давать не стану. Да и не в статье дело. Просто она подтолкнула меня поделиться тем, что я на личном опыте узнал за год метакодинга

(если вы не знаете, мы с Женей Власовым пилим, и скоро, я надеюсь, релизнем iOS-приложение «Буков»)

Метакодинг — вдумчивое и грамотное программирование с нейросетями. Код пишет нейросеть, но ты контролируешь каждый этап, вникаешь в архитектуру, внимательно читаешь сопроводительные комментарии нейронки, тестируешь код и постоянно обновляешь документацию и контекст

Вот, какие основные советы я вынес из года метакодинга:
— Проси объяснять на твоём уровне непонимания. Всегда полезно спрашивать, что значат термины, которые тебе пишет нейронка
— Читай, что тебе пишет нейросеть. Не применяй правки бездумно
— Документация — это фундамент. Именно она задаёт контекст нейронке и помогает ей не делать ошибок. У тебя будут сотни чатов. Чем полнее твоя документация, тем проще тебе будет начинать каждый новый чат
— Проси нейронку анализировать код и писать/обновлять документацию в соответствии с этим анализом
— Дели документацию на блоки по функциональным частями твоего приложения
— Записывай все высокоуровневые правила и практики, которым ты хочешь, чтобы нейронка следовала, в отдельный файлик, и добавляй его в контекст или в поле кастомного промта
— Не проси исправлять ошибки больше одного раза. Если первая просьба не сработала, лучше откатись на шаг назад и посмотри, что нужно добавить в промт, чтобы ошибок не было. Добавь это и перегенерируй ответ
— Иногда ошибки уходят, если тупо перегенерировать ответ заново или сменить модель
— Не скупись на самые новые модели. Иногда качество кода существенно повышается просто из-за подбора правильной модели
— Но! Новые модели не обязательно лучше. Мы сталкивались с ситуациями, когда Sonnet 3.5 писал код гораздо лучше Sonnet 3.7 или даже GPT 4o, хотя по синтетическим тестам они слабее
— Экономь окно контекста. Следи за тем, чтобы в контекст не попадала ненужная информация. Если даёшь нейронке логи, убирай из них лишнее. Это и деньги экономит, и качество ответов повышает

(эти советы легко могут устареть через полгода, но пока так)

Многие думают, что нейронка — это такое волшебное окно, куда ты пишешь «сделай круто» и она так и делает. А это просто новый инструмент. Если нейронка что-то написала не так — это твоя ответственность и вина. Это не машина тупая, а ты плохо поставил задачу. Она просто делает то, что ты просишь. Garbage in — garbage out

КОРОЧЕ: Метакодинг — база, и он доступен всем, кто готов проявить усидчивость и терпение

Awesome Tuist

Если собирать топ действительно полезных библиотек для iOS-разработки, то на первое место я бы поставил Tuist.

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

Это конкретная оценка по полноте и объему информации любого архитектурного решения. Если там есть пейволл, то определенно точно на него будут акценты воронок продаж, чтобы как можно больше людей запросило поддержку. Наша задача, при выборе архитектурного решения, не очароваться математическим бэкграундом или техническим скиллом авторов. А трезво оценить их НАМЕРЕНИЯ. Степень доступности информации — это ключевая оценка любой технологии.

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

В некоторых случаях библиотеки словно специально делают сложнее, чем нужно. В итоге всё сводится к тому, что разработчики вынуждены платить за консультации — и не просто платить, а по несколько сотен евро. А если у них что-то не получилось — всегда можно сказать: «Они использовали старую версию и вообще всё неправильно делали. В нашем платном контенте мы расскажем как нужно». (отказаться от использование библиотек на зрелых этапах не так дешево)

Удобная позиция "Ты просто не умеешь это готовить". Только вот рецепты “как правильно” — платные. Доказательств нет, но интуиция подсказывает: усложнение может быть не случайным, особенно если платные консультации — единственный способ монетизации.

Идеальный маркетинг:
1. Убедить всех, что инструмент — бесплатный.
2. Дождаться, пока его минусы будут проявляться на больших масштабах проекта и о них мало кто расскажет.
3. Усложнить использование, а всех критиков обвинить "в недостатке скилла".
4. Понимать, что отказ и выпил технологии будет для них дорогой.
5. Загнав в угол предложить платное решение, чтобы “разобраться”.

Отличная шахматная партия. Шах и мат. Если уж и завидовать таланту авторов, то только их стратегии монетизации и отличной коммерческой игре. Но такая монетизация мне кажется зашкварной. Одно дело ты продаешь знания, а другое делаешь других зависимыми от своего продукта, создаешь искусственно проблему, а потом просишь за решение этой проблемы деньги. Капитализм? Меркантильность? Ну, извините, мы из разных обойм.

При выборе архитектурных решений всегда оценивате "интерес" авторов ;) И если их интерес построен на таком СКРЫТОМ НАМЕРЕНИИ и зависимости, как "поддержка", то это красный флаг.

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

Например, в отличие от ТСА, туист легко посчитать в цифры — вы экономите время ожидания билда. А это чуть ли не основная метрика приложения. Плюс в чат, если работали в проектах банка и ждали билды час. Так еще и бесплатно. Без намеренного усложнения. Без скрытых платных слоёв.

В этом гитхабе автор собрал полезные ссылки, если еще не затащили туист или не прокачали у себя.

Авито удалили из App Store

SwiftUI Architecture — Best Practices and Principles

Тема архитектур все острее и острее. Красить кнопки нам осталось немного.

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

Напомню, что архитектуры и систем дизайн — это не перебор паттернов проектирования и спор между MVC и VIPER. Это более глубокая тема, которая затрагивает очень много нюансов. Как и зачем складывать код? Как читается лучше? Где меньше когнитивная нагрузка?

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

Выбрасывайте TCA из проекта. Пишите свои удобные архитектурные решения.

👨‍💻В России заработала платформа для подтверждения навыков айтишников

Программисты, которые успешно справятся, получат сертификат Минцифры и отметку на Госуслугах.

Сократите расходы, а не углы. Модуляризация с помощью SPM

Когда речь идёт об архитектуре, важно понимать: MVC, MVP, VIPER, TCA — это не архитектуры, а лишь паттерны уровня UI. Настоящая архитектура — это о структуре всего приложения, а не одного экрана.

Модуляризация отвечает на прямые вопросы:
- Где будет бизнес-логика?
- Как делятся модули?
- Как они взаимодействуют?
- Как добавлять новые фичи?

Эти вопросы особенно важны, когда проект растёт и превращается в монолит: сборка становится медленной (привет банки с часом сборки проекта), а багов всё больше. В такой ситуации уже не до споров про TCA или VIPER — хочется просто, чтобы всё работало.

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

Архитектура — это не стиль, а система с понятными метриками и последствиями. И если решать архитектурные проблемы — то с опорой на реальную структуру проекта, а не только на паттерны UI.

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