sigotirandolas
(That's also why there are so many of them: It just isn't that hard, everyone feels like a genius when they figure it out, and it's a great way to resume-build in the AI era).
1. AI generated text is just hard to read and verbose, if you worked so hard on your docs/specs, why would you want your README to be unreadable?
2. There's so much garbage written with AI that I'm just going to assume yours also is. Would you sign up to a gym with broken windows? It could be the best gym ever, but I wouldn't count on it.
* They can afford frequent CC incidents since their value is having the best models, and 95%+ uptime is still OK-ish.
* The core functionality of CC (the harness "agentic loop") is simple, an if that works then for most purposes CC works.
* CC just stores a bunch of config and history files, there isn't any financial or irreversible safety loss if they mess it up once in a while.
Once you work on something where a minor slipup can result in a huge real world mess, then I don't see how their approach can work.
I remember them from way back on Windows 98 and no one seems to care to hide them (?).
Once you get to that point, you can copy paste your issue into an LLM and get a fix close to the PR you would open, but so can the maintainers, so what's the point of opening a PR and adding more friction?
In fact discussing the issue is way more productive since it's just about the actual issue, root cause and tradeoffs without the debates on implementation details and nitpicks.
If you want to contribute major features, you need to befriend, discuss and agree with the maintainers, I don't think drive-by PRs ever worked for this.
It definitely doesn't inspire confidence in the project taking security seriously.
(Also the "write-up" is almost surely a "Claude-up", though it appears generated by someone external to the project).
The LLMs don't need to be perfect, they just need to be good enough so that the cost of fixing their code is lower than the communication overhead and the 'lost in translation' overhead from delegating tasks to mediocre engineers.
If the text is full of punchy three word phrases or nonsense GenAI images then that's an obvious sign. But so is if the other person has some revolutionary project with great results but they can't really explain why their solution works where presumably many failed in the past (or it's a word salad, or some lengthy writing that doesn't show any signs of getting you to an "aha, that's some great insight" moment).
A good sign is also if the author had something interesting going before 2022, and they didn't fall into the earliest low quality LLM waves. Unfortunately some genuinely talented people have started using LLMs to turbocharge their output while leaving some quality on the table nowadays, so I don't really know. I'm becoming a lot more sceptical of the Internet, to be honest.
Reading your comment, it looks like you work for a pretty nice company that takes those things seriously. I envy you!
My concern was that for companies unlike yours that don't have well established engineering practices, it _feels_ that with AI you can go much faster and in fact it's a great excuse to dismantle any remaining practices. But, in reality they either doing busywork or building the wrong thing. My guess is that those are going to learn that this is a bad idea in the future, when they already have a mess to deal with.
To put what I mean into perspective... if you browse OP's profile you can find absolutely gigantic PRs like https://github.com/leynos/weaver/pull/76. I can not review any PR like that in good faith, period.
On the other side perhaps your company, like most, does not know how to measure overengineering, cognitive complexity, lack of understanding, balancing speed/quality, morale, etc. but they surely suffer the effects of it.
I suspect that unless we get fully automated engineering / AGI soon, companies that value engineers with good taste will thrive, while those that double down into "ticket factory" mode will stagnate.
Many of those tools are overpowered unless you have a very complex project that many people depend on.
The AI tools will catch the most obvious issues, but will not help you with the most important aspects (e.g. whether you project is useful, or the UX is good).
In fact, having this complexity from the start may kneecap you (the "code is a liability" cliché).
You may be "shipping a lot of PRs" and "implementing solid engineering practices", but how do you know if that is getting closer to what you value?
How do you know that this is not actually slowing your down?
To start, it is based on a single machine check. It has little context, but if this was a common problem, I'd expect more data points.
The MC happened 8 hours after the freeze. It's not unusual that a hardware/kernel failure cascades to multiple subsystems so I'd be sceptical that the MC has a direct relationship to the root cause of the freeze.
(Part 13) Why does it quote an Engineering Change Notice rather than a consolidated spec?
(Part 11) LaneErrStatus=0xFFFFFFFF is 32 bits. As far as I know, PCIe x32 is very rare.
(Part 8.4) How is it surprising MMIO isn't included in memory dumps?
(Part 4) How is the definition of a MCE relevant here?
The "friction" is that Wayland developers don't want a sandboxed application with access to the Wayland socket to pwn your machine.
Trying to isolate applications within the same UNIX user is essentially unfixable since there's ptrace, LD_PRELOAD, /proc/$pid, .bashrc drop-ins, etc.
The author must know about all of this, as it's mentioned in the LD_PRELOAD note in the end. In my view, the model he proposes is security by obscurity (putting hurdles on top of a fundamentally insecure system).
In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.
Knowing those patterns is very helpful as a way to think about design problems, as long as you have the common sense to realize applying the pattern "by the book" is often overkill and you can just take some ideas out of it.
That article conflates as "Pure engineering" both reducing a software system to a small set of cohesive concepts, and architecture astronauts, when those are polar opposites.
I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.
So, you want to avoid both being disliked, but also being liked - because this puts you in novel situations you fear lead to an even bigger failure down the road.
I don't think the fundamental dynamics change by seniority, just that after some level there may simply be a smaller pool.
From the interviewers perspective, it makes sense to reject a candidate if they see any possibility it could be a flop. A bad hire is going to frustrate the team and look bad to the company, missing the best candidate is just going to result in hiring their next best pick.
> As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected.
I guess this is very context dependent but I can also see "bending to the interviewer's whims" backfiring if they see you're just trying to flatter them. I could see some interviewers valuing that you can explain your point if it's framed in a way that shows you are both observant and easy to work with. If it's framed as a more aggressive kind of pushback, yes that's going to get you rejected.
But yeah, I can also see that if you're willing to take any offer at any company as a junior just to get your feet into the industry most interviewers may not be specially smart and resisting is likely to go wrong.
- Install as little software as possible, use websites if possible.
- Keep important stuff (especially cryptocurrency) on a separate device.
- If you are working on a project that pulls 100s of dependencies from a package registry, put that project on a VM or container.
In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.
They are not mutually exclusive, but they compete to a degree. If someone's time is mostly spent on what can be measured, they can't spend time on "common sense" or investigative work that is less easily tracked. At the end of they day, trying to measure everything makes as much sense as trying to document every line of code. (Most of this, naturally, also applies the other way around).
> This is just the frame that the author is trying to prop up in order to sell us their shallow, meaningless piece.
> I see this pattern a lot in “influencer” content that people sometimes share with me
I think a lot of the shallowness is from blogs or HN being a public, persistent, broadcast written media. In a face to face conversation, you can generally follow up and share more specifics and nuance without fear of getting a bad reputation.
If anything I think the bias is the other way around, on the Internet whatever you write can get cherry-picked and framed to make you appear terrible, in person it's much easier to get a fair sample.
I've even seen this stupidity in myself sometimes. In a way it's funny how you can get so lost on the numbers that you forget about the thing.
Otherwise, it's a matter of time until the house of cards falls down and the company stagnates (sadly, the timescales are less of a house of cards, and more like a coal mine fire).
Did that end up working for you?
I had this same experience recently, and it floored my expectations for that dev, it just felt so wrong.
I made it abundantly clear that it was substandard work with comically wrong content and phrasings, hoping that he would understand that I trust _him_ to do the work, but I still later saw signs of it all over again.
I wish there was something other than "move on". I'm just lost, and scarred.
- https://github.com/hyprwm/Hyprland/blob/00da4450db9bab1abfda...
- https://github.com/hyprwm/Hyprland/blob/00da4450db9bab1abfda...
- https://github.com/hyprwm/Hyprland/blob/00da4450db9bab1abfda...