Гибкое ПО: 80% готовой основы + 20% своего кода — и рынок productivity-инструментов перевернётся
Malleable software = solid bases and custom code
Автор, наблюдающий за рынком productivity-инструментов с 2004 года, анализирует, как AI меняет подход к созданию софта. Он сравнивает пять категорий инструментов — от Codex и Lovable до Notion и специализированных решений — и приходит к выводу, что идеальная модель — это «solid base» (готовая основа: база данных, права доступа, история изменений, коллаборация) плюс «custom code» (свой код для уникальных потребностей). По его прогнозу, malleable-инструменты (гибкие, настраиваемые) имеют лучшие шансы занять эту нишу, так как добавление точек расширения занимает кварталы, а создание основы — годы.
Выбирайте основу, а не интерфейсы: данные, история и права доступа накапливаются, и их трудно сменить через два года, а UI становится дешёвой и заменяемой частью.
- watty
Отличное понимание, я согласен с автором! Посмотрите мой [ВСТАВЬТЕ ССЫЛКУ НА GITHUB С VIBE CODED], который следует этим паттернам!
- momojo
Обожаю такой подход. В области биоимиджинга Napari — отличный пример этого. Чудесно прочная основа, но при этом чрезвычайно расширяемая, поскольку это просто Python насквозь.
Есть что-то замечательное в том, когда коллега подходит с проблемой, и ты можешь набросать плагин для Napari, который решает именно его задачу до обеда.
Мой порядок «эскалации инструментов» обычно такой:
- Могу ли я решить его проблему из встроенного терминала napari?
- Могу ли я решить её разовым скриптом?
- Могу ли я решить её разовым скриптом, который создаёт разовый интерфейс плагина?
- Стоит ли добавить плагин в наш общекорпоративный репозиторий, раз эта проблема возникает часто?
- mickael-kerjean
Это путь, по которому я иду со своей альтернативой Dropbox [1]. 80% — это быстрое ядро, которое фокусируется на управлении файлами, остальные 20% приходят через плагины, реализующие один из основных интерфейсов, так что вы можете управлять собственным хранилищем, авторизацией, аутентификацией, пользовательскими приложениями для обработки типов файлов, ... Забавный факт: в различных плагинах [2], охватывающих всё подряд, кода в 10 раз больше, чем в ядре, которое должно было быть теми самыми 80%, что неудивительно — каждому нужны были свои 20%. Плюс мне кажется крутым, что парень, которому нужна была система журналирования, соответствующая требованиям gobd и с кучей свойств для аудиторов, обеспечивающая хэш-цепочки с подписью по RFC3161, не делает систему хуже для всех остальных.
[1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/fdrive
- genatron_ai
Наличие такой рабочей основы, которую агенты затем могут настраивать под себя, — отличный подход, потому что вы получаете некоторые преимущества brownfield-разработки, где есть устоявшиеся паттерны, которым можно продолжать следовать. Это часто намного быстрее и предсказуемее, чем начинать с нуля, где, даже если агентная разработка быстрая, нужно иметь настоящее мышление разработчика и продумывать всё.
- pavo-etc
Pi — отличный пример этого. Я использовал его как основу для целого парка агентов, которых запускаю на своём сервере, но вместо TUI Pi я запускаю его в headless-режиме и расширил его, чтобы использовать XMPP в качестве уровня коммуникации, чтобы я мог пользоваться любым устройством с теми же сессиями, и чтобы агенты могли общаться друг с другом.
Каркас Pi создан для такого расширения, и с ним приятно работать.