After two years of vibecoding, I'm back to writing by hand

> The Greeks and Romans had weightlifting and boxing gyms, but no forklifts.

We may not have any evidence that they had forklifts but we also can't rule out the possibility entirely :)

They may know the area they are responsible for, but they don't know all of the details of everything else and just have to trust that other people are doing the right thing and following contracts correctly. It doesn't require anyone to have full global understanding. Having local experts is good enough.

Yes! Don't worry about it, I very much agree. However, I do think that even if/when I'm using Lisp and have all the best structural editing capabilities at my disposal, I'd still prefer to have an agent do my editing for me; I'd just be 30% more likely to jump in and write code myself on occasion — because ultimately, even with structural editing, you're still thinking about how to apply this constrained set of operations to manipulate a tree of code to get it to where you want, and then having to go through the grunt work of actually doing that, instead of thinking about what state you want the code to be in directly.

Vehement agreeing below:

S-expressions are a massive boon for text editing, because they allow such incredible structural transformations and motions. The problem is that, personally, I don't actually find Lisp to be the best tool for the job for any of the things I want to do. While I find Common Lisp and to a lesser degree Scheme to be fascinating languages, the state of the library ecosystem, documentation, toolchain, and IDEs around them just aren't satisfactory to me, and they don't seem really well adapted to the things I want to do. And yeah, I could spend my time optimizing Common Lisp with `declare`s and doing C-FFI with it, massaging it to do what I want, that's not what I want to spend my time doing. I want to actually finish writing tools that are useful to me.

Moreover, while I used to have hope for tree-sitter to provide a similar level of structural editing for other languages, at least in most editors I've just not found that to be the case. There seem really to be two ways to use tree-sitter to add structural editing to languages: one, to write custom queries for every language, in order to get Vim style syntax objects, and two, to try to directly move/select/manipulate all nodes in the concrete syntax tree as if they're the same, essentially trying to treat tree-sitter's CSTs like S-expressions.

The problem with the first approach is that you end up with really limited, often buggy or incomplete, language support, and structural editing that requires a lot more cognitive overhead: instead of navigating a tree fluidly, you're having to "think before you act," deciding ahead of time what the specific name, in this language, is for the part of the tree you want to manipulate. Additionally, this approach makes it much more difficult to do more high level, interesting transformations; even simple ones like slurp and barf become a bit problematic when you're dealing with such a typed tree, and more advanced ones like convolute? Forget about it.

The problem with the second approach is that, if you're trying to do generalized tree navigation, where you're not up-front naming the specific thing you're talking about, but instead navigating the concrete syntax tree as if it's S-expressions, you run into the problem the author of Combobulate and Mastering Emacs talks about[1]: CSTs are actually really different from S-expressions in practice, because they don't map uniquely onto source code text; instead, they're something overlaid on top of the source code text, which is not one to one with it (in terms of CST nodes to text token), but many to one, because the CST is very granular. Which means that there's a lot of ambiguity in trying to understand where the user is in the tree, where they think they are, and where they intend to go.

There's also the fact that tree-sitter CSTs contain a lot of unnamed nodes (what I call "stop tokens"), where the delimiters for a node of a tree and its children are themselves children of that node, siblings with the actual siblings. And to add insult to injury, most language syntaces just... don't really lend themselves to tree navigation and transformation very well.

I actually tried to bring structural editing to a level equivalent to the S-exp commands in Emacs recently[2], but ran into all of the above problems. I recently moved to Zed, and while its implementation of structural editing and movement is better than mine, and pretty close to 1:1 with the commands available in Emacs (especially if they accept my PR[3]), and also takes the second, language-agnostic, route, it's still not as intuitive and reliable as I'd like.

[1]: https://www.masteringemacs.org/article/combobulate-intuitive...

[2]: https://github.com/alexispurslane/treesit-sexp

[3]: https://github.com/zed-industries/zed/pull/47571

Can you just clarify the claim you're making here: you personally are shipping vibe coded features, as a PM, that makes it into prod and this prod feature that you're building is largely vibe coded?

Accurate and sane take! Current models are extremely good for very specific kinds of tasks. But beyond that, it is a coin toss. Gets worse as the context window goes beyond a few ten thousand tokens. If you have only vibe-coded toy projects (even with the latest fad - Ralph whatever) for anything serious, you can see how quickly it all falls apart.

It is quite scary that junior devs/college kids are more into vibe coding than putting in the effort to actually learn the fundamentals properly. This will create at least 2-3 generations of bad programmers down the line.