| ▲ | deadbabe 11 hours ago |
| Customer doesn’t give a fuck how long a billing system took to make, they only care that it works correctly. A billing system only truly gets built once, then possibly maintained in perpetuity. This makes the advantage of building it 20x times faster pointless. AI builds it in a day, will it matter 5 years from now if that billing system was instead built by hand in 20 days a long time ago? No. The speed advantage of AI only comes into play when you have a lot of code to crank out continuously. Do you have a need to constantly build bespoke billing systems at a rate of 1 per day? Probably not. So who cares. Take your little AI grift charging $1000/month somewhere else. It’s not needed. |
|
| ▲ | JPKab 6 hours ago | parent | next [-] |
| They care how much you charge them to build it, and they care how fast you deliver it to them. The idea that they don't makes me question whether or not you have ever been self-employed in your entire life. This kind of thinking makes me think you have always been a drone getting paid by a boss. |
|
| ▲ | bluGill 11 hours ago | parent | prev | next [-] |
| Every billing system in use is constantly maintained with new features, bug fixes ane the like. The system of 20 years ago would apply the wrong tax laws today. the people asking for the new feature today care about how easy those are to add |
| |
| ▲ | prewett 11 hours ago | parent [-] | | I think adding new features is exactly the sort of place where AI is terrible, at least after you do it for a while. I think it's going to have a tendency to regenerate the whole function(s), but it's not deterministic. Plus, as others have said, the code isn't clean. So you're going to get accretions of messy code, the actual implementation of which will change around each time it gets generated. Anything not clearly specified is apt to get changed, which will probably cause regressions. I had AI write some graphs in D3.js recently, and as I asked for different things, the colors would change, how (if) the font sizes were specified would change, all kinds of minor things. I didn't care, because I modified the output by hand, and it was short. But this is not the sort of behavior I want my code output to have. I think after a while the accretions are going to get slow, and probably unmaintainable even for AI. And by that time, the code will be completely unreadable. It will probably make the code written by people who probably should not be developers that I have had to clean up look fairly straightforward in comparison. | | |
| ▲ | JPKab 6 hours ago | parent | next [-] | | "The code isn't clean" Skill issue. If you just one-shot everything, sure, you'll get a messy codebase. But if you just manage it like a talented junior dev, review the code, provide feedback, and iterate, you get very clean code. Minus the arguing you get from some OCD moron human who is attached to their weird line length formatting quirk. | |
| ▲ | bluGill 11 hours ago | parent | prev [-] | | That is why I understand everything before I commit. Ai can write a lot of bad code - but an expert can guide it to good code. | | |
| ▲ | deadbabe 6 hours ago | parent [-] | | After a while why wouldn’t the expert just write the good code if the AI never truly learns? | | |
| ▲ | bluGill 2 hours ago | parent [-] | | Because the ai can write the tedious parts fast. you have to check but that is faster than writing. |
|
|
|
|
|
| ▲ | nickrivadeneira 11 hours ago | parent | prev [-] |
| The customer cares how much it costs. And how much it costs is proportionate to how much time it takes to build. You’re conveniently ignoring market and price dynamics |