mjr00

I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic.

If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.

> In a few years, it just might.

If you're in a product company and your development backlog is empty, run. That company is about to go out of business.

It's very true, you used to have to hire people you knew were not very good just to have warm bodies who could throw together widgets, minor bug fixes, etc. You still had to have a competent developer review what they did, which was annoying, but ultimately a time saver over doing it themselves.

Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).

So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.

If you could reliably work from your autonomous vehicle for two hours you might be able to include that as part of your work day, e.g. 2 hours working on the ride in, 4 hours in the office, 2 hours on the ride home for the full 8 hours. If not, you could fall asleep in the backseat, watch some TV shows, or... you know. Just make sure your windows are tinted. In any case, I'd definitely take a 2 hour "do whatever in the backseat" commute over an hour-long "pay attention to the road at all times" commute.

This is all predicated on true autonomous vehicles though, not the half-baked non-solutions that exist today.

Yes, I mean you've basically explained it without realizing it; "being a manager is about writing" and "being a software developer is about coding" are equally overly reductive statements.

Yes but also no I guess? Like would you say being a manager or in marketing is about writing, or that being in sales is about talking? Those are the main methods of accomplishing what those roles are meant to do, but it's not like they're about writing and talking.

> software jobs still hire based on how good your coding is primarily

ehhh. In my experience, being able to code is a necessary but not sufficient skill for a software developer. The only exceptions I've seen is having some extremely deep expertise in a niche technical field (and even then I wouldn't call that being able to code well, so much as technical domain knowledge).

When I was hiring at AWS the view for my team (RDS) was that there wasn't much difference in expectations between algorithmic coding ability for juniors and seniors. The primary technical differentiator for seniors was architectural and operational. But even more important than those was the nontechnical stuff; mentorship, being able to communicate ideas clearly and succinctly (no point in being able to architect a system if you can't communicate it in a way people understand), interacting with other teams, demonstrating understanding customer and business value, etc.

Stock/bond ratios are way too advanced for what's qualifying as good advice here:

> AI consistently advised people to save during their working years, draw down savings in retirement, invest heavily in diversified stock funds, and reduce stock exposure after age 45.

This is analogous to saying to an aspiring software developer, "You should write clean and testable code, have clearly defined API boundaries, and a repeatable build process." All very true, but also so general and basic that it's not helpful.

AI financial advice is surprisingly good... for now. But given the historical trajectory of both the finance and advertising sectors I can't imagine it will, for long. AI responses without ads are unoptimized space!

It only takes Draftkings writing a very large check to Google before it responds to financial questions with solid advice before ending with, "Since you have a few spare hundred dollars laying around, why not try a high-risk investment into same-game parlays?"

Sure, and you need to do the build vs buy math, but why not take the "If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data." logic further and say

1. Don't use a third-party auth provider, if you can't build out an OAuth provider in an afternoon you shouldn't be entrusted with login credentials

2. Don't use Github, if you can't build out an internal Gitlab instance in an afternoon you shouldn't be entrusted with securing source code

3. Don't use Github Actions or CircleCI, if you can't self-host a Jenkins server in an afternoon you shouldn't be entrusted with secure deployments

4. Don't use a lawyer or outsourced HR, if you can't draft legally binding employment agreement in an afternoon you shouldn't be entrusted with hiring people

> We’re not talking about maintaining your own k8s cluster here mind you, but a basic Postgres setup. If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data.

Intelligence is being able to set up your own postgres database with backups, PITR, retention policies, HA/replicas, and everything else needed to prevent catastrophic data loss. Wisdom is realizing that's a solved problem completely unrelated to your business, so you don't have to.

I might get flak for saying this but if you aren't a postgres expert already: just use RDS or a similar cloud DB. The amount of money you're saving by hosting and managing your own postgres instance is absolute peanuts compared to having battle-tested infrastructure for HA, backup and restores, point-in-time recovery, read replicas, etc.

Good article overall, some comments:

> Use foreign keys with cascading deletes for low-volume tables, particularly where database consistency and correctness are important. Careful at higher volume.

This might be just me, but I hate cascades, for a very simple reason: at most places, the majority of developers "live" in the Python/Node/Go/whatever application that talks to the database, not the database itself. Cascading deletes (or updates) is basically magic and it can be very hard to understand "why did deleting a row from table A delete something from table B automatically". Especially if someone sets up the cascading wrong! IMO it's better for long-term maintainability to emit explicit delete clauses. Correct use of foreign keys will prevent any issues with database consistency.

> Tricks for large table migrations

The pitfalls and workarounds are all correct, but worth pointing out tooling already exists[0] for managing this for you. Making changes to large tables should be as simple as running a command (and then nervously monitoring for the next 24 hours as the data copies).

Other things to consider,

1. Get used to separating application and database deployments early. It is impossible to transactionally deploy both a schema change and an application change simultaneously, there will always be some delay where the versions of database and application are out of sync, and you will eventually run into a situation where the database change deploys fine but your application change does not. Once your app is in production, get in the habit of only doing backwards compatible schema changes: all new columns are nullable or have a default, no renaming of tables/columns, etc.

2. In the same vein, figure out a schema management strategy early. You really don't want your database deployment process to be "senior dev runs some DDL manually on production from his machine". I'm still partial to liquibase because it's the devil I know, but there's other tooling like Flyway which exists.

[0] https://github.com/shayonj/pg-osc

> Kubernetes vs AWS?

How is this even a direct comparison? Most companies I know of which use Kubernetes are using it on a cloud provider. Even if it's kubernetes on EC2 rather than hosted e.g. EKS, those companies are also happy to use lock-in services like RDS and S3.

> Also, for some reason Optional[T] became deprecated, just as the ecosystem finally embraced types ~3 years ago.

Optional[T] is now T | None. Means exactly the same thing but doesn't require an import. Support for the older syntax presumably won't be removed for a long while regardless.

> This is unprofessional and embarrassing for Zig.

It is. It's also why Anthropic and Bun moved off Zig.

Zig is effectively a one-man show, and that one man has been making increasingly erratic decisions.

It's his project so it's well within his rights, of course. But when you're a ~trillion dollar company you don't want to get hit by a supply chain risk like this.

For Anthropic, it's better to nip this in the bud rather than invest more into the Zig ecosystem, where there's a demonstrated risk of the not-so-BDFL going off the rails.

You're framing this as a thing done by a greedy corporation in an evil manner, which maybe it is, but it's also just a sign of the times.

For most of the 90s and 00s, your game engine, specifically idTech in this case, was a competitive advantage. Doom and Quake/2/3 all represented massive technological jumps over their predecessors and were way ahead of their competition in terms of looks. Games like Unreal (Tournament) and Tribes competed using their engines' strengths; those engines didn't look as good but were capable of rendering much larger spaces than idTech, and those games emphasized that, e.g. Tribes' massive multiplayer maps with vehicles, or classic UT maps like Facing Worlds and Lava Giant.

Then in the late 00s to 10s, things started to hit a wall. Probably peaking with Crysis in 2007, which is likely more remembered for its engine, graphics, and system requirements (all of which were truly mind-blowing at the time) than its actual gameplay. After that, games' graphics improved at a much slower rate; it started to be less about the engine's capabilities, which were increasingly homogenized, and more about art direction.

Now in the 2020s, we have UE5 for AAA games with high-fidelity graphics and Unity for everything else... what is the competitive advantage in maintaining your own engine? As you mention, you have to have internal expertise, which is less well-documented than UE5/Unity because you don't have dedicated documentation staff; you have to maintain your own tooling, which is likely worse because you haven't invested as much in it. From a ROI perspective, unless you're planning on investing so you can license out the engine and become a UE5/Unity competitor, it doesn't make sense to maintain your own engine.

And looking ahead, frankly, consumer GPUs are now so expensive that game graphics have likely peaked for at least a decade. There will simply not be better hardware available to gamers for the foreseeable future. Games "looking good" will be more about art style and direction, and you sadly do not need a team of game engine programmers for that.

No missing "k", really just 191 players. https://steamdb.info/app/3043580/

> - The make around 5 billion in revenue per quarter - The problem according to them is profit margin - around 150-160 million

> So first of all, they are big! Secondly they are not at a loss. They just have a "thin, non-growing margin". So to fix all this they are trimming down, so they can "return to growth" (which I think is ridiculous).

How is that profit margin distributed though? King (Candy Crush etc) and Mojang (Minecraft) are specifically called out as money-makers, it's possible that they're carrying the majority of profits while everything else is a dud:

> We have also learned that we are not the best home for every type of studio; in a typical year, we lost 64 cents for every dollar we invested.

As an example, Double Fine (one of the studios being chopped) has released 2 games since 2021, Keeper (191 peak player count on steam) and Kiln (163 peak players); these would be flops even for a normal indie game, for a studio getting Microsoft salaries those are enormous flops.

I think this article is a good demonstration of how the nebulous concept of "taste" still dominates, despite AI taking over so much.

IMO -- and apparently the opinion of others -- adding an AI-generated picture every single paragraph in your article in which the primary purpose is to, presumably, discuss a topic rather than show off your AI-generated art, is in extremely poor taste. It's distracting, it makes it hard to focus on the text, and to be perfectly blunt, nobody is impressed by your ability to create pictures by AI.

> Honest question : does it need to be said ?

At the current time I'm writing this, all other top-level comments are engaging with the article as if it were sincere. So, yes.

I mean I agree with this as well, the people who yell and swear at LLMs are just as bad as the people who chit-chat with them like they're friends. It's all very unsettling because it's prepatory for psychological manipulation at unprecedented scale. Targeted advertising on steroids.

I'll go a step further and to say this it's genuinely unsettling someone type to a computer like this. I won't claim to be a psychologist, but with how many instances of "AI psychosis" have been reported (and I've seen first-hand) it seems like treating the computer like a computer is safer, not to mention more effective e.g. lower token usage.

... except this is on-prem with their own infrastructure, not cloud?

The loudness war in the strict "we must compress and slam everything as much as possible to make our stuff sound good on the radio" sense is over thanks to Spotify et al doing loudness normalization, but there's still an open question of "how much compression does sound good?" which is extremely subjective. A lot of modern music is louder than peak loudness war stuff just because the creators want their music to be slammed to shit. I listen to/make aggressive bass music and -5, -4, -3 LUFS are common. (By comparison, some of the common examples of loudness war era CDs like Definitely Maybe and Californication sit between -8 and -6 LUFS.)

> Especially since the answer to any loudness problem is to simply for the user to turn up the volume.

This isn't quite true as compression addresses differences in volume. Unless you expect the listener to actively turn up the volume during the quiet parts and down during the loud parts of your song, or be listening in a completely quiet environment with nothing but the music so they can appreciate the dynamics--which is the way a lot of vinyl aficionados do listen to music.

Now, yes, but in the 90s/00s the alternative to CDs was cassette tapes, which were both inferior audio quality and took up more space. CD players in cars were a very desirable feature back then.

At my peak in the mid-00s I remember counting and finding I had just over 500 CDs in my car, almost all of which were MP3s burnt to playable CD-Rs laying in the passenger seat... the good old days. Nice thing about using CD-Rs is you didn't have to care about them getting scratched, either.

"How do I acquire users" is the entire function of sales and marketing. A single HN comment explaining how to do sales and marketing, which is highly dependent on your product and market (and much more difficult than technical people tend to believe), is a bit unrealistic. And a great opportunity to use Claude/ChatGPT for something other than code. There's no silver bullet but as a springboard you can think about:

Who is your ideal customer profile (look up buyer personas) -- if you're B2B figure out both the profile of the company who would buy, as well as the person who would actually buy, and the person who would actually use the software: remember that buyer != user in B2B scenarios, and you'll have to figure out if the buyer, user or both is the best path to getting a sale. If you're B2C figure out your buyer personas so you know where to advertise.

Why would people want your product; sounds like you may already have this down but be ready to explain your value proposition concisely.

How will these people hear about your product -- a SaaS that falls in the woods doesn't make a sound, you need people to learn your product exists before they can pay for it. This is the point of figuring out buyer personas, you need to meet your customers where they are, and you can't know where they are unless you know who they are. This is highly dependent on your product/personas, and could range from running LinkedIn ads to SEO to having a Bluesky brand account to going to local meetup groups or conferences and trying to get your first handful of users in-person.

I am glad you like some things. Some people like other things, such as LLMs, or hosted server infrastructure.

Now explain to me why you are allowed to have the things you like which use a lot of water, while other people are not allowed to have the things they like which use a lot of water.

That's exactly my point! Everything has negative externalities, and focusing on them is the way to seem "rational" even though you don't actually care about them. It's the same as how people will protest high density residences "ruining the character of the neighborhood" when they really just don't want poor people living near them. You can't just outright say you don't want poor people in your neighborhood, so you talk about how these residences ruin neighborhood character, disrupt view cones, cause traffic problems, etc.

Here it's the same thing--the people protesting don't give a damn about water waste, electricity usage, or wasted land. If they did, there are tons of other offenders who are way worse. But they don't want to outright say they're protesting against AI because it makes them seem like luddites.

It takes 870 gallons of water to produce 1 gallon of wine -- if people were genuinely protesting water waste it would be a good idea to start there. Almonds too.