Although I am all for freedom, one forgets that this is one of the few places left on internet where discussions feel meaningful and I am not judging you if you want AI but do it at your own discretion using chatbots.
If you want, you can even hack around a simple extension (tampermonkey etc.) where you can have a button which can do this for you if you really so desire.
Ended up being bored and asked chatgpt to do this but chatgpt is having something wrong, it got just blinking mode so I asked claude web (4.5 sonnet) to do it and I ended up building it with tampermonkey script.
I was just writing this comment and I just got curious I guess so in the end ended up building it.
Although Edit: Thinking about it, I felt that we should read other people's articles as well. I just created this tool not out of endorsement of idea or anything but just curiosity or boredom but I think that we should probably read the articles themselves instead of asking chatgpt or LLM's about it.
There is this quote which I remembered right now
If something is worth talking/discussing about, its worth writing
If something is worth writing, then its worth reading.
Information that we write is fundamentally subjective (our writing style etc with our biases etc.), passing it through a black box which will try to homogenify all of it just feels like it misses the point.
<s>I'm not entirely sure but I think</s> if the file name ends with .user.js like HN%20ChatGPT%20Summarize.user.js it will prompt to install when opening the raw file.
Alright so I did change the name of the file from HN ChatGPT Summarize.js to hn-summarize-ai.user.js
Is this what you are talking about? If you need any cooperation from my side lemme know, I don't know too much about tampermonkey but I end up using it for my mini scripts because its way much easier to deal with compared to building pure extensions themselves and these have their own editors as well so I just copy paste for a faster way to prototype with stuff like this
Fair I guess, I think I myself might use it when sometimes the articles are more dense than my liking perhaps. As I said, I just built it out of curiosity but also a solution to their problem because I didnt like the idea of having an AI generated summary in the comments.
I mean, they didn't bury it far in the article, it's like a two second skim into it and it's labelled with a tl;dr. Not a bad idea in general but you don't even need it for this one.
My friend moved into one two months ago that had no fridge. I've seen a handful of similar units. Perhaps it's the price bracket you're looking in? These are often cheap apartments.
This post has aged like milk given the rollback. In the amount of time it's taken them to fix it, including lobbying xterm.js upstream and telling users "use a modern terminal emulator", you'd be hard-pressed to convince me they'd have burned more goodwill with paying customers than they already have if they'd quietly switched to alt-mode. It's a downright embarrassing bug for such a high-profile company.
Imagine if society were a program and laws, policies and procedures were its codebase. The scary thing is that the way it gets patched in reality isn't very different from the way agentic LLMs perform on actual codebases today. Bug in this department? Delete it. People abuse this system? Add more friction for legitimate users. Society has a need? Greenfield a feature that works great but doesn't fit in with existing systems at all. This didn't used to be so on the nose. I can't decide if we should welcome our new robot overlords or even what is a reflection of who anymore.
> For packages typed with JSDoc, CTRL/CMD clicking on a function will take you to actual code rather than a type declarations file. I much prefer this experience as a dev.
More broadly, this is the default behavior of JS even without JSDoc blocks, and it ought to be the default behavior everywhere, including TS. I'm not alone in this sentiment, but it's incredibly contentious. There's been an open GH issue about it with hundreds of replies for years. I have no idea why they can't just pick a different shortcut for viewing types and call it a day. They'd be doing the entire ecosystem a favor.
If only we could take output and reverse-engineer activation layers through some parameters and get the original prompt. Imagine how much time we could save if we could read the chat transcript or the two actually human-written paragraphs this article was based on. They'd be some banal rant about a DevRel dude but at least it'd be more efficient.
Would be nice but you could probably edit it enough or splice different chat outputs together to break it.
Honestly with the way the world is going, you might as well just ask AI to generate the chat logs from the article. Who cares if it's remotely accurate, doesn't seem like anyone cares when it comes to anything else anyways.
GitHub wants to sell a service. Keys are convenient. Better alternatives in authorization and authentication exist, and GitHub is very aware of them. They even offer and facilitate them. For example, see OIDC. But many users either want keys because they're used to them or GitHub is sure they do, so they continue to offer them to avoid friction. The alternatives require more parameters, thought, and coordination between services.
GitHub has deprecated classic tokens, but the new tokens are not backwards compatible. The deprecated tokens have also continued to be available for some time. Real security professionals will tell you flatly "tokens are bad", and they're right. They're leakable attack vectors. The tokens are the problem and discontinuation is the solution. Scanning is simply symptom treating, and given what I know about Microsoft culture, I doubt that's going to change soon or quickly.
This article talks a lot about AI, but what I find odd is that in my relatively short (but long enough) ~9 yr career so far, this problem predates AI. I don't deny that it exacerbates it, but you don't kill a disease by addressing the symptoms. From the first time I was ever involved in the hiring process, senior leadership always encouraged me to hire more experienced staff, always most heavily scrutinized juniors, and had negotiations fall through with mid-level candidates the most. This was despite juniors passing technical screens with strong showings. This was not at a Fortune 500. This was a micro-cap subsidiary of a private, billion dollar company.
And although it hasn't discouraged me, I have to admit that I've been burned by juniors when caught in the middle between them and senior leadership on output expectations or strategy because frankly it's much more challenging to mentor how to navigate company politics than it is to mentor professional coding acumen. I want to be humble here. I don't think that's the junior's fault.
It feels like these problems go a lot deeper than AI. Most shops want software teams that are either silently embedded black boxes that you insert rough instructions into and get working software as output or an outsourced team. We've all experienced this. It seems silly to deny that it's directly related to why it's so hard to mentor or hire juniors.
You're not wrong! I'm the original author of the post, and yes, I've seen this trend for years now, too, but I was using those two research studies that I cited as the basis of the article, so I started looking at it from that lens. I think the problems go deeper than AI, too, which is why I touched on corporate incentives. Ultimately, my goal was just for teams to think about how it could benefit them to invest in juniors and for college students to know that they need to prepare for a challenging ride if they're majoring in an AI-adopting field.
We may have some things in common. I'm not a mom, but I am a woman. And I don't want to assume the same is true for you, but breaking into this industry was difficult for me, so even without children, I'm really invested in the ability for juniors to succeed too. I wish I had responded more directly to your article rather than my general ennui. I really admire your willingness to write this. I hope it gets broad engagement, because I think these problems seem obvious to us but based on private conversations I've had with some industry peers in very senior director roles the drying of junior opportunities for growth is not readily obvious to them. I'm going to have to think more about the corporate incentives you mentioned, because reading that in the article, it feels deeper to me, and I think that's what I was trying to get at by sharing my past company details.
I think you succeeded overall at your goal! Thanks for replying. You encouraged me to go back and read your article more closely.
I appreciate the positive feedback. :) And yes, I was a career changer, so it was difficult for me to break into tech, too, so it feels a bit personal for that reason, as well.
Yes, AI isn't helping but the corporate world has been doing this for decades! Junior devs are second class citizens internally. I don't blame them for moving on after a few years.
I guess I should clarify too: I don't believe in junior titles. They handicap people into the position you describe where they must move on to progress. When I describe "junior" above, I generally mean a candidate with <=1.5 years of experience. When I say mid I mean any amount of experience greater but not senior according to technical review. And yep, I know this is not the best heuristic because there are definitely people with no working experience who have mid-senior coding skills (although they're rare). I think that's sort of part of the problem too. Senior management is disincentived from understanding the roles and growth trajectories, so our heuristics for hiring are totally warped and stomped on.
I agree. I wonder if it's a mix of fully remote work being popular some time ago and the amount of tech one has to know now increasing (DBs, backend, frontend, cloud, observability, security, etc.). When hiring remotely, people naturally try to find candidates who are very communicative, have a high level of ownership, and can work with or without clear requirements and without oversight. That latter set of traits is often associated with senior developers rather than juniors.
>Most shops want software teams that are either silently embedded black boxes that you insert rough instructions into and get working software as output or an outsourced team
Well that explains why AI excacerbates this. It's all they ever wished for and they don't need to make do with that facsimile of "human interaction" anymore. It's not perfect but that's a sacrifice they are willing to make.
Or you know, they just really want to be as cheap as possible in production (hence, outsourcing).
>It seems silly to deny that it's directly related to why it's so hard to mentor or hire juniors.
I'll give a slight BOTD here after my disdain above and admit tha a small team probably isn't the best enviroment to train a junior. Not unless you either
a) truly believe that the skillet you need isn't out there, and you are willing to train it yourself to alleviate your workload, or
b) you are thinking long term efficiency and are willing to lose early productivity to power the future prosperity. Which, to be frank, is not how modern businesses operate.
And yes. Any teacher in any field (but especially education) will tell you that the star players make their day, week, and year. But the worst cases make you question your career. Our natural negativity bias makes the latter stick out more. Those in industry won't get star players as they are either filtered out by these stupid hoops or gobbled up for 100k above your budget by the big players. It's rough.
reply