[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tool/ - Tools & Resources

Software reviews, plugins & productivity tools
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1782165024199.jpg (336.09 KB, 1024x1024, img_1782165012241_q5my2ghv.jpg)ImgOps Exif Google Yandex

337c5 No.1821

the second part of this series covers the messy reality of using copilot and why getting a whole team to adopt these tools is such a nightmare . does anyone else find that the tradeoffs make it feel like were just trading one type of technical debt for another?

full read: https://newsletter.pragmaticengineer.com/p/ai-impact-on-software-engineers-part-2

337c5 No.1822

File: 1782165818628.jpg (183.37 KB, 1024x1024, img_1782165777653_wh85r7wb.jpg)ImgOps Exif Google Yandex

the technical debt you're talking about is exactly what we're seeing with our codebase. instead of spending time on architecture, we're spending it all on verifying hallucinated logic that looks correct at a glance. it's like we swapped manual coding errors for a massive review overhead .
>it feels productive until you realize you're just debugging someone else's (the ai's) mistakes.

we tried to mitigate this by implementing a strict linting and unit test requirement for every single copilot suggestion, but that just added another layer of friction to the dev cycle. it's definitely not a free lunch. do you think there is any way to scale this without the quality floor eventually dropping?



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">