| ▲ | boredtofears 10 hours ago |
| I dunno, when you've made about 10,000 clay pots its kinda nice to skip to the end result, you're probably not going to learn a ton with clay pot #10,001. You can probably come up with some pretty interesting ideas for what you want the end result to look like from the onset. I find myself being able to reach for the things that my normal pragmatist code monkey self would consider out of scope - these are often not user facing things at all but things that absolutely improve code maintenance, scalability, testing/testability, or reduce side effects. |
|
| ▲ | belZaah 9 hours ago | parent | next [-] |
| Depends on the problem. If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. Manually coding a signup flow #875 is not my idea of fun either. But if the complexity is in the implementation, it’s different. Doing complex cryptography, doing performance optimization or near-hardware stuff is just a different class of problems. |
| |
| ▲ | aleph_minus_one 7 hours ago | parent | next [-] | | > If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. The problem is rather that programmers who work on business logic often hate programmers who are actually capable of seeing (often mathematical) patterns in the business logic that could be abstracted away; in other words: many business logic programmers hate abstract mathematical stuff. So, in my opinion/experience this is a very self-inflected problem that arises from the whole culture around business logic and business logic programming. | |
| ▲ | skydhash 3 hours ago | parent | prev | next [-] | | Coding signup flow #875 should as easy as using a snippet tool or a code generator. Everyone that explains why using an LLM is a good idea always sound like living in the stone age of programming. There are already industrial level tools to get things done faster. Often so fast that I feel time being wasted describing it in english. | | |
| ▲ | boredtofears 16 minutes ago | parent [-] | | Of course I use code generation. Why would that be mutually exclusive from AI usage? Claude will take full advantage of it with proper instruction. |
| |
| ▲ | boredtofears 9 hours ago | parent | prev [-] | | In my experience AI is pretty good at performance optimizations as long as you know what to ask for. Can't speak to firmware code or complex cryptography but my hunch is if it's in it's training dataset and you know enough to guide it, it's generally pretty useful. | | |
| ▲ | kranner 8 hours ago | parent | next [-] | | > my hunch is if it's in it's training dataset and you know enough to guide it, it's generally pretty useful. Presumably humanity still has room to grow and not everything is already in the training set. | |
| ▲ | aleph_minus_one 7 hours ago | parent | prev [-] | | >
In my experience AI is pretty good at performance optimizations as long as you know what to ask for. This rather tells that the kind of performance optimizations that you ask for are very "standard". | | |
| ▲ | charcircuit 6 hours ago | parent | next [-] | | Most optimizations are making sure you do not do work that is unnecessary or that you use the hardware effectively. The standard techniques are all you need 99% of the time you are doing performance work. The hard part about performance is dedicating the time towards it and not letting it regress as you scale the team. With AI you can have agents constantly profiling the codebase identifying and optimizing hotspots as they get introduced. | | |
| ▲ | aleph_minus_one 3 hours ago | parent [-] | | > Most optimizations are making sure you [...] use the hardware effectively. If you really care about using the hardware effectively, optimizing the code is so much more than what you describe. |
| |
| ▲ | boredtofears 34 minutes ago | parent | prev [-] | | As most are |
|
|
|
|
| ▲ | bravetraveler 8 hours ago | parent | prev [-] |
| import claypot trillion dollar industry boys |
| |