一位软件开发者认为，AI工具虽然看似有用，但会引入不必要的复杂性和样板代码，最终阻碍开发而非帮助开发。该开发者认为，软件开发中的核心问题源于对程序功能和状态的理解不足，而AI自动生成样板代码的倾向会掩盖这些根本性问题。这一观点与当前行业采用复杂框架和AI驱动解决方案的主流趋势形成对比，该开发者认为这会导致代码库的可维护性和可理解性降低。 AI
影响 表明AI工具可能会增加代码复杂性并阻碍理解，与其预期益处背道而驰。
排序理由 该集群包含来自Mastodon上单一用户的观点帖子，表达了对AI在软件开发中的批判性看法。
在 Mastodon — mastodon.social 阅读 →
AI 生成摘要 · Google Gemini · 来自 13 个来源。 我们如何撰写摘要 →
完整方法见我们的编辑标准。
I can tell when I'm looking at a new codebase whether the author: A) is deeply entrenched in Silicon Valley culture and industry, or B) just kinda self-taught themselves software Not by their code quality, but by how much extra bullshit their codebase has strapped onto it. #AI
But I remember that I couldn't get people to agree that needing to create 3 files to add a route or a component to your program is a serious issue. So it's not super surprising that it's hard to get them to understand that automating that is also kind of a problem for the same re…
But it's also sort of about why I think there's a disconnect between programmers on this. It is so totally obvious to me why AI is bad for these tasks, because in general, BOILERPLATE is bad. This stuff should feel bad to use because it's a sign something is wrong with your codeb…
Anyway none of this has been about AI, but actually literally ALL of it is about AI, and about why how even if this shit wasn't so unethical, I still wouldn't let it touch my codebases. "Ah, but AI can help EXPLAIN-" If you need it to do that, your code is too complex. Fix your c…
The VAST majority of bugs in software come from: A) not understanding what a program is ACTUALLY doing B) not understanding what its current state is EVERYTHING becomes easier when you address those problems. But this is actually a really surprisingly contentious thing to say. #A…
But I would get SO much pushback about this stuff. We can't have a singleton data source, we gotta have a framework that passes state down the React tree and makes it impossible to do efficient rendering. We can't connect to a database, there needs to be a vendor-agnostic databas…
That ability to think about literally the entire codebase at the same time - and to eat some of the upfront cost of sometimes working at a lower level so I wouldn't have to juggle abstractions - made my programming a lot simpler and a lot more ambitious. To me this is common sens…
I found that I was able to build much more complicated programs because I aggressively culled complexity that wasn't needed. As a result, I could build some really complicated stuff while keeping the entire codebase in my head at the same time. #AI
A lot of open source got dominated by companies like Facebook shipping projects that were designed for 3 million line codebases with teams spread across 3 continents. But that became the STANDARD architecture for every project. When I did indie game development, my process was di…
Them: "But this is making it so much easier to wire tasks together in a-" Me: "Your Gulp file is twice the size that a simple Node script would be." Them: "But it's easier to understand-" Me: "I have to talk to 3 engineers to update it. Look at this - do you know how it works?" #…
A large part of my programming career at the time involved me focusing on ways to *remove* code. I remember working with a company using Gulp for their build process and I pointed out at some point - this is MORE code than you would write in a pure Node file. [...] #AI
To me this was the most common-sense idea in the entire world - abstractions are useful and I use them, but strictly speaking, they always increase the complexity of your codebase because now you have both the conceptual abstraction AND implementation to think about. To me this w…
Many many years ago I gave a talk at a couple of local conferences and online about how over-abstracting code and can sometimes make codebases *less* maintainable than if you just worked closer to the metal, and I was so surprised at the time how much pushback I got about that. #…