DanielHB

The developers of the Zelda series always tried to make new games fit the previous one's lore.

The devs themselves put a ton of effort on making these games kinda fit with each other at the time they were making each new installment, it wasn't a retroactive thing. They just weren't super pedantic about it until the official timeline came out.

Anyone knows the details why Heart left Sweden? I applied for a job with them a few years ago but never heard back so I am quite curious.

They seemed to have a lot of former Embraer engineers from Brazil, I wonder if they brought them over to the US.

Yes, but I also think it will be trivially by-passable if you pass your output through another LLM. At least for text.

It might help catch students cheating, but not real spam-bot usage. As soon as platforms start checking for watermarks spambots will add anti-watermark passes.

Graphite kinda does that automatically with its "gt modify" command. However it keeps the history internally in your PR, but that history doesn't end up in your main branch. Once you merge the PR it looks like a single commit in the main branch history (or a single commit per PR in the stack).

It is a bit unfortunate but when using Graphite it is usually better to completely avoid any raw git commands that modify history at all.

Ah okay, I thought you meant to fully close the session before you make any manual changes.

In my company we use graphite and stacked PRs so it is highly encouraged to keep one commit per PR, so I am constantly ammending my commits.

I don't let claude make commits for me, every commit is my own. I check the diffs before commiting.

> never mix your changes with the agent's changes

yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.

When I was doing a really large refactor across the codebase I told Claude Code to explain how certain things worked currently and how I wanted things to look like after the migration and a plan on how to get there. Then I did several further clean sessions where I always started along the lines: "Using this plan {link} do X."

Works pretty well for "non-permanent" instructions (you don't want to put this info into your committed markdowns).

My main motivation was simply to save tokens, but it actually worked really well and improved speed as well.

My lockfile was not gitignored, I had made significant changes to package.json so I was expecting diffs in the lockfile.

I just don't usually read lockfile diffs and claude inadvertently updated a few dozen packages to new minor versions without me noticing. In fact I only realized the problem after I looked at the lockfile diff.

I made changes to my dependency lists in the same code where Claude ran npm update. The lockfile diff was a few hundred lines after I undid what Claude did.

And yes, eventually I did check the lockfile changes and spotted the problem. I just usually don't check the lockfile that throughly.

You are assuming a greenfield scenario, in large brownfield projects it is quite easy to degrade performance by innocent changes. That is usually when the perf goes to trash.

It takes a lot more work to keep performance good in a large project than just letting it degrade.

I remember using it to encode some videos for a school presentation. I think I needed to make it fit into a CD and play-on-double-click and Bink was the easiest tool to do it in.

From what I heard from Visual Studio folk it is surprising it is not orders of magnitude faster rather than "much faster".

Also I learned to program in Turbo C and Turbo Pascal with its debugger and nothing comes faster (at least nothing single threaded)

Casey mentions that at some point one of these great minds were upset that it was so difficult to write programs because they didn't have things like keyboards or screens. One of them even brings up exciting new developments in electronic typewriters that could be used to improve their workflows.

It is kinda funny that some world-renowed people who invented genius algorithms like quicksort and graph shortest-path were mulling over "hey would be nice if we kept related data together in a struct" and some people were raging over it saying "why you want to change how I work?"

Casey points out that many of the lessons they came to were so obvious that it just became how it is done that no one even remembers it was done in any other way. In the talk the laments it makes it really hard to track down who originally came up with these ideas.

Claude ran npm update (update all dependencies to the latest version compatible with the semver specified) in my repo without telling me when trying to fix some problems. Given that only updates the dependency lock-file I didn't notice and it caused several hours of debugging for me.

It is quite sneaky how LLM output can sometimes bypass human verification like that. No one is going around checking every single line change in auto-generated files. Someone could easily sneak a malicious dependency in there through some online tutorial that the LLM searches for.

Guake and Yakuake have this always-on-top terminal overlay mode which is really nice for this kind of workflow. Works exceptionally well with multiple workspaces I prefer one single big monitor with everything maximized and multiple workspaces.

iterm2 on mac also has a similar mode, but it is a bit finicky to set it up (it is really hidden in the settings).

I use git diff and ctrl+click the file+linenumber which opens my IDE. Works well enough. I use this macro here when there are a lot of changes:

  gdf() { git diff '*'$1'*'; }

  gdf fileName (doesn't need full file name)

  gdf folderName (all files in a folder)

The DPI thing is nuts, any high res monitor these days is unusable without some DPI adjustment.

when LLMs first became popular my first real use for them was to find information about AWS services. LLMs have read it all and can (mostly) synthesize what you ask if it is in the docs.

There is a subset of yaml which is like 99.9% of all yaml code that is fine.

And then you have whatever the hell OpenAPI uses.

You underestimate the cost of "optimization", sometimes it means actually rebuilding large parts of the system. I would not say it is the "easiest" part, but it is usually not what will kill your business though.

US bank accounts don't have IBAN? I thought IBAN numbers were part of the whole Swift system that Russia got locked out of. Shows how much I know about this stuff...

Yeah it is that old saying, the best person to wield power is the one that doesn't want it. High pay and bonuses get rats into the ship, low pay makes no competent sailor want to join your crew.

Yeah this is what I have seen in the orgs I been in too (although not as bad as you pointed out), I have also seen CEOs fail by inaction like you pointed out (not laying off people doing bad things).

Although I am more afraid of the middle manager who hides information than the CEO who doesn't act on it.

Why? If anything it makes complete sense:

1) Local inference means more general GPUs and less ASIC hardware. Only big companies can push ASIC because of the software required, meanwhile nVidia owns cuda which is the standard.

2) Local is less resource-efficient per chip (chips remaining idle much more, meaning more chips required).

3) End-customers have less bargaining power compared to hyper-scalers. Although this might change if customer hardware start behaving more like phones (SoC with everything packed in), but even then the SoC makers will likely still have less bargaining power than hyper-scalers. But then nVidia could potentially make the whole SoC too.

So overall local-inference users = higher profit margins for nvidia. They much rather have every business on the globe buy one nvidia rack (or every laptop have a beefy GPU) than have 5-10 hyperscalers buy a few hundred thousand.

I dunno most CEOs I have been under of seem to work really hard and try to get stuff done in a sane manner, it is usually the middle management that fs up.

CEO is, of course, partly responsible for having that middle management in the first place. However if I were the CEO I don't even know how I would be able to smell the rats with the top-down view that CEOs have (they can't be in every meeting and decision making of their subordinates).

If you have the right underlings (or inherit them) you might actually not need to do anything at all and succeed. Then again if you have the wrong underlings (or inherit them) then your job is hella-difficult.

This is not what I said, I said that Canada has internal tarifs between provinces while being in (albeit limited) free-trade agreements with other countries. Making some types of internal trade _more_ bundersome than foreign trade.

I work with music streaming, I don't really know how to judge what is low-ticket vs high-ticket. However it is a medium-to-high margin business.

Our free tier is time-limited but we still look at all tickets even from non-paying customers (in the hopes of converting them). A 1-hour intervention from a customer rep can result in a multi-year paying customer.

Language, payroll-rules and tax-rules alone can be enough to prevent a business from expanding into a market. Even when there is no foul intent, just different set of rules.

I am from Brazil and it is not unusual for companies to operate only within certain states because of this. Even though Brazil is a single country with a single language and mostly federal rules about things, there is still enough variance of laws from one state to another to cause problems.

Then you hear about Canada which has tariffs between its own provinces, but not to the US. Meaning some products are cheaper across the US border than across a province border. Figuring out how much to pay in taxes alone can be a blocker...

This is not an EU-only problem, any large single market will have friction in its internal divisions. It tends to be worse in the EU because the countries have a lot more sovereignty though (enforcement agencies tend to be local, not federal for example).

Android devices are unlocked, non-manufacturer OSes are still well outside of "easy" to install, much less get all features working.

The main problem is that people maintaining the OS build for your hardware is the same people making the hardware. If legislation forced to divest both into separate companies the support would last far, far longer.