Спасибо, понял. Подход, который я описал - это классика, которую десятилетиями продвигают компании, разрабатывающие инструменты разработки (автоматической генерации...) на основе концептуальных описаний...
Обычные разработчики никаких концептуальных описаний/моделей не поддерживают, а просто "пишут код" :-)
Проблема, которую описывает автор статьи, в том, что в данном случае написанный код непонятен человеку. И при отсутствии высокоуровневого описания, понятного человеку, остаётся полагаться на способности ИИ... и выбрасывать сделанное им, если он справиться не может?!
Если ИИ пишет код не с нуля, то ему надо рассказать не только то, как должно быть, но и то, чем отличается переданный ему кусок кода от того, что нужно сделать. И надо позаботиться не только о том, чтобы изменения кода соответствовали новой версии описания, но ещё и продумать переход от старого к новому. То есть второй шаг, о котором мы сейчас с Вами говорим - это далеко не то же самое, что повторение первого шага :-)
То есть Вы расширяете или переделываете модуль, расширяя или переделывая его описание для ИИ. То описание, которое было создано для предыдущей версии. А потом ИИ разрабатывает новый код на основе этого описания опять с нуля?!
Интересно, спасибо за статью. Пожалуй, я попробую начать активно использовать ИИ похожим образом:
Мы пришли к третьему варианту с элементами первого. ИИ помогает нам разбираться в документации и думать над сложными кейсами.
Да, ИИ определённо хорош в качестве "продвинутого поиска" ответов на вопросы (вариантов решений) как внутри кодовой базы, так и в Сети, в том числе, в документации.
Очевидно, полезность ИИ падает с увеличением размера кода, составляющего разрабатываемую Систему, плюс, до некоторой степени, - кода (АПИ) интегрируемых с нашей Системой других систем... Но если он сможет быть более полезен, чем полнотекстовый поиск - уже хорошо.
Интересно упоминание MCP-серверов и необходимости искать ответы по свежей информации, а не только по тому, чему ИИ мог научиться раньше.
Это рассказ про разработку первой версии приложения.
А основной вопрос в данной статье - о развитии и последующих версиях.
Как Вы делаете следующую версию? В которой что-то надо расширишь, что-то сделать по-другому, обеспечив совместимость и миграцию с предыдущего решения...
Первая вещь — это папка inbox. Всё новое падает туда вообще без разборки. Получил документ, файл, чек, письмо, экспорт — просто закинул. Разбор потом. Это снимает порог входа.
Вспомнилась фраза, прочитанная в Twitter 162 месяца назад (как говорит мне мой клиент соцсетей):
Понял, как работает Read It Later: Добавляешь туда всё и НЕ читаешь. Это даже лучше, чем я думал.
Понятно: надежда на бесплатность и на то, что разработчик сам найдёт способ окупать развитие и эксплуатацию Системы :-) И на то, что "ещё немного", и Система ("ИИ" или что-то ещё) начнёт делать правильно и многое, а не только складывать стишки из известных фраз и рифм.
Я помню, в девяностые мой товарищ купил себе программу преобразования голоса в текст ("Горыныч", вроде бы...). Он надеялся, что ещё немного, и ему не придётся самому наколачивать на клавиатуре свои умные мысли.
Но вот прошло тридцать лет, но даже сегодня "Яндекс клавиатура", которая распознаёт мой голос и пишет за меня текст, показывает, что она слабо понимает то, о чём я говорю. И соответственно, часто ошибается. Меня устраивает её работа только потому, что она условно бесплатна для меня.
Привет Джулио! Да, твой опыт поиска себя и своей профессии действительно интересен и поучителен. Я уже отправил ссылку на эту статью тем своим знакомым, которым, возможно, твой пример поможет увидеть перспективу и варианты пути...
И привет IBS-у. Интересно, как после многих перипетий эта компания стала разработчиком софта. Когда я, примерно в таком же возрасте, как и ты, пришёл в IBS, разработки был минимум. В основном - консалтинг и "системная интеграция"...
Прочитав про ссылку на YouTube, я подумал: А точно автор хочет, чтобы читатели посмотрели это видео?
Выложите на Российский сайт, пожалуйста!
Это не так. Ищешь, находишь и переходишь на новое.
Большинство поменяют текущие неработающие привычки на то, что продолжает работать, в том числе на новое, появляющееся на расчищенном поле.
Скорее не "когда столкнётесь", а "когда поймёте, что такое legacy". :-)
Мне нравтся понимание, что legacy - это всё то , что уже работает. А не что-то абстрактно "устаревшее".
А я сюда попал из ленты новостей Google Chrome for Android.
И тоже никаких картинок не заметил.
...картинка там в ленте была, но мелкая - не разглядеть
А что толку винить "стрелочников"? Внедрение ИИ толкают сверху.
Проблема ещё и в том, что люди приходят и уходят.
Даже месяц назад сделанный коммит может принадлежать "бывшему сотруднику".
Спасибо, понял. Подход, который я описал - это классика, которую десятилетиями продвигают компании, разрабатывающие инструменты разработки (автоматической генерации...) на основе концептуальных описаний...
Обычные разработчики никаких концептуальных описаний/моделей не поддерживают, а просто "пишут код" :-)
Проблема, которую описывает автор статьи, в том, что в данном случае написанный код непонятен человеку. И при отсутствии высокоуровневого описания, понятного человеку, остаётся полагаться на способности ИИ... и выбрасывать сделанное им, если он справиться не может?!
Если ИИ пишет код не с нуля, то ему надо рассказать не только то, как должно быть, но и то, чем отличается переданный ему кусок кода от того, что нужно сделать.
И надо позаботиться не только о том, чтобы изменения кода соответствовали новой версии описания, но ещё и продумать переход от старого к новому.
То есть второй шаг, о котором мы сейчас с Вами говорим - это далеко не то же самое, что повторение первого шага :-)
То есть Вы расширяете или переделываете модуль, расширяя или переделывая его описание для ИИ. То описание, которое было создано для предыдущей версии.
А потом ИИ разрабатывает новый код на основе этого описания опять с нуля?!
Интересно, спасибо за статью.
Пожалуй, я попробую начать активно использовать ИИ похожим образом:
Да, ИИ определённо хорош в качестве "продвинутого поиска" ответов на вопросы (вариантов решений) как внутри кодовой базы, так и в Сети, в том числе, в документации.
Очевидно, полезность ИИ падает с увеличением размера кода, составляющего разрабатываемую Систему, плюс, до некоторой степени, - кода (АПИ) интегрируемых с нашей Системой других систем... Но если он сможет быть более полезен, чем полнотекстовый поиск - уже хорошо.
Интересно упоминание MCP-серверов и необходимости искать ответы по свежей информации, а не только по тому, чему ИИ мог научиться раньше.
Это рассказ про разработку первой версии приложения.
А основной вопрос в данной статье - о развитии и последующих версиях.
Как Вы делаете следующую версию? В которой что-то надо расширишь, что-то сделать по-другому, обеспечив совместимость и миграцию с предыдущего решения...
Вспомнилась фраза, прочитанная в Twitter 162 месяца назад (как говорит мне мой клиент соцсетей):
Понятно: надежда на бесплатность и на то, что разработчик сам найдёт способ окупать развитие и эксплуатацию Системы :-)
И на то, что "ещё немного", и Система ("ИИ" или что-то ещё) начнёт делать правильно и многое, а не только складывать стишки из известных фраз и рифм.
Я помню, в девяностые мой товарищ купил себе программу преобразования голоса в текст ("Горыныч", вроде бы...). Он надеялся, что ещё немного, и ему не придётся самому наколачивать на клавиатуре свои умные мысли.
Но вот прошло тридцать лет, но даже сегодня "Яндекс клавиатура", которая распознаёт мой голос и пишет за меня текст, показывает, что она слабо понимает то, о чём я говорю. И соответственно, часто ошибается. Меня устраивает её работа только потому, что она условно бесплатна для меня.
Если вам нужна система для сочинения "стишков", то систему управления самолётом вы и за грош не купите.
Вопос только, а сколько у вас есть денег на оплату разработки и эксплуатации системы, которая сумеет сочинять устраивающие вас стишки.
Звучит как призыв использовать конкретное программно-аппаратное решение :-)
Привет Джулио!
Да, твой опыт поиска себя и своей профессии действительно интересен и поучителен. Я уже отправил ссылку на эту статью тем своим знакомым, которым, возможно, твой пример поможет увидеть перспективу и варианты пути...
И привет IBS-у. Интересно, как после многих перипетий эта компания стала разработчиком софта. Когда я, примерно в таком же возрасте, как и ты, пришёл в IBS, разработки был минимум. В основном - консалтинг и "системная интеграция"...