Pull to refresh

Comments 15

Коммодити, но AI-driven

Deepseek, но ллама

От чего зависит выбор написания англ термина?

Пы.сы. Я не разработчик, но текст интересный. Сейв.

Как же у Вас все легко - "идем и получаем одобрение от бизнеса...". Так и хочется вставить слова классика:"Интересный Вы человек господин Корейко"

А что было сложного в прошлый раз, когда вы пытались получить одобрение от бизнеса с рабочим proof of concept на руках?

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

В статье пишу про ситуацию, когда я уже работаю в компании и предлагаю решить существующую проблему. Не понимаю, почему невозможно поговорить с бизнесом, в котором работаешь.

Заголовок статьи не соответствует содержанию. Автор просто рассказывает про свой личный опыт внедрения чего-то-там у себя на работе. Много текста - пользы мало.

Первый раз встречаю, чтобы подкрепление тезисов примерами из личного опыта было в минус

Написано не интересно. Куча терминов, слов, размышлений. Вопрос был простой: как стать разработчиком ИИ. Ответ должен быть таким же простым. А не вот это все, что я даже читать не стал

Не понял, почему ответ должен быть простой 🤷‍♂️
На вопрос "как войти в айти" вы тоже ждете один параграф? Какая польза от него будет?

Мне кажется заголовок статьи привлекает определённую аудиторию - тех кто хочет, но ещё не умеет. Однако, статья очень искусно обходит стороной все делали, которые были бы очень важны для этой аудитории.

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

Там есть:

  1. Основные этапы реализации AI проекта

  2. Грабли, на которые наступают чаще всего

  3. Набор базовых инструментов, которые нужны в работе

  4. Отобранный список материалов, который нужно изучить

Могу понять, что для кого-то это мало. Если пройдете все из статьи и будет мало, можете написать мне в ЛС, там уже под ваш конкретный кейс что-нибудь посоветую

Так вроде и ответ максимально простой, проще не встречал нигде. Правда, есть нюанс: согласно статье 80% ии разработчика - обычный разработчик. И по моему впечатлению (от статьи) - бэкенд разработчик. И не 80, а 90. Мне, бэкенд разработчику, статья выглядит как максимально простая пошаговая инструкция "на пальцах". Подозреваю, что не бэкенд разработчикам она может выглядеть иначе. Сперва надо найти инструкцию "как стать бэкенд разработчиком" и воспользоваться ей.

Да, про бэкенд, в целом, верное уточнение. Про 90% хз – я изначально так и писал, но решил исправить на 80%, потому что есть еще определенный набор навыков и паттернов комбинирования запросов, которые не типичны для обычного разработчика.

Доходит до совсем смешного – в классе Response поменяли порядок или название полей, а у вас качество упало. Или поменяли куски промпта местами, а у вас кэширование промптов, которое удешевляет инференс, перестало работать.

Да хорошо все написано, было приятно почитать, жду новых статей, почему начать использовать langchain зря

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

Еще и пример действительно полезный и в какой-то степени даже вдохновляющий.

Sign up to leave a comment.

Articles