Hacker Newsnew | past | comments | ask | show | jobs | submit | aeonflux's commentslogin

> And then people still think their developer jobs are safe.

From my experience, most developers are actually very anxious and scared about their future.


Many are, and I already seen team sizes shrink thanks to AI tooling, on top of what was already happening with serverless and iPaaS low code/no code tooling.

However in many forums and blogposts still looks like that the "only happens to others" mentality is quite prevalent.


There was a a great one I replied to that was full of the capitalist talking points saying they dont believe in UBI or high wages for most workers (themselves excepted of course) while lamenting about how to feel motivated and keep chill about their future and I pointed out all the pressures they happily accept and endorse for other workers below them will soon apply to them with rent and bills pressure and low wages so they wont even have a motivation problem when the transition is complete

When actually it should be software companies that should be worried. If you believe like some guys do that you can just point an LLM to any piece of software in the world and ask it to patch it / replicate it / maintain it with zero copyright repercussions, what is the point of software companies again?

If you believe like some guys do that you can just point a camera at any painting in the world and replicate it, what is the point of painters again?

(i.e. the ability to copy existing things does not obsolete the need to be able to make new things)


I imagine that, if you're in the US, it is seriously scary. Nobody is safe, not even in FAANG. Probably FAANG is the worst place to be now if you care about stability but it was never great before that (stack ranking, firing quotas, etc.). At least you had the idea that performance would keep you safe, but now it doesn't.

I'm not sure how much that translates in other countries where protections for workers are stronger and companies have different operating models. Not to say it's without trade-offs, you might feel safer over in Europe but you're never gonna see US-style compensation, and the concept of becoming a millionaire (and a new startup founder with ex-FAANG credentials) because you joined a startup at the right time is practically non-existent.


I know people working as programmers in germany, who don't even know what claude is. So there are areas left but I bet their numbers won't increase, but die out fast.

> I'm not a team player or something. It's ridiculous.

This. In the past, when you could challenge a sloppy and rushed feature, done wrongly. You could steer people into better designs without adding much overhead. These days, if you try to challenge those no-reviews, ship-50k PRs daily, you instantly get labeled as AI-sceptic, someone who is afraid of change, afraid of loosing your job. I don't see a way out from this.


> Hobby groups projects like this are less fun for a lot of people who used to enjoy interacting with smart people.

Same thing did happen to many work places. People at all levels proxy questions through LLMs and don't even bother to read/trim/edit the response.

Funny, how suddenly a tight, 1-2 sentence response on point is a sign of skill.


Wasn't there an article here, or was it under another HN post as a comment? Someone pointed out that the before the dawn of LLMs, "bad contributors" had a rate limiter of sorts. Now anyone can prompt their LLM and throw their output at you, shifting the burden entirely on the reviewer at highest possible speed.

It's so much worse than just that. Because they will also decide on how problem should be solved by prompting LLM and ask you to argument doing it any other way vs the LLM slop they pasted

It which point you reject the PR and suggest them to maintain a fork themselves.

I'd say don't bother suggesting anything.

Not as a rule for all prs you want to reject, but any time it seems to be no-effort pure ai. Both to waste as little of your own time and effort as possible, but also to to help make this activity not rewarding.

I wouldn't worry about false positives and being unfair. This is self defense and also community defense. Anyone legit will manage to get your attention. You'd be filtering not on any specific detail or rule but on simply "care".

If a legit person fails to convince you that they are a human that cares, then that's just an unfortunate industrial accident. It's unfortunate but trying to do anything about it is worse.

Besides, any actual adult understands that if they can't prove their age right now, then they can't buy a drink right now, even though they normally have that right, and is never the one trying to cry about the travesty of justice at being denied. If I submit a pr that fails your ai sniff test, I get it and don't think you're abusing me. I can try harder and we can be friends later no problem at all.


I put something like that right into AGENTS.md in one of my open source repositories -- disclose the usage of AI (it's super obvious anyway) and be prepared to act on review comments, otherwise the PR is closed and submitted could be banned depending on my mood. And I only got like 3 PRs before I put it.

Those weren't even that bad code-wise, some have uncovered realy problems, but I ended up asking /my/ LLM to ponytail them into shape, because the submitter didn't bother.




Just this morning I had a senior manager say to me "I was trying to do someone else's job and give them all the info so they can review it as I have no knowledge" in response to me asking for them to please filter the Claude word salad using the meat proxy. I'm pretty tired of having to do the job of filtering the low-effort copy-paste walls of text

Similar to sending a "Let Me Google That For You" except somehow because it was an LLM not Google, they've forgotten it's more insulting than helpful, and aren't even in on the joke they themselves are making.

I mean I can't speak for everyone but in my mind, sending lmgtfy was not only always insulting, it was meant to be. It's saying "I know you have access to the tools you need to answer this question, why are you asking me, and here's some instructions on how you use this tool in the future so you don't need to be asking me foolish questions."

And while I generally believe we should be pro-social in our communications both with each other as software engineers and with others who don't know what we know, I think it's also fair game to point out that the thing being asked of you is commonly available knowledge. Google may suck as my sibling comment points out, and I agree, but filtering good info from info dumps, be that Claude or Google search, is a life skill that's more critical now than ever. And if you work in tech, really at any level, you know how to do that.


The issue with LLM copypaste by non-expert humans, and it took me a while to realize this, is ego.

What they feel like when they do it: "Man, I'm fucking brilliant. Look at me using new technology well. I was always the key provider of value here."

What they hear when you call out AI copypaste as less useful: "None of that is true."

Now we can debate on the factual merit of both sides, but that doesn't change the feelings.

Unfortunately, I don't see a way to change the feelings, because that dopamine burst of making non-experts feel like experts is something all the AI labs have a HUGE financial incentive to maximize in their products.


Well - the "let me google that for you" nowadays barely works, because google ruined the search engine. The search engine sucks now - and by default the first results are AI slop summaries that are IMO worthless.

I saw a product manager that used to do that, just ask developers to verify the Claude hallucination and placeholder numbers.

He got fired quite quickly after his boss realized it was all bullshit.


I knew a manager that tried the exact same but in the GPT4 era :D He also got fired/left but as satisfying it would be to say that this was the cause of his demise I can't prove that.

> Funny, how suddenly a tight, 1-2 sentence response on point is a sign of skill.

Wasn't it always?


I agree, anecdotally I've always noticed a huge amount of my peers lacked professional communication skills even pre-LLMs.

A lot of people get this idea that "more verbosity = better" instead of optimizing for conciseness and information-density. I largely blame minimum word-count essays from school assignments.


Verbosity can be fine, but you'd want a simple enough text, with the verbosity separated. I still write emails with footnotes, and thanks to UTF-8 I now have all the numbers available.

Amusingly enough the advent of HTML-emails didn't produce any better formatted mails, despite the extra formatting options, than what you can do with a plain text email supported by a proper text editor.


Verbosity is, among other things, a cover-your-ass move. Stating something simply requires cutting details that might matter sometimes. If your counterparty or experience has made this painful, you'll likely write more.

Would you like me to edit this mess for you? You’re way too verbose..

"As brevity is the soul of wit, I shall be brief. [then bloviates on and on.]" ~Polonius

I’d have written a shorter comment, but I didn’t have the time.

That's the essence of it, I suppose. Cheap walls of text.

Edit: although another quote comes to mind- "Quantity has a quality of its own."


Was also a power signal, often demonstrated by execs who send three or four word replies to everything, often also in lower case with no punctuation.

sama tweets like this all the time, totally performative

Depends. A lot of the 1-2 sentence rapid responders from my past jobs weren’t really understanding the problem. They were virtue signaling that they were confident, fast to respond, and understood immediately (without elaborating)

It’s easy to send a pithy response that suggests experience and understanding without having either. Think of a middle manager spouting pithy buzzword laden cliches confidently in response to every request, then transferring the real problem to the grumbling employees who have to solve the actual hard parts of the problem which lie in the nuance.


This is a core problem of short-form social media (including HN): it’s easy to signal understanding or expertise without having to demonstrate it.

I think a lot of workplaces would do well to ban LLM-based replies in certain spaces.

While I don't disagree with you, they shouldn't have to. This should be one of those things like covering your mouth when you cough in a crowd and not playing loud music in your cube that people with basic social skills should know not to do. Unfortunately, like much basic courtesy, we apparently now have to make rules.

I agree, but it seems that some people actually need to be told that copy/pasting a bunch of LLM slop into chat is like farting on an elevator.

I wouldn't even say that it comes down to "social skills" in a lot of cases, it's just people who seem to be performatively using AI. I'd classify them as corporate climber "yes, boss" types more than lacking in social skills.


Your analogy is better than mine. :-)

> Funny, how suddenly a tight, 1-2 sentence response on point is a sign of skill.

Communicating well has always been a sign of skill. Talking to most devs was like pulling teeth even before LLMs.


Meat proxies. Artificially intelligent.

This was already true (as sibling comments note) but it's _way_ sharper now. Even if you use an LLM to research or answer a question, editing it down for other people takes effort, and doing it well demonstrates understanding.

That's why I tell my Claude to keep its responses short :V


Does this project have any meaningful traction? Seemed like a cool idea, but I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...


I found that a big issue with it in practice is that the numbers are just not great, and the repo is very vibe-coded. When the numbers are great, it's sometimes cheating with the setup. For example some GEMMs only compute each 8th value and reach close to peak TFLOPs because of this, but it's a vibe-coded reward hack and the verifier does not check all numbers of the target.

Also, compilers have a lot to prove in 2026. Why not just hill-climb a Triton or Cuda kernel if you need perf?


> But I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...

At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem. Ocaml is barely mentioned in the news and rarely HNers here use that language, but it is Jane Street that maintains and uses it.

Judging by hype isn't a great way of evaluating a language. I am not going to check the entire Nvidia stack, from CUDA, to CUTLASS to cuDNN and even on PyTorch's side just to solve a runtime error that could have originated from either place when Mojo solves all of that.


Jane Street's use of OCamel gives them a comparative advantage in hiring. Many devs put a premium on the tools they use. Same story with Anduril/Mercury using Haskell. You can run a successful prop trading firm/weapons design shop/startup-banking(?) platform without these things. They differentiate you from your competitors by being cool, not by being the best technical solution. If anything they were otherwise unprove at scale and out of pure engineering consideration a gamble. Developers are consumers.


> At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem.

No need for snarky comments. These days tools/frameworks/languages/libraries/etc are popping all the time. Do you expect people to research every simple signal they catch in the wild?


How noob do you have to be to really feel this way lol

Edit: a language is by definition an ecosystem. Learning/using a language that no one else uses is completely pointless.


The interesting opportunity in 2026 for languages is that an LLM doesn't complain if there's an ecosystem or whether any other LLMs or people are using a language, they'll just write the code in whatever language you tell it to. Already authors are writing languages with features aimed at making it more more attractive for AI to write than people. Also great for working with research languages. I just used AI to write a Halide program and I wouldn't have bothered to do so before, for the reasons you state.


I think the compiler not being open-source hurt with getting people to check it out. Today, people are accustomed to most of it regarding PL development being out in the open, and Mojo was an outlier here.


the main value proposition of mojo is being a (modern language for heterogenous compute). when writing code for the CPU, it is a nice language. it looks a bit like python, have arguably one of the best SIMD abstraction, a bit easier than Rust .. etc. but in my opinion, that does not justify deep investment in learning the language vs rust or zig. what sets Mojo apart is that it was designed from the grounds up to natively supprt other types of hardware (starting with GPUs). I have been in the mojo community from the beginning and almost every other project presentation starts with (I wanted to do XYZ in my domain and I could match or get close to Rust, C++ perf but then I wanted to see if I can make work on the GPU and it was much easier than expected and now I can solve my problem 10x faster). this is massive advantage that is underutilized outside of the AI/LLM and few other niches. running natively and being portable to NVIDIA/AMD/Apple GPUs means that you can transform any arbitrary workload you have in mind to the GPU and you won't need to worry about the separate CUDA/ROCm/Metal stacks, slightly different programming models, building headaches. you will be using the same language and the same compiler for CPUs and GPUs (all of them). or you won't need to coerce your problem in the shape of Triton to make it portable. If you have a problem in mind and don't like what you see? write your own GPU abstractions, containers, data moving and pipelining logic, work partitioning .. etc. this is extremely powerful and it sets Mojo apart from any other mainstream systems language that I have seen. that's why bigger mojo projects (even pre 1.0) like NuMojo and Marrow are all dabbling with GPU support even before the first stable release.

and now with support for TPUs and Trainium chips it is becoming even better. some problems will work better on some architectures and you will be able to split your problem to the best hardware doing some work on the CPU and some work on the accelerator(s) of choice, all with a modern language and one compiler with good tooling. that seems to be a good enough value proposition for me.


The "problem" it might solve for me, personally, is having a systems-level language that matches my personal style a bit better than Rust or other more modern systems level languages.

I know they're putting a lot of weight on GPU programming, which is fine and probably solves problems, but this is the part that would motivate me personally.


I'm in the same category, but GPU support is definitely interesting too. The idea of offloading intensive processing to the GPU has its merits.


You can read a lot more about it here: https://mojolang.org/docs/vision/


I don't really understand where is this need to compress the logic into where small chunks comes from. In result we get single line of code which has multiple statement conditions, different paths, and it's not possible to grasp in one go.

Other practical example why ternary is bad: Many code-coverage solutions break on ternary because they don't correctly see that one of the branches was missed in tests.


Because you can deduplicate certain parts of the logic which make the whole thing less error prone, such as

    if c
      x=1
    else
      x=2
If I ever want to change x, or refactor this code some other way, its a more brittle process over x=c?1:2

The ternary expression also takes up much less space so there is less of an emphasis on it, this can be a stylistic tool in a programmer's toolbox


the oposite is also true, you can have misleading side effects coming from joining things into a single expression


Those two behave in the same way if you drop the parentheses:

1. statement if (condition || something)

2. (statement if condition) or something


I don't think rewrite the in Scala was great decision, business wise. Fast forward 15 years its way lower on popularity than Ruby. Not sure what they use these days though.


"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup, The C++ Programming Language


Results from outsourcing can vary. You might end-up with totally unmatched 5 candidates and complain that there is no good people on the market. How would asses that the agency did good job (or any job at all)?


Types are helpful in large codebases, but in Web Apps they tend to get into the way more than they help. You can still use semi-typed constructs in Ruby, but you have the freedom to choose where you need them.

After moving to writing web in Go (from Ruby) I am still baffled how much more boiler plate there is and how much slower things move because of this. Types are great when you want to refactor some things, but thats just part of the job.

In Ruby I loved how can you just quickly jump into REPL or just do inline breakpoint to inspect state: `scope.map(&:names).last.tally.sort_by(&:last).reverse.first(10)`

Something like this is such a chore in Go that I simply skip it more often than not.

> it uses a lot of special characters, which makes writing the code slower

I don't get this part. What special characters?


Unfortunately I don't have much experience with Go, I did try it for the sake of trying it, and I see your point, it is a bit more complicated to write code compared to JS/TS (two languages I know very well) or even Java (disclaimer: I think Java sucks).

> I don't get this part. What special characters?

For example let's look at this code:

```

class ProductsController < ApplicationController before_action :set_product, only: %i[ show edit update destroy ]

  def index
    @products = Product.all
  end
...

```

You can see a bunch of special characters: < : , % [] @

For example, if I wanted to write the same code in Typescript, based on my setup I might just need do something like this:

```

instance.get("/products", () => ProductsRepository.find());

```

Where instance is my router instance (fastify, express, whatever) and ProductsRepository is a TypeORM repository. My before_action might just be a middleware I pass to the callbacks chain or register as global middleware


You're mostly comparing frameworks here. For example, using the Roda framework instead of Rails you can define a route like this:

  r.get "products" { ProductsRepository.all }
which is pretty close to your Express example.

You don't say what set_product should do but with any Rack application like Roda or Rails you can also set middleware as you suggest for Express.

With regard for special characters vs reserved keywords, that seems to be mostly about personal preference and familiarity.

e.g. I know that in a class declarion in Ruby < means the same thing as extends in JavaScript. I don't really notice the difference day to day.

Same for @products vs this.products. This doesn't seem like a conceptually big differnce to me.

As for %i[] to define an array of symbols, the typescript equivalent would be:

  const symbols: symbol[] = [Symbol("show"), Symbol("edit"), Symbol("update"), Symbol("destroy")];
Personally I always use [:show, :edit, :update, :destroy], it's more obvious IMHO. I use Rubocop to autoconvert that in any code I inherit.

What makes me love Rails is all the little trivial methods like one to quickly format arrays into gramatically correct sentences. Or the Array() wrap method when dealing with APIs.

Or the way Rails handles dates and times like 1.business_day.from_now

Or any number of other little utilities that are easy enough to write yourself but add friction when they're missing.

Rails gives me a well supported fullstack of what I need and I know that it and Ruby are constanly improving because its backed by some massive companies.

I don't think there's any need for you to adopt it though. That podcast is just about why DHH loves Ruby and Rails that doesn't invalidate what you're already happy with.

There is more than one way to do things.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: