Hacker News Reader

ON TOP OF IT ALL, juniors are the ones who bring novel tools to the desk MOST times...i.e. I had no clue the Google IDE gave you free unlimited credits despite the terrible UI...but a young engineer told me about it!!

I'm just shocked people aren't clueing into the fact that tech companies are trying to build developer dependence on these things to secure a "rent" revenue stream. But hey, what do I know. It's just cloud hyper scaling all over again. Don't buy and drive your own hardware. Rent ours! Look, we built the metering and everything!

I'd hope people are. It's painfully obvious this entire AI push is rent-seeking half hidden by big tech money. At some point the free money is going to go away, but the rent for every service will remain.

I'm clued in to that but at this point who cares. All the models are fungible for the coding assistance use case.

you will be able to run code assistants on your own machine soon, just like how you can run intense graphical simulations (videogames?) thanks to GPUs

idk about that with the rising cost of hardware. But I guess if your IT dept is doing the purchasing thats not really your problem.

I've seen seniors and juniors bring novel tools in. Seniors do it less often perhaps - but only because we have seen this before under a different name and realize it isn't novel. (sometimes the time has finally come, sometimes it fail again for the same reason it failed last time)

I've seen seniors bring up novel ideas to juniors—well, novel to the juniors anyway.

Just an example. I've been in so many code bases over the years… I had a newer engineer come aboard who, when he saw some code I recently wrote with labels (!) he kind of blanched. He thought "goto == BAD". (We're talking "C" here.)

But this was code that dealt with Apple's CoreFoundation. More or less every call to CF can fail (which means returning NULL in the CF API). And (relevant) passing NULL to a CF call, like when trying to append a CF object to a CF array, was a hard crash. CF does no param checking. (Why, that would slow it down—you, dear reader, are to do all the sanity checking.)

So you might have code similar to:

CFDictionary dict = NULL;

dict = CFCreateDictionary();

if (!dict)

    goto bail;

You would likely continue to create arrays, etc—insert them into your dictionary, maybe return the dictionary at the end. And again, you checked for NULL at every call to CF, goto bail if needed.

Down past 'bail' you could CFRelease() all the non-null instances that you do not return. This was how we collected our own garbage. :-)

In any event, goto labels made the code cleaner: your NULL-checking if-statements did not have to nest crazy deep.

The new engineer admitted surprise that there might be a place for labels. (Or, you know, CF could have been more NULL-tolerant and simply exited gracefully.)

I work at a place with lots of rules around what can and can’t be used. When someone new start we end up spending a lot of time policing to make sure they aren’t using stuff they should be.

A very basic example were the interns who constantly tried to use Google Docs for everything, their personal accounts no less. I had to stop them and point them back to MS Office at least a dozen times.

In other situations, people will try and use free tools that don’t scale well, because that’s what they used in college or as a hobby. It can take a lot of work to point them to the enterprise solution that is already approved and integrated with everything. A basic example of this would be someone using Ansible from their laptop when we have Ansible Automation Platform, which is better optimized for running jobs around the globe and automatically logs to Splunk to create an audit trail.

Are you talking about Antigravity, Firebase Studio, or something else?

Antigravity: https://antigravity.google/pricing

"BUT I see juniors often are the ones who actually understand AI tools better than seniors"

Sorry, what does that mean exactly ? Are you claiming that a junior dev knows how to ask the right prompts better than a Senior dev ?

Their implication is that junior devs have more likely built up their workflow around the use of AI tooling, likely because if they're younger they'll have had more plasticity in their process to adapt AI tooling

Overall I don't quite agree. Personally this applies to me, I've been using vim for the last decade so any AI tooling that wants me to run some electron app is a non starter. But many of my senior peers coming from VS Code have no such barriers

Speaking of vim - adding and configuring copilot plugin for vim is easy (it runs a nodejs app in the background but if you have spare 500 Mb RAM it's invisible).

Copilot in vim is not the same as cursor. e.g. There is no multiline tab autocomplete.

All the major players offer a CLI, for what it’s worth.

You won’t need Vim except to review changes and tweak some things if you feel like it.

Some old dogs resist learning new tricks.

If AI is just prompts to you, you fall into the "don't know how to use it" group.

Speaking as a senior dev, anecdotally juniors may indeed understand AI tools better, because they spend more hours a day coding and working with the tools, and they need the tools to understand the codebase or to be productive. Seniors have more hours stuck in meetings, developing specs/tickets for the juniors, code reviewing, etc. Seniors are likely to not bother with a prompt for simple changes in codebases they already understand.

> He said juniors are usually the most experienced with AI tools, so cutting them makes no sense.

While anyone is free to define words as they so please, most people consider those with the most experience to be seniors. I am pretty sure that has been the message around this all along: Do not cut the seniors. The label you choose isn't significant. Whether you want to call them juniors or seniors, it has always been considered to make no sense to cut those with the most experience.

No, he’s saying that juniors, while having less experience ind development in general have more experience with AI tools. (This may be true broadly, certainly less experienced devs generally, IME, seem more enthusiastic about adopting and relying heavily on AI tooling.)

While, again, anyone can define words as they see fit, most people consider the "junior" and "senior" labels to apply to the activity being conducted, not something off to the side. As the job is to use AI tools, these most experienced people would be considered "seniors" by most. Nobody was ever suggesting that you should cut good help because they're juniors in knitting or dirt biking.

No, the job is to develop software. Using AI tools is one piece of the job. Having less experience with the job overall and more experience with one piece is a thing that happens.

The job is never to develop software. The job is always to solve problems for customers. Developing software is just a tool in the toolbox. As is, increasingly, using AI. As such, it is valuable to have those who are experienced in using AI on staff.

Which is nothing new. It has always been understood that it is valuable to have experienced people on board. The "cut the juniors" talk has never been about letting those who offer value go. Trying to frame it as being about those who offer experiential value — just not in the places you've arbitrary chosen — is absurd.

> As the job is to use AI tools

Aside from the absurdity of this claim, consider how many years of experience a "senior" is typically expected to have, and then consider how long even ChatGPT has been available to the public, never mind SOTA coding agents.

> consider how many years of experience a "senior" is typically expected to have

That entirely depends on what the experience is towards. If it is something like farming where you only get to experience a different scenario once per year due to worldly constraints, then one would expect many years — decades, even — before considering someone "senior".

But when the domain allows experiencing a new scenario every handful of milliseconds, you can shorten that tremendously. In that case, a couple of years is more than enough time to become a "senior" even with only a modicum of attention given to it. If you haven't "seen it all" after a couple of years in that kind of environment, you're never going to become "senior" as you are hardly engaging with it at all.

Amazon has an internal platform for building software. The workflows are documented and have checks and balances. So the CEO wants to have more junior developer that are more proficient with AI, and have (in ratio) less senior developers. Also, product context comes from (product) managers, UX designers.

For medium or small companies, these guardrails or documentation can be missing. In that case you need experienced people to help out.

you're right but my opinion about this has changed

I would have agreed with you 100% one year ago. Basically senior engineers are too complacent to look at AI tools as well as ego driven about it, all while corporate policy disincentivizes them from using anything at all, with maybe a forced Co-Pilot subscription. While junior engineers will take a risk that the corporate monitoring of cloud AI tools isn't that robust.

But now, although many of those organizations are still the same - with more contrived Co-Pilot subscriptions - I think senior engineers are skirting corporate policy too and become more familiar with tools.

I'm also currently in an organization that is a total free for all with as many AI coding and usage tools as necessary to deliver faster. So I could be out of touch already.

Perhaps more complacent firms are the same as they were a year ago.

Sorry but what the heck is up with all the ellipses in this comment?

They're trying really hard to make sure you know they didn't write their post with an LLM? /s

honestly i think that'll be a thing in the future

"bespoke, hand generated content straight to your best readers"

Nah, models can be fine tuned and trained on anything. Common consumer products like ChatGPT and Gemini have particular styles, very polite and helpful, but there are models trained to be combatative, models trained to write in the style of shakespeare, all sorts of things. Someone could train a model to reply to posts in the style of HN comments and you’d probably never know.

Because LLMs would use unicode Horizontal Ellipsis…

https://www.compart.com/en/unicode/U+2026

They have an emacs package that triples their . automatically!

It's a sort of stream of consciousness. That style of writing goes in and out of style from time to time but some people use it consistently.

> I'm seeing a pattern...

Me too. Fire your senior devs. (Ha ha, not ha ha.)

No no, fire them.

Cannot wait for the 'Oh dear god everything is on fire, where is the senior dev?' return pay packages.

I love that the dominant narrative with modern AI is "figure out who we can fire" pronto. I don't see a clear pattnern with juniors and seniors and AI. I know some younger engineers who are not embracing AI tools at all.

I'd say that AI tools make good engineers better and more productive and makes bad engineers appear to be more productive but ultimately makes them shoot themselves in the foot more thoroughly and quickly, while also piling up more work for everyone else.

Maybe, but you make it sound like juniors are more worthy to companies than seniors. Then fire most/all seniors and good luck with resulting situation.

Coding in any sufficiently large organization is never the main part of senior's time spend, unless its some code sweatshop. Juniors can do little to no of all that remaining glue that makes projects go from a quick brainstorming meeting to live well functioning and supported product.

So as for worth - companies can, in non-idedal fashion obviously, work without juniors. I can't imagine them working without seniors, unless its some sort of quick churn of CRUDs or eshops from some templates.

Also there is this little topic that resonates recently across various research - knowledge gained fast via llms is a shallow one, doesn't last that long and doesn't go deeper. One example out of many - any time I had to do some more sophisticated regex-based processing I dived deep into specs, implementation etc. and few times pushed it to the limits (or realized task is beyond what regex can do), instead of just given the result, copypasted it and moved along since some basic test succeeded. Spread this approach across many other complex topics. That's also a view on long term future of companies.

I get what you say and I agree partially but its a double edged sword.

7/10 senior devs (usually fellas 50+) will get mad at you for trying to use Claude Code. Me: “dude it writes better code than crap you write in your mush middle-age brain.” Also me: “I also have mush brain.”

I think LLM is a reflection of human intelligence. If we humans become dumber as a result of LLM, LLMs will also become dumber. I’d like to think in some dystopian world, LLM’s trained from pre 2023 data will be sought after.

> 7/10 senior devs (usually fellas 50+) will get mad at you for trying to use Claude Code

Ironic because the junior has much more to lose. The 50+ can probably coast across the finish line.

is this just a janky summary cause you added zero new viewpoints