Азимов формулировал их для роботов, но по сути это про любой интеллект, принимающий решения самостоятельно — неважно, железо или код. Другой вопрос, способен ли ИИ в принципе следовать таким законам. Он оперирует вероятностями, а не этикой. Для него "не навреди" — это статистика, а не принцип.
Именно так. На основе данных когда-то принимались решения о логике в коде. Когда данные теряются или меняют структуру — вместе с ними теряются предпосылки, почему код написан именно так. Код остаётся, а контекст его появления — нет. И уже никто не скажет, это ошибка, задуманное поведение или костыль под особенность данных, которых давно нет.
Мы просто смотрим с разных сторон. Вы — с позиции сильного специалиста, который придёт и решит проблему. Я — с позиции, что если выстроены процессы и стандарты, то не один человек в команде способен это сделать, а каждый. И уход любого из них не становится катастрофой.
Собственно, это и есть разница между уровнем 2 («У нас есть Петя, он это умеет») и уровнем 3+ в модели. Пока Петя на месте — всё работает. Но стоит ему уйти в отпуск или уволиться — и процесс встаёт. Модель как раз про то, чтобы от этой зависимости уйти.
Мне кажется, тут есть смещение фокуса. Никто не спорит, что конечная метрика для бизнеса — это деньги. Но это всё равно что сказать сантехнику: "Единственное, что важно — чтобы вода текла и не протекало". Верно. Но если сантехник хочет, чтобы у него это получалось стабильно, предсказуемо и без аварий по ночам — ему полезно понимать, как у него устроены процессы: есть ли чек-листы при сдаче, как он проверяет качество соединений, ведёт ли учёт материалов. И если кто-то систематизирует этот опыт и скажет: "Вот пять уровней того, как сантехническая бригада может быть организована" — это не мерилка, а навигатор.
Модель зрелости — это не способ померяться. Это внутренний инструмент, чтобы команда видела, где у неё сильные стороны, а где точки роста. Подобные модели существуют в самых разных инженерных практиках — DORA, CMMI, Spotify Health Check — и никого не смущает, что они не измеряют напрямую выручку. Они помогают выстроить работу так, чтобы выручка не терялась из-за хаоса в процессах.
Азимов формулировал их для роботов, но по сути это про любой интеллект, принимающий решения самостоятельно — неважно, железо или код. Другой вопрос, способен ли ИИ в принципе следовать таким законам. Он оперирует вероятностями, а не этикой. Для него "не навреди" — это статистика, а не принцип.
Именно так. На основе данных когда-то принимались решения о логике в коде. Когда данные теряются или меняют структуру — вместе с ними теряются предпосылки, почему код написан именно так. Код остаётся, а контекст его появления — нет. И уже никто не скажет, это ошибка, задуманное поведение или костыль под особенность данных, которых давно нет.
Или не закомментированного, но при этом он нигде не используется :)
Мы просто смотрим с разных сторон. Вы — с позиции сильного специалиста, который придёт и решит проблему. Я — с позиции, что если выстроены процессы и стандарты, то не один человек в команде способен это сделать, а каждый. И уход любого из них не становится катастрофой.
Собственно, это и есть разница между уровнем 2 («У нас есть Петя, он это умеет») и уровнем 3+ в модели. Пока Петя на месте — всё работает. Но стоит ему уйти в отпуск или уволиться — и процесс встаёт. Модель как раз про то, чтобы от этой зависимости уйти.
Мне кажется, тут есть смещение фокуса. Никто не спорит, что конечная метрика для бизнеса — это деньги. Но это всё равно что сказать сантехнику: "Единственное, что важно — чтобы вода текла и не протекало". Верно. Но если сантехник хочет, чтобы у него это получалось стабильно, предсказуемо и без аварий по ночам — ему полезно понимать, как у него устроены процессы: есть ли чек-листы при сдаче, как он проверяет качество соединений, ведёт ли учёт материалов. И если кто-то систематизирует этот опыт и скажет: "Вот пять уровней того, как сантехническая бригада может быть организована" — это не мерилка, а навигатор.
Модель зрелости — это не способ померяться. Это внутренний инструмент, чтобы команда видела, где у неё сильные стороны, а где точки роста. Подобные модели существуют в самых разных инженерных практиках — DORA, CMMI, Spotify Health Check — и никого не смущает, что они не измеряют напрямую выручку. Они помогают выстроить работу так, чтобы выручка не терялась из-за хаоса в процессах.