Hacker News: melozo

New comment by melozo in "Open source AI must win"

melozo — Sat, 13 Jun 2026 03:52:31 +0000

Huh? Open source is a quality of the software, not specific to the hardware used to run the model. The demand is that model weights are openly available for anyone to run and fine tune without restriction. Has nothing to do with the hardware it runs on.

New comment by melozo in "Ask HN: Are most corporate SWE jobs performative?"

melozo — Wed, 10 Jun 2026 14:12:14 +0000

I worked at Amazon and I do think that more than anything we were overhired with little meaningful work. A lot of compliance goal chasing. Not that it’s performative to the top brass, but the work was very little and not usually very technical.

New comment by melozo in "GitHub RCE Vulnerability: CVE-2026-3854 Breakdown"

melozo — Wed, 29 Apr 2026 16:56:55 +0000

Yeah I’m struggling to understand why the same header field would be used for git options in the first place. Why ever allow users to modify that specific header?

New comment by melozo in "Layoffs at Block"

melozo — Fri, 27 Feb 2026 16:36:19 +0000

Ironically Square isn’t good at anything in particular. Square fails to have a good point of sale (Toast wins) and fails for online store fronts (Shopify wins). Square is in a position where they spread themselves thin and aren’t at the top of anything in particular.

New comment by melozo in "AI is forcing us to write good code"

melozo — Tue, 30 Dec 2025 22:13:13 +0000

I’m not sure how controversial this is - but 100% code coverage is almost always a waste of time, paid both immediately and long term, for certain languages. Go, for example, requires explicit error handling, but the way errors are handled are usually plain and homogenous. Adding unit testing everywhere creates a phenomenal amount of test code that can become 3x the size of the source, and certain changes (like interface changes) can require updates to all tests, especially if mocking is used.

Obviously with AI maybe those issues I have go away. But I really don’t like letting the AI modify tests without meticulously manually reviewing those changes, because in my experience the AI cares more about getting the tests passing than it does about ensuring semantic correctness. For as long as tests are manually maintained I will continue keeping them as few as necessary while maintaining what I view as an acceptable amount of coverage.

New comment by melozo in "AWS multiple services outage in us-east-1"

melozo — Mon, 20 Oct 2025 22:41:02 +0000

You’re right about that. I guess what I mean is, how long will people be enthusiastic about AWS and its ability to innovate. But AWS undeniably has some really strong product offerings - it’s just that their pace of innovation has slowed. Their managed solutions for open source applications is generally good, but some of their bespoke alternatives are lacking over the last few years (ecs kinesis code* tools) - it wasn’t always like that (sqs ddb s3 ec2).

New comment by melozo in "AWS multiple services outage in us-east-1"

melozo — Mon, 20 Oct 2025 18:30:58 +0000

Sure, but it’s not reasonable that internal collaboration platforms built for ticketing engineers about outages doesn’t work during the outage. That would be something worth making multi-region at a minimum.

New comment by melozo in "AWS multiple services outage in us-east-1"

melozo — Mon, 20 Oct 2025 17:49:40 +0000

Even internal Amazon tooling is impacted greatly - including the internal ticketing platform which is making collaboration impossible during the outage. Amazon is incapable of building multi-region services internally. The Amazon retail site seems available, but I’m curious if it’s even using native AWS or is still on the old internal compute platform. Makes me wonder how much juice this company has left.

New comment by melozo in "The Time I Lied to the CTO and Saved the Day"

melozo — Thu, 09 May 2024 04:16:55 +0000

I worked at and we had this exact architecture. The senior engineer (who went to Stanford and was proud of it) designed this system. I had long arguments with him about how this system wouldn't scale when we launched it, and used real production data to prove that it would happen. No one listened to me, it launched and imploded within a few weeks, and soon after I transferred off the team. The worst part is, that senior engineer was eventually promoted and that system was passed off to an entirely new team to battle with. That entire system was terribly designed, and I think you can guess why.