Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Senior Developer Skills in the AI Age

manuel.kiessling.net

Post reply on HN
Print view View original

11–20 of 323 posts

Re: Senior Developer Skills in the AI Age

#11

Post by rybosome »

necovek wrote: post #9

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,…

Ok - not wrong at all. Now take that feedback and put it in a prompt back to the LLM.

They’re very good at honing bad code into good code with good feedback. And when you can describe good code faster than you can write it - for instance it uses a library you’re not intimately familiar with - this kind of coding can be enormously productive.

Re: Senior Developer Skills in the AI Age

#13

Post by mjr00 »

necovek wrote: post #9

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,…

I "love" this part:

  def ensure_dir_exists(path: str) -> None:
    """
    Ensure a directory exists.

    Args:
        path: Directory path
    """
An extremely useful and insightful comment. Then you look where it's actually used,

    # Ensure the directory exists and is writable
    ensure_dir_exists(work_dir)

    work_path = Path(work_dir)
    if not work_path.exists() or not os.access(work_dir, os.W_OK):
... so like, the entire function and its call (and its needlessly verbose comment) could be removed because the existence of the directory is being checked anyway by pathlib.

This might not matter here because it's a small, trivial example, but if you have 10, 50, 100, 500 developers working on a codebase, and they're all thoughtlessly slinging code like this in, you're going to have a dumpster fire soon enough.

I honestly think "vibe coding" is the best use case for AI coding, because at least then you're fully aware the code is throwaway shit and don't pretend otherwise.

edit: and actually looking deeper, `ensure_dir_exists` actually makes the directory, except it's already been made before the function is called so... sigh. Code reviews are going to be pretty tedious in the coming years, aren't they?

Re: Senior Developer Skills in the AI Age

#14

Post by echelon »

only-one1701 wrote: post #5

Increasingly I’m realizing that in most cases there is a SIGNIFICANT difference between how useful AI is on greenfield projects vs how useful it is on brownfield projects. For the former: pretty good! For the brownfield, it’s often worse than useless.

I think there's a similar analogy here for products in the AI era.

Bolting AI onto existing products probably doesn't make sense. AI is going to produce an entirely new set of products with AI-first creation modalities.

You don't need AI in Photoshop / Gimp / Krita to manipulate images. You need a brand new AI-first creation tool that uses your mouse inputs like magic to create images. Image creation looks nothing like it did in the past.

You don't need Figma to design a webpage. You need an AI-first tool that creates the output - Lovable, V0, etc. are becoming that.

You don't need AI in your IDE. Your IDE needs to be built around AI. And perhaps eventually even programming languages and libraries themselves need AI annotations or ASTs.

You don't need AI in Docs / Gmail / Sheets. You're going to be creating documents from scratch (maybe pasting things in). "My presentation has these ideas, figures, and facts" is much different than creating and editing the structure from scratch.

There is so much new stuff to build, and the old tools are all going to die.

I'd be shocked if anyone is using Gimp, Blender, Photoshop, Premiere, PowerPoint, etc. in ten years. These are all going to be reinvented. The only way these products themselves survive is if they undergo tectonic shifts in development and an eventual complete rewrite.

Re: Senior Developer Skills in the AI Age

#15

Post by datavirtue »

That free GitHub Copilot though. Microsoft is a relentless drug dealer. If you haven't tried Copilot Edits yet, hold on to your hat. I started using it in a clean Express project and a Vue3 project in VS Code. Basically flawless edits from prompt over multiple files, new files...the works. Easy.

Re: Senior Developer Skills in the AI Age

#16

Post by necovek »

rybosome wrote: post #11
necovek wrote: post #9

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,…

Ok - not wrong at all. Now take that feedback and put it in a prompt back to the LLM. They’re very good at honing bad code into good code with good feedback. And when you can describe good code faster than you can write it - for instance it uses a library you’re not intimately familiar with - this kind of coding can be enormously productive.

I do plan on experimenting with the latest versions of coding assistants, but last I tried them (6 months ago), none could satisfy all of the requirements at the same time.

Perhaps there is simply too much crappy Python code around that they were trained on as Python is frequently used for "scripting".

Perhaps the field has moved on and I need to try again.

But looking at this, it would still be faster for me to type this out myself than go through multiple rounds of reviews and prompts.

Really, a senior has not reviewed this, no matter their language (raciness throughout, not just this file).

Re: Senior Developer Skills in the AI Age

#17

Post by Quarrelsome »

skizm wrote: post #6
Quarrelsome wrote: post #3

This is extremely fascinating and finally something that feels extremely tangible as opposed to vibes based ideas around how AI will "take everyone's jobs" while failing to fill in the gaps between. This feels extremely gap filling. I find it quite interesting how we can do a very large chunk of the work up front in design, in order to automate the rest of the work. Its almost as if waterfall was the better pattern a…

Waterfall has always been the best model as long as specs are frozen, which is never the case.

sure, but if you're generating the code in a very small amount of time from the specs then suddenly its no longer the code that is the source, its the specs.

That's what waterfall always wanted to be and it failed because writing the code usually took a lot longer than writing the specs, but now perhaps, that is no longer the case.

Re: Senior Developer Skills in the AI Age

#18

Post by imiric »

rybosome wrote: post #11
necovek wrote: post #9

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,…

Ok - not wrong at all. Now take that feedback and put it in a prompt back to the LLM. They’re very good at honing bad code into good code with good feedback. And when you can describe good code faster than you can write it - for instance it uses a library you’re not intimately familiar with - this kind of coding can be enormously productive.

> They’re very good at honing bad code into good code with good feedback.

And they're very bad at keeping other code good across iterations. So you might find that while they might've fixed the specific thing you asked for—in the best case scenario, assuming no hallucinations and such—they inadvertently broke something else. So this quickly becomes a game of whack-a-mole, at which point it's safer, quicker, and easier to fix it yourself. IME the chance of this happening is directly proportional to the length of the context.

Re: Senior Developer Skills in the AI Age

#19

Post by rs186 »

That prompt looks horrifying.

I am not going to spend half an hour coming up with that prompt, tweaking it, and then spend many hours (on the optimistic side) to track down all the hallucinated code and hidden bugs. Have been there once, never going to do that again.

I'd rather do it myself to have a piece of mind.

Re: Senior Developer Skills in the AI Age

#20

Post by thisdougb »

skizm wrote: post #6
Quarrelsome wrote: post #3

This is extremely fascinating and finally something that feels extremely tangible as opposed to vibes based ideas around how AI will "take everyone's jobs" while failing to fill in the gaps between. This feels extremely gap filling. I find it quite interesting how we can do a very large chunk of the work up front in design, in order to automate the rest of the work. Its almost as if waterfall was the better pattern a…

Waterfall has always been the best model as long as specs are frozen, which is never the case.

When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features.

Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.

Specs were never frozen with waterfall.

Post reply on HN