hellodanylo

If need anything more complicated than simple $var substitution, it's time to use a general purpose scripting language with appropriate libraries to generate your data structure. A half-baked template DSL will never work.

Why not buy a giant display panel and connect it to a computer that you fully control?

I don't seem to understand where OpenAI's market segment ends and Azure's begins.

> I question just how much productivity you've gained.

Me too. It's an empirical question to be answered by those who will dare to try.

> It's kinda like self-driving cars

Strong disagree. Yes, neural nets are blackboxes, but the generated code can be idiomatic, modular, easy to inspect with a debugger, etc.

> more formally specify the problem that an LLM is being asked to solve.

That would be a great direction to explore.

This should give a second life to Test-Driven Development.

One of the under-appreciated wisdoms of TDD is that there is a complexity asymmetry in many problems between finding a solution and (fully or partially) verifying it. Examples of asymmetric problems: inverting matrices, sorting an array, computing a function's gradient, compressing a byte stream, etc.

Human writes the easier part -- the test suite, the language model writes the harder part -- the solution. This can be a net gain in productivity.

There is a major flaw in placement of the EC2 instance in this diagram.

Each EC2 instance has 1 or more Network Interfaces, where each Network Interface resides in 1 subnet and can have multiple public and private IP addresses. The diagram currently suggests that an EC2 instance is located in a single subnet — it’s not. Each Network Interface connected to an EC2 instance is only required to be in the same Availability Zone where the instance was launched.

I would rephrase this concern as "dconf is not a stable API" rather than "you are not supposed to do this". It's my computer, I am supposed to do whatever I want, but using unstable API comes with costs that should be understood.

I find SQL very hard to use when the data schema and/or transformation graph needs to be dynamic (e.g. depends on the data itself). It's hard to make SQL dynamic even at build time -- Jinja+SQL is one of the worst development experiences I have ever had.

Yeah, I am also struggling to interpret the metrics in this post positively.

The 50% success rate is also best out of 3200 completions. For best out of 1 completion, the success rate is in low single digits.

I think the lesson here is that these models bring a lot more value when: 1. you have unit tests, 2. can afford compute/time to let the model try many solutions, 3. have enough isolation to run unverified code.

> I'm sure the recovery process is not as easy.

A lot of services offer one-time backup codes and connecting multiple 2FA devices. Making Yubikey a single point of failure is certainly a bad idea.

> Authenticators are fine, except if you lose a couple of smartphones too close together, or you need a team to access one account.

When you enable TOTP with a service, you can extract the TOTP secret and do all of the above with it -- backup to storage, copy to new devices, distribute to multiple people, etc.

In my recent job, I committed Jupyter notebooks to Git, and they tend to be giant JSON files. I had 10x SLOC of anyone who did not commit Jupyter notebooks.

If you had 3 days to find bottom 50% of devs to be fired, what would be your heuristic?