←back to thread

Senior Developer Skills in the AI Age

(manuel.kiessling.net)
421 points briankelly | 3 comments | 03 Apr 25 18:47 UTC | HN request time: 0.012s | source
Show context
necovek ◴[03 Apr 25 21:27 UTC] 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 ◴[03 Apr 25 21:55 UTC] 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 #
1. jstummbillig ◴[04 Apr 25 07:17 UTC] No.43579215[source]▶
> The scary thing is: I have seen professional human developers write worse code.

That's not the scary part. It's the honest part. Yes, we all have (vague) ideas of what good code looks like, and we might know it when we see it but we know what reality looks like.

I find the standard to which we hold AI in that regard slightly puzzling. If I can get the same meh-ish code for way less money and way less time, that's a stark improvement. If the premise is now "no, it also has to be something that I recognize as really good / excellent" then at least let us recognize that we have past the question if it can produce useful code.

replies(2): >>43583610 #>>43584210 #
2. necovek ◴[04 Apr 25 15:13 UTC] No.43583610[source]▶
I do believe it's amazing what we can build with AI tools today.

But whenever someone advertises how an expert will benefit from it yet they end up with crap, it's a different discussion.

As an expert, I want AI to help me produce code of similar quality faster. Anyone can find a cheaper engineer (maybe five of them?) that can produce 5-10x the code I need at much worse quality.

I will sometimes produce crappy code when I lack the time to produce higher quality code: can AI step in and make me always produce high quality code?

That's a marked improvement I would sign up for, and some seem to tout, yet I have never seen it play out.

In a sense, the world is already full of crappy code used to build crappy products: I never felt we were lacking in that department.

And I can't really rejoice if we end up with even more of it :)

3. merrywhether ◴[04 Apr 25 15:54 UTC] No.43584210[source]▶
I think there’s a difference in that this is about as good as LLM code is going to get in terms of code quality (as opposed to capability a la agentic functionality). LLM output can only be as good as its training data, and the proliferation of public LLM-generated code will only serve as a further anchor in future training. Humans on the other hand ideally will learn and improve with each code review and if they don’t want to you can replace them (to put it harshly).