[HN Gopher] Senior Developer Skills in the AI Age
___________________________________________________________________
Senior Developer Skills in the AI Age
Author : briankelly
Score : 64 points
Date : 2025-04-03 18:47 UTC (4 hours ago)
(HTM) web link (manuel.kiessling.net)
(TXT) w3m dump (manuel.kiessling.net)
| thisdougb wrote:
| This is interesting, thanks for posting. I've been searching for
| some sort of 'real' usage of AI-coding. I'm a skeptic of the
| current state of things, so it's useful to see real code.
|
| I know Python, but have been coding in Go for the last few years.
| So I'm thinking how I'd implement this in Go.
|
| There's a lot of code there. Do you think it's a lot, or it
| doesn't matter? It seems reasonably clear though, easy to
| understand.
|
| I'd have expected better documentation/in-line comments. Is that
| something that you did/didn't specify?
| Quarrelsome wrote:
| 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 all
| along, but we just lacked the tools at that time to make it work
| out.
| skizm wrote:
| Waterfall has always been the best model as long as specs are
| frozen, which is never the case.
| Quarrelsome wrote:
| 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.
| thisdougb wrote:
| 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.
| gsibble wrote:
| I completely agree, as a fellow senior coder. It allows me to
| move significantly faster through my tasks and makes me much more
| productive.
|
| It also makes coding a lot less painful because I'm not making
| typos or weird errors (since so much code autocompletes) that I
| spend less time debugging too.
| only-one1701 wrote:
| 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.
| whiplash451 wrote:
| Right, but AI could change the ratio of greenfield vs
| brownfield then (<< I'll be faster if I rewrite this part from
| scratch >>)
| robenkleene wrote:
| I struggle to wrap my head around how this would work (and
| how AI can be used to maintain and refine software in
| general). Brownfield code got brown by being useful and
| solving a real problem, and doing it well enough to be
| maintained. So the AI approach is to throwaway the code
| that's proved its usefulness? I just don't get it.
| the-grump wrote:
| My experience on brownfield projects is the opposite.
| echelon wrote:
| 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.
| dghlsakjg wrote:
| Just for the record, Photoshop's first generative 'AI'
| feature, Content Aware Fill, is 15 years old.
|
| That's a long time for Adobe not to have figured out what
| your are saying.
| necovek wrote:
| 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.
| rybosome wrote:
| 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.
| necovek wrote:
| 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).
| imiric wrote:
| > 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.
| aunty_helen wrote:
| Nah. This isn't true. Every time you hit enter you're not
| just getting a jr dev, you're getting a randomly selected jr
| dev.
|
| So, how did I end up with a logging.py, config.py, config in
| __init__.py and main.py? Well I prompted for it to fix the
| logging setup to use a specific format.
|
| I use cursor, it can spit out code at an amazing rate and
| reduced the amount of docs I need to read to get something
| done. But after its second attempt at something you need to
| jump in and do it yourself and most likely debug what was
| written.
| skydhash wrote:
| Are you reading a whole encyclopedia each time you assigned
| to a task? The one thing about learning is that it
| compounds. You get faster the longer you use a specific
| technology. So unless you use a different platform for each
| task, I don't think you have to read that much
| documentation (understanding them is another matter).
| mjr00 wrote:
| 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?
| milicat wrote:
| 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.
| ramesh31 wrote:
| >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.
| mjr00 wrote:
| > 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?
|
| You're not wrong here, but there's a big difference in
| programming one-off tooling or prototype MVPs and
| programming things that need to be maintained for years and
| years.
|
| We did this song and dance pretty recently with dynamic
| typing. Developers thought it was so much more productive
| to use dynamically typed languages, because it _is_ in the
| initial phases. Then years went by, those small, quick-to-
| make dynamic codebases ended up becoming unmaintainable
| monstrosities, and those developers who hyped up dynamic
| typing invented Python /PHP type hinting and Flow for
| JavaScript, later moving to TypeScript entirely. Nowadays
| nobody seriously recommends building long-lived systems in
| untyped languages, _but_ they are still very useful for
| one-off scripting and more interactive /exploratory work
| where correctness is less important, i.e. Jupyter
| notebooks.
|
| I wouldn't be surprised to see the same pattern happen with
| low-supervision AI code; it's great for popping out the
| first MVP, but because it generates poor code, the gung-ho
| junior devs who think they're getting 10x productivity
| gains will wisen up and realize the value of spending an
| hour thinking about proper levels of abstraction instead of
| YOLO'ing the first thing the AI spits out when they want to
| build a system that's going to be worked on by multiple
| developers for multiple years.
| fzeroracer wrote:
| At the very least, if a professional human developer writes
| garbage code you can confidently blame them and either try to
| get them to improve or reduce the impact they have on the
| project.
|
| With AI they can simply blame whatever model they used and
| continually shovel trash out there instantly.
| Aurornis wrote:
| > I feel like one could delete almost all comments from that
| project without losing any information
|
| I far from a heavy LLM coder but I've noticed a massive
| excess of unnecessary comments in most output. I'm always
| deleting the obvious ones.
|
| But then I started noticing that the comments seem to help
| the LLM navigate additional code changes. It's like a big
| trail of breadcrumbs for the LLM to parse.
|
| I wouldn't be surprised if vibe coders get trained to leave
| the excess comments in place.
| jonnycoder wrote:
| Very good concrete examples. AI is moving very fast so it can
| become overwhelming, but what has held true is focusing on
| writing thorough prompts to get the results you want.
|
| Senior developers have the experience to think through and plan
| out a new application for an AI to write. Unfortunately a lot of
| us are bogged down by working our day jobs, but we need to
| dedicate time to create our own apps with AI.
|
| Building a personal brand is never more important, so I envision
| a future where dev's have a personal website with thumbnail links
| (like a fancy youtube thumbnail) to all the small apps they have
| built. Dozens of them, maybe hundreds, all with beautiful or
| modern UIs. The prompt they used can be the new form of blog
| articles. At least that's what I plan to do.
| motorest wrote:
| What a high quality article, packed with gems. What a treat.
| datavirtue wrote:
| 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.
| rs186 wrote:
| 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.
| ramesh31 wrote:
| This maps pretty well to my experience.
|
| Other devs will say things like "AI is just a stupid glorified
| autocomplete, it will never be able to handle my Very Special
| Unique Codebase. I even spent 20 minutes one time trying out
| Cursor, and it just failed"
|
| Nope, you're just not that good obviously. I am literally 10x
| more productive at this point. Sprint goals have become single
| afternoons. If you are not tuned in to what's going on here and
| embracing it, you are going to be completely obsolete in the next
| 6 months unless you are some extremely niche high level expert.
| It wont be a dramatic moment where anyone gets "fired for AI".
| Orgs will just simply not replace people through attrition when
| they see productivity staying the same (or even increasing) as
| headcount goes down.
| __jochen__ wrote:
| That's the problem. The new norm will be 10x of pre-AI
| productivity, nobody will be able justify hand-writing code.
| And until the quality bar of LLM's/their successors get much
| better (see e.g. comments above looking at the details in the
| examples given), you'll get accumulation of errors that are
| higher than what decent programmers get. With higher LOC and
| more uninspected complexity, you'll get significantly lower
| quality overall. The coming wave of AI-coded bugs will be fun
| for all. GOTO FAIL;
| williamdclt wrote:
| Giving your anecdotal experience is only useful if you include
| anecdotal context: seniority, years of experience, technology,
| project size, sprint goal complexity...
| Denzel wrote:
| Can you talk through specifically what sprint goals you've
| completed in an afternoon? Hopefully multiple examples.
|
| Grounding these conversations in an actual reality affords more
| context for people to evaluate your claims. Otherwise it's just
| "trust me bro".
|
| And I say this as a Senior SWE who's successfully worked with
| ChatGPT to code up some prototype stuff, but haven't been able
| to dedicate 100+ hours to work through all the minutia of
| learning how to drive daily with it.
| jonnycoder wrote:
| I think experiences vary. AI can work well with greenfield
| projects, small features, and helping solve annoying
| problems. I've tried using it on a large Python Django
| codebase and it works really well if I ask for help with a
| particular function AND I give it an example to model after
| for code consistency.
|
| But I have also spent hours asking Claude and ChatGPT with
| help trying to solve several annoying Django problems and I
| have reached the point multiple times where they circle back
| and give me answers that did not previously work in the same
| context window. Eventually when I figure out the issue, I
| have fun and ask it "well does it not work as expected
| because the existing code chained multiple filter calls in
| django?" and all of a sudden the AI knows what is wrong! To
| be fair, there was only one sentence in the django
| documentation that mentions not chaining filter calls on many
| to many relationships.
___________________________________________________________________
(page generated 2025-04-03 23:00 UTC)