←back to thread

421 points briankelly | 2 comments | | HN request time: 0.615s | source
Show context
necovek ◴[] No.43575664[source]
The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: https://github.com/dx-tooling/platform-problem-monitoring-co...

All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves, to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there...

In a nutshell, if the rest of it is like this, it simply sucks.

replies(23): >>43575714 #>>43575764 #>>43575953 #>>43576545 #>>43576732 #>>43576977 #>>43577008 #>>43577017 #>>43577193 #>>43577214 #>>43577226 #>>43577314 #>>43577850 #>>43578934 #>>43578952 #>>43578973 #>>43579760 #>>43581498 #>>43582065 #>>43583922 #>>43585046 #>>43585094 #>>43587376 #
milicat ◴[] No.43575953[source]
The more I browse through this, the more I agree. I feel like one could delete almost all comments from that project without losing any information – which means, at least the variable naming is (probably?) sensible. Then again, I don't know the application domain.

Also…

  def _save_current_date_time(current_date_time_file: str, current_date_time: str) -> None:
    with Path(current_date_time_file).open("w") as f:
      f.write(current_date_time)
there is a lot of obviously useful abstraction being missed, wasting lines of code that will all need to be maintained.

The scary thing is: I have seen professional human developers write worse code.

replies(5): >>43576009 #>>43576011 #>>43576425 #>>43579037 #>>43579215 #
ramesh31 ◴[] No.43576009[source]
>The scary thing is: I have seen professional human developers write worse code.

This is kind of the rub of it all. If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter? I mean at that point its kind of like looking at the output of a bytecode compiler and being like "wow what a mess". And it's not like they can't write code up to your stylistic standards, it's just literally a matter of prompting for that.

replies(5): >>43576193 #>>43576693 #>>43577895 #>>43578279 #>>43579014 #
dilyevsky ◴[] No.43576693[source]
what are you going to do when something suddenly doesn't work and cursor endlessly spins without progress no matter how many "please don't make mistakes" you add? delete the whole thing and try to one-shot it again?
replies(1): >>43576880 #
nsonha ◴[] No.43576880[source]
Why do you HAVE TO one-shot? No one says you have to code like those influencers. You are a software engineer, use AI like one, iteratively.
replies(2): >>43577027 #>>43577098 #
dilyevsky ◴[] No.43577098[source]
The point is because it generally produces crap code you have to one shot or else iteration becomes hard. Similar to how a junior would try to refactor their mess and just make a bigger mess
replies(1): >>43578116 #
1. nsonha ◴[] No.43578116[source]
I find it hard to believe that when the AI generates crap code, there is absolutely nothing you can do (change the prompt, modify context, add examples) to make it do what you want. It has not been my experience either. I only use AI to make small modules and refactor instead of one-shoting.

Also I find "AI makes crap code so we should give it a bigger task" illogical.

replies(1): >>43589035 #
2. mistrial9 ◴[] No.43589035[source]
it seems that there are really, really large differences between models; how well they do, what they respond to.. even among the "best" .. the field does seem to be moving faster