В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
Стирать это хорошо. Это гораздо лучше чем не стирать. На этапе доски ошибки почти бесплатны. Любая пойманная ошибка экономит море денег.
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Фотографии доски после совещаний это вообще ценный артефакт. Он вероятно поможет кому-то через 10 лет понять как до такого дошли.
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
Когда БД спроектирована человек садится и пишет create table под все что придумали и согласовали.
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
А сколько БД крупных (допустим от человекогода на разработку бекенда) прод сервисов вы спроектировали? Я несколько.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Более того. в развитие темы — если он, как проверенный ценнейший специалист, для рисования моков запросит спины белых девственниц, то вопрос будет не "а зачем это тебе надо?", а "какую площадь обеспечить единовременно?"
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
Инструмент не важен, важно — решается задача или нет.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Чисто теоретический вопрос - вы представляете себе, что такое НФ? От 3 до 6? И как одна физическая сущность может развертываться в произвольное число таблиц и всего прочего, описывающего ее? А связи сущностей? Нарезать это в отдельные промты? Ну, удачи
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.
LLM - технология генерации контента, поэтому Вам неоднократно написали о том, что результат генеративных моделей надо валидировать, что в свою очередь требует неопределенного количества времени, которое игнорируется в контексте "экономии времени".
Так я и сам пишу, что требует валидации. Вот часть текста одного из моих комментариев под этой же статьёй:
Я на личном практическом опыте многократно убедился, что экономия существенная, и эффект ускорения значительный. Да, именно при правильном использовании, с последующей верификацией. И я не говорю о том, чтобы делать всё-всё при помощи ИИ. Нужно понимать, какие задачи будет быстрее запромптить и отверифицировать, чем продумать и написать самому. Если ставить перед собой цель написать весь код проекта исключительно с помощью ИИ, то на более менее среднем-крупном проекте это доставит больше проблем, чем пользы. Однако реализацию отдельных моментов, которые можно эффективно ускорить с помощью ИИ, не жертвуя качеством и излишними время-затратами, рациональнее реализовывать с помощью ИИ. И да, это облегчит и ускорит процесс.
Вы так уверены, что именно я "не сталкивался" или "слишком поверхностно"? И на чем же основана ваша уверенность? Ну расскажите
@BoomerCore я тут скорее не про вас, а про тех, насчёт которых вы утверждаете:
Вам уже тут неоднократно объясняли, что если делать задачу правильно (ваш пример), то экономия "на спичках" даст настолько незначительный эффект ускорения
А по поводу подобных комментариев, именно такое впечатление и сложилось. Когда человек не пробовал, не знает какие сейчас возможности у нейросетей, и результаты какого качества они могут давать, но предполагает, что заведомо не могут ничего полезного сгенерировать, и пишет комментарии отталкиваясь от своих теоретических размышлений. А уверенность моя в этом основана, повторюсь, на личном практическом опыте.
Я уже несколько раз здесь писал, что именно декомпозируя "собственным интеллектом" задачи на мелкие, и делегируя их ИИ, и то не все, а те в которых экономия времени будет существенной, при том что процесс включает не только написание промпта, но и проверку результата, то общая экономия будет тоже существенной. И опять же, это личный практический опыт, а не предположения. И нет, не по ХХП.
Shit in - shit out согласен, об этом я и в статье пишу:
Чем подробнее и точнее будет текстовый промпт, тем лучше будет результат
А вот LLM считает, что он является искусственным интеллектом 😁
И гугол тоже пишет, что "обзор от ИИ"
Как по мне не нужно сравнивать искусственный интеллект с человеческим. Это естественно не одно и то же, и не будет одним и тем же. У человеческого интеллекта есть свои плюсы и минусы (но не у всех людей есть интеллект 😁), у искусственного интеллекта есть свои другие плюсы и минусы.
И сила именно в объединении человеческого и искусственного интеллекта, или если вам так больше нравится, человеческого интеллекта и мощь результатов машинного обучения
С иерархией в LLM дела уже обстоят вполне себе, уважаемый. Тот же Cursor и ориентируется в существующей структуре, и сам способен создать структуру папок и файлов. Я как то проводил ревью файловой структуры не особо большого проекта, там backend с несколькими crud операциями и другой не сильно замороченной логикой, который был реализован полностью на ИИ. И я полностью одобрил структуру папок и файлов. То есть во первых она (структура) там была, а во вторых мне было не к чему придраться, чтобы сказать что что-то с ней не так.
Человек который шарит в нюансах таких ошибок не допускает
Поэтому у штурвала ИИ должен быть именно такой человек, который способен проверить результат. Сделать ревью, и при необходимости исправить.
В командах программирования и без ИИ точно так же и происходит. Если не делать обязательное ревью самыми опытными кодерами в команде, а то и внешними экспертами, то потом можно ошалеть от того, что накодили те кто выдаёт себя даже не за джунов, а за "миддлов" а то и за "сеньоров". А при грамотном ревью и всё работает, и команда развивается.
Тоже об этом думал. Вообще я заметил общую для большинства людей особенность – если человек чем-то доволен, он может не заморачиваться на плюсы, хорошие отзывы и так далее. Но вот если испытывает малейшее несогласие или недовольство – сразу готов и минусы писать, и жалобы подавать, и всё что угодно. Я и за собой это заметил – и начал с этим работать. Например когда я ездил на такси, и поездка проходила отлично, я просто выходил и всё. Но стоило водителю как то меня огорчить, хотя бы чуть чуть, я сразу снижал оценку, и писал плохой отзыв. Далее я пересмотрел эту позицию, и сфокусировался на том, что я хотя бы чутка остался доволен, я обязательно поставлю высокую оценку, а если вообще отлично всё прошло, то и оценку высокую, и отзыв хороший, и может даже чаевые дам. А если наоборот водитель меня огорчил, то я ещё подумаю – а настолько ли это ужасно, чтобы ему снижать оценку? Надо ли вообще снижать, и насколько сильно, может до 4 или 3, а не до 1 или 2? Может проблема вообще была во мне, моём настроении, или моих необоснованных требованиях к водителю? И так далее. И вот знаете, когда я на все сферы жизни такое мышление начал применять, лично моя жизнь сильно изменилась в лучшую сторону.
Да, всё в точности так!
Хабр – стадия "ненависть" ко всем кто пишет что нейросети могут как то помочь 😁
Вы напишите свой вопрос так чтобы его нормальные люди поняли
Какой курсор? Какая структура? Какой косяк? Куда упорол?))
вы сами поняли что написали?
Благодарю за комментарий! Рад, что статья понравилась!
А то тут налетели ненавистники ИИ и айда тухлыми помидорами кидаться) Я уж в один момент подумал не зря ли я написал статью))
Я не хочу чтобы меня блокировали за рекламу. В правилах написано — упоминать название можно, ссылки давать нельзя. Так что это я не из вредности...
В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Кто такой Клод?) Я Андрей Рик 🤠
Полностью согласен с вышеописанным
В статье указано название инструмента, попробуйте его найти самостоятельно в поисковиках.
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.
Так я и сам пишу, что требует валидации. Вот часть текста одного из моих комментариев под этой же статьёй:
@BoomerCore да вы правы, эта статья никому не может принести пользу 😇 в отличие от ваших комментариев 😁
@BoomerCore я тут скорее не про вас, а про тех, насчёт которых вы утверждаете:
А по поводу подобных комментариев, именно такое впечатление и сложилось. Когда человек не пробовал, не знает какие сейчас возможности у нейросетей, и результаты какого качества они могут давать, но предполагает, что заведомо не могут ничего полезного сгенерировать, и пишет комментарии отталкиваясь от своих теоретических размышлений. А уверенность моя в этом основана, повторюсь, на личном практическом опыте.
Я уже несколько раз здесь писал, что именно декомпозируя "собственным интеллектом" задачи на мелкие, и делегируя их ИИ, и то не все, а те в которых экономия времени будет существенной, при том что процесс включает не только написание промпта, но и проверку результата, то общая экономия будет тоже существенной. И опять же, это личный практический опыт, а не предположения. И нет, не по ХХП.
Shit in - shit out согласен, об этом я и в статье пишу:
А вот LLM считает, что он является искусственным интеллектом 😁
И гугол тоже пишет, что "обзор от ИИ"
Как по мне не нужно сравнивать искусственный интеллект с человеческим. Это естественно не одно и то же, и не будет одним и тем же. У человеческого интеллекта есть свои плюсы и минусы (но не у всех людей есть интеллект 😁), у искусственного интеллекта есть свои другие плюсы и минусы.
И сила именно в объединении человеческого и искусственного интеллекта, или если вам так больше нравится, человеческого интеллекта и мощь результатов машинного обучения
С иерархией в LLM дела уже обстоят вполне себе, уважаемый. Тот же Cursor и ориентируется в существующей структуре, и сам способен создать структуру папок и файлов. Я как то проводил ревью файловой структуры не особо большого проекта, там backend с несколькими crud операциями и другой не сильно замороченной логикой, который был реализован полностью на ИИ. И я полностью одобрил структуру папок и файлов. То есть во первых она (структура) там была, а во вторых мне было не к чему придраться, чтобы сказать что что-то с ней не так.
Поэтому у штурвала ИИ должен быть именно такой человек, который способен проверить результат. Сделать ревью, и при необходимости исправить.
В командах программирования и без ИИ точно так же и происходит. Если не делать обязательное ревью самыми опытными кодерами в команде, а то и внешними экспертами, то потом можно ошалеть от того, что накодили те кто выдаёт себя даже не за джунов, а за "миддлов" а то и за "сеньоров". А при грамотном ревью и всё работает, и команда развивается.
Пример чего конкретно вы желаете, могу полюбопытствовать?)
Тоже об этом думал. Вообще я заметил общую для большинства людей особенность – если человек чем-то доволен, он может не заморачиваться на плюсы, хорошие отзывы и так далее. Но вот если испытывает малейшее несогласие или недовольство – сразу готов и минусы писать, и жалобы подавать, и всё что угодно. Я и за собой это заметил – и начал с этим работать. Например когда я ездил на такси, и поездка проходила отлично, я просто выходил и всё. Но стоило водителю как то меня огорчить, хотя бы чуть чуть, я сразу снижал оценку, и писал плохой отзыв. Далее я пересмотрел эту позицию, и сфокусировался на том, что я хотя бы чутка остался доволен, я обязательно поставлю высокую оценку, а если вообще отлично всё прошло, то и оценку высокую, и отзыв хороший, и может даже чаевые дам. А если наоборот водитель меня огорчил, то я ещё подумаю – а настолько ли это ужасно, чтобы ему снижать оценку? Надо ли вообще снижать, и насколько сильно, может до 4 или 3, а не до 1 или 2? Может проблема вообще была во мне, моём настроении, или моих необоснованных требованиях к водителю? И так далее. И вот знаете, когда я на все сферы жизни такое мышление начал применять, лично моя жизнь сильно изменилась в лучшую сторону.
Благодарю за комментарий!