capplexham

I searched for: "Memes and jokes surrounding Dario Saric's delay in moving to the USA when drafted in 2014."

And got a good answer. Google's not weird, you just need to recognise that Dario is ambiguous, especially with Dario Amodei being much more famous.

Nothing to see here, except people thinking Google / AI can read their minds when they aren't specific enough.

The paradigm shift from ETL to ELT is what went wrong with Data Lakes. An enormous amount of business logic and effort was historically accumulated in the Extract-Transform stage (usually in COBOL or SQL), and then Loaded into a Data Mart for end-users.

When ELT became the corporate "Strategy", Extract-Load was technically easy and had a lot of Big Data evangelism and exuberance behind it. The money flowed easily at the beginning, but budgets aren't unlimited and corporate knowledge isn't easy to retain. So Data Lakes became Swamps of just Extract-Load, and business users were told to transform the data themselves.

As someone who lived through it for 12 years at an Insurance company, I like to think of it as ETL becoming Extract-Load-GoFuckYourself.

Have a look at the prompts in the GitHub [0]. It defines a System Prompt and specifies the documentation structure. This would allow you to switch coding agents, instead of relying on how your coding agent interprets the command "write docs".

[0]: https://github.com/langchain-ai/openwiki/blob/main/src/agent...

Click "Show Options", then:

- Check "Show chords on piano?"

- Check "Play chord sounds"

- Uncheck "Play feedback sounds"

For the "Chords", start with just Red and Blue. Then add Yellow.

I don't have perfect pitch, and I could not distinguish between Red and Blue, when Yellow was in the mix and the feedback sounds interrupted the trials.

Black and Green were much easier for me to differentiate, but Red / Blue is really difficult.

> The LLM makes this easier but the improvement drops to about 2-3x b/c there is a lot of back and forth + me reading the code to confirm etc

This makes sense when you stop viewing the LLM as a "vending machine" for apps and start seeing it as a repository of software deltas.

LLMs aren't just trained on final code; they are trained on the entire history of pull requests, review comments, and issue discussions that move a project from one version to the next.

When I use an LLM now, my workflow has shifted entirely. I’ve stopped trying to be the "coder" and have instead stepped into the role of PR Reviewer and Power User. My job is to point out edge cases, define the spec, and catch regressions—effectively managing a "virtual team" that handles the boilerplate and feature implementation.

Expecting a one-shot 1.0 release is unrealistic because it bypasses the thousand micro-decisions that happen in a real dev cycle. By embracing the "review and refine" loop, I’m becoming a better maintainer, even if that 100-hour gap to a polished product still exists.

This isn’t surprising when you consider how LLMs are actually trained to write code.

Expecting a one-shot 1.0 release is unrealistic because the sheer volume of context and decision-making required for a finished product is enormous.

Instead, I think of LLMs as being trained on the "delta" of software development: the pull requests, review comments, and issue discussions that move a project from one version to the next.

When you use an LLM for coding, you are effectively tapping into the collective output of a team of developers and a crowd of users. My mental model has shifted accordingly: I no longer try to be the "coder." Instead, I act as the PR reviewer and the passionate power user. My job is to point out edge cases and refine the output, rather than expecting a finished product in one go.

It’s making me a better maintainer and a more precise communicator, even if the "100-hour gap" to production remains a reality.