7 ms·
It wouldn't be unreasonable to expect just that. Overall, producing code quicker is probably not something we need. It's plenty quick to type code. What's slow
by marginalia_nu 4y ago
It wouldn't be unreasonable to expect just that. Overall, producing code quicker is probably not something we need. It's plenty quick to type code. What's slow is finding good designs. I think more often than not, we jump to the coding part too early and build things too soon. This creates problems that are hard to fix after the fact.
The easier it is to produce code, the more code will be produced. The more code is produced, the more complex and short-sighted the architecture will be as a result.
This is much older than AI. You can take a one-person task that takes two weeks to perform, assign it to a five person team, and they'll solve it by producing 25 times the code.
We create abstractions to cope with the noise of a large code base, but in doing so, we also create a noisier and more complex code base that needs more abstractions.
- wnkrshm 4y agoManaging complexity was once the job description
- _bohm 4y agoYeah I think there's a lot of sense in that. I think it's likely that the ability to use these tools in a disciplined fashion will grow to be a significant differentiator between more effective and less effective programmers. The former taking a considered approach to design and then using the tools where they're a real force multiplier e.g., writing unit tests, and the latter prompting them to spit out large swaths of code they would have previously written by hand: "write an endpoint that does X".