I do not use an explicit "plan mode" that tries to limit what the LLM can do. But I do tell it to explore and research and produce an artifact of what needs to happen to finish a large ticket and then use that as input to the actual implementation. I do have it even write small experiments to verify some-parts of the total design to connect it to reality.

The reason is that there can often be lots of decisions that need a large amount of context about the code base in order to reasonably determine what the right design and implementation is and this doesn't happen (in my experience) with the little Interview dialogue that pops up when it isn't sure. Or, even worse, Opus will just make decisions for you that are incoherent with the goals of the codebase.

So, I think, "plan mode" as an explicit mode is dead, but the act of planning is still a good thing to do.

I think I'm a bit of an outlier here on that k never really understood why durability requires fsync. It doesn't help you if the storage dies. If durable storage is important to you, then isn't the only solution to synchronously replicate to a quorum of machines at which point an fsync isn't that relevant? What am I missing?

If you're an artist, programming is your clay, if you're an engineer, programming is your building material.

Point being, which I always connected with, was that programming is a medium for expressing a lot of things. Just like you can use paper and pen to write poetry or a dry technical manual. And everyone gets to decide how they see it and use it.

I believe LLMs are going to make the bar for a SaaS you would pay for, as a company, higher.

> The planning is happening openly, including a voluntary separation window. That creates real uncertainty for our team over the next few weeks, but we believe the outcome will be better for it.

No good way to execute lay-offs, my preference would be to do it like a band-aid. What use is it to do it in open unless they plan on having gladiatorial matches to keep your job. Otherwise it's just like a painful game of Duck Duck Goose.

1. It supports basically any file transfer protocol.

2. It is a library that is designed for long running processes.

3. Because it's designed for long running processes, it makes use of every trick it can to pipeline and re-use connections and resources.

4. It has an asynchronous API so it can be integrated into any existing event loop.

Is a web browser or database more complicated? Most certainly, they solve really massive problems. But curl is certainly more complicated than probably most application code that uses it.

Comments URL: https://news.ycombinator.com/item?id=47751800

Points: 3

# Comments: 0

1. I subjectively just like it better. Things like dtrace, jails, the init system, just click for me.

2. I think it's good to not support a Linux mono-culture. Yes, there is Windows and macOS, but in terms of open source OS's, I think it's good to have more than one choice and so for any rough edges in FreeBSD, I'm willing to deal with them to support that goal.

3. I don't think you'll find any actual, hard, technical reason to want to prefer FreeBSD over Linux on a desktop. Anything you can do in FreeBSD you can do in Linux. Heck, FreeBSD is probably even running the Linux version (for example video drivers).

But really, which Linux do you mean? Nix? Gentoo? Red Hat?

1. AI is meant to make us go faster, reviews are slow, the AI is smart, let it go.

2. There are plenty of AI maximizers who only think we should be writing design docs and letting the AI go to town on it.

Maybe, this might be a great time to start a company. Maximize the benefits of AI while you can without someone who has never written a line of code telling you that your job is going to disappear in 12 months.

All the incentives are against someone who wants to use AI in a reasonable way, right now.

I have been using Argus in anger for a few days, it needs some updates, but being "run on your own desktop" software means it can be a lot simpler than a full product, which is nice. Next feature I am pushing to get implemented: I want Reviewboard-like intra-push diffs. I have a force-push heavy workflow and GH PR view doesn't let you see the diff of what was pushed vs what I last reviewed, and that is a feature that all the data is there and I want it.

1. I want to deploy to a testing environment where I may want to use different users, different sized services, or even mock services so I don't have to pay for them? 2. I want to develop in an isolated environment (maybe without internet or simply I'm trying to develop a narrow feature that doesn't require the rest of the infrastructure)? 3. How does it handle security elements like VPCs, IAM roles, all these things that are the context my application runs in that I don't necessarily want to couple to my application code?

As comparison, if a programming language forced you to split your software into multiple executables when you got to a certain number of functions, I think, almost universally, we would say that it's not a production language. That is a stupid limitation and forcing development work on users because of stupid limitations is disqualifying.

But for TF, even if we are refactoring it because the tool is doing it, we tell ourselves that it's a good idea anyways because of good software practices. But splitting infrastructure over multiple root modules is, in my analogy, the same as being forced to do it over multiple executables. It comes with a lot of unnecessary limitations.

With Stategraph, you can choose to split your infrastructure over multiple root modules, if that is what you want to do, not because you don't have a choice.

V1 of Stategraph is a drop-in TF/Tofu replacement, but once it's there, you can see a path to something more like k8s operators, without having to do any migration of infrastructure.