why-el

Because of your multiple "I am tired of saying this, but this text was written by me and not an LLM" in your blog posts, I want to tell you that I read it word for word. :D I know this comment adds not much but I felt it needed to be said.

So far a Rust rewrite's success rate directly, probably super linearly, correlates with the presence of a good, well designed test suite. This is why Bun's rewrite and others are successful. I anticipate that this will be true for the 37Signals rewrites.

I want to learn a couple of things once they are done:

1. Once the test suite assistance is over, how do features get built in their backends and continue to maintain the same quality. LLM test writing is a bit trickier as it often favors what Randy Coulman called tautological tests back in the day. It takes a lot of work to get them not to do this, so I am guessing folks at 37Signals will read at least this part. I can't imagine zero Rust read at all.

2. Over the years they had a few innovations in their domain design, ones that Rails made easier to do, for instance their delegated type pattern. Will Rust replicate this, and how would one know without reading it, or perhaps it does not matter? Furthermore, how do newer patterns emerge? and how does our arsenal of better abstractions keep growing?

I don't have the answers but I am glad there is a chance we can learn said answers.

> a register is a mechanical device to power and maintain,

surely a million times less expensive than a subscription to a POS....this is not a strong argument.

I would assume they actually moved off of litestream here no? otherwise how can their frequent manual checkpointing even succeed when litestream locks for the same behavior.

For sure. The literal first two pages of any book, essentially the back of the cover and the title page, always host a huge list of pages plus summary of something interesting i saw in the book. For instance, it will say something like:

* p85, interesting semaphore usage

or some such. This also condenses the books to important things so I can do a speed read to recall the most important parts.

For Oauth I'd like to borrow what I would describe humbly as a better analogy, and it comes from Douglas Crockford, and so adapting it from him commenting on Monads in Functional Programming, it goes something like this:

"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."

Chomsky never argued it was words (and how couldn't it be words, for there are millions of words from 100s of 1000s of languages), just a configuration to eventually learn those words.

I am not sure if this will help you, but have an extended, deep conversation with ChatGPT about your resume. Tell it who you are, what you excel at, and list projects and technologies. Then, paste a couple of the job postings that did not work for you.

This might sound silly to you, but it absolutely works, because it will distill your experience better, ask you to re-arrange and generalize, and more importantly, it is far superior to us in finding unique key word combinations that work.

the user who wants it? and a premature retort: if the feedback is "the user / PM / stakeholder could be wrong", then... that's where we are. A "refiner" LLM can be fronted (Replit is playing with this for instance).

To be clear: this is not something I do currently, but my point is that one needs to detach from how _we_ engineers do this for a more accurate evaluation of whether these things truly do not work.

I am not so sure. Code by one LLM can be reviewed by another. Puppeteer like solutions will exist pretty soon. "Given this change, can you confirm this spec".

Even better, this can carry on for a few iterations. And both LLMs can be:

1. Budgeted ("don't exceed X amount")

2. Improved (another LLM can improve their prompts)

and so on. I think we are fixating on how _we_ do things, not how this new world will do their _own_ thing. That to me is the real danger.

> "ask you"

I get the concern, however. But, short of nuking the actual .git directory, the upsides are worth it, in my opinion. Cursor offers filtering via a mini-prompt in its YOLO mode, so does Windsurf. The idea is killer, it allows it to progressively build and also correct its own errors. e.g. Cursorrules can be told to run tests after a feature is generated, or typecheck, or some other automated feedback-loop your codebase offers. That's pretty neat!

Better yet, setup a dev container first. Then, at most, your local DB is the only concern. If still paranoid (as you should be), suspend your network while the agent is working. :D

I was hoping the LLM is the staff engineer? can read both ways.

your incident lingo will be fun.

not to be confused with "Drunk Magnus", a very strong player.