피드백의 속도: AI 시대의 개발자가 통제력을 유지하는 법

인간의 인지-결정-행동(PDA) 주기는 물리적 한계가 있으며, 도구의 속도가 이를 초과하면 오류를 제어하기 어려워진다.

🔗 원문 보기

AI를 사용하지 않아도 괜찮은 이유: 개발과 출판의 관점에서 본 반(反) AI 전략

AI가 생성하는 코드의 양보다 유지보수 가능하고 견고한 소프트웨어를 만드는 것이 중요하며, AI는 오히려 개발자의 통찰력을 방해할 수 있다.

🔗 원문 보기

라이브러리 영구 포크(Fork)의 트레이드오프와 리스크

오픈소스 프로젝트가 중단되었거나 팀의 패치가 거부될 때, 그리고 팀이 장기 유지보수 능력을 갖춘 경우에만 포크를 고려해야 한다.

🔗 원문 보기

[Перевод] Долг понимания — скрытая цена кода, сгенерированного искусственным интеллектом

“Долг понимания” (comprehension debt) — это скрытая цена, которую человеческий интеллект и память платят в результате чрезмерной зависимости от ИИ и автоматизации. Для инженеров это особенно актуально в сфере разработки агентных систем. Когда команды активно используют инструменты для генерации кода с помощью ИИ, возникают определенные издержки, которые не отражаются в показателях производительности. Особенно это касается случаев, когда проверка всего кода, генерируемого ИИ, становится утомительной. Эти издержки накапливаются постепенно, и в конечном итоге их приходится оплачивать — с процентами. Это называется “долг понимания” или “когнитивный долг” .

https://habr.com/ru/articles/1016680/

#code_quality #ai #artificial_intelligence #technical_debt #сomprehension_debt #качество_кода #ии #искусственный_интеллект #технический_долг #долг_понимания

A good article on technical debt that covers rarely discussed points: the "contagion" effect of a debt, and ways to classify different types of debt. https://technology.riotgames.com/news/taxonomy-tech-debt

#technical_debt #dev

А о техническом долге я скажу…

Бывало у вас такое, что приходилось вставлять не самое лучшее решение в код, только чтоб успеть сдать задачу перед условной выставкой? Или идет работа над проектом в течение уже пару месяцев, а документация откладывается на потом когда все устаканится - поздравляю, вы “счастливый” обладатель технического долга. Не стоит расстраиваться, это частая жизни, которую следует принять и проработать как на сеансе психолога для комфортной жизни в будущем. Для начала определим цель текущей работы. Это МВП для проверки бизнес-гипотезы - мы можем забыть о “техдолге” и бежать вперед для получения нужных метрик. Надо сделать пару задач, где сроки “вчера” - вставляем подходящие решения с мыслью о будущем рефакторинге. Тут главное правильно понять дальнейшее развитие проекта, чтобы после наших технических решений были понятны масштабы работ по накопившимся обязательствам. Это как с кредитом, который мы берем в банке и будем возвращать в будущем, да еще и с процентами. Проведите верхнеуровневый анализ проекта и поймите на каком вы этапе и куда хотите прийти. Картинка в помощь.

https://habr.com/ru/companies/rostelecom/articles/852188/

#технический_долг #управление_техническим_долгом #technical_debt #рефакторинг #матрица_эйзенхауэра