rbongers

I just happen to spend 40 hours of my life working a week and would like to enjoy as much of it as possible. Not doing so not only drains joy from a massive portion of my limited time on this Earth, but makes it harder to utilize the time I have available if all my energy is drained.

It would also be nice to have work readily available related to the field I've been building skills in for over a decade that I know isn't going to disappear suddenly. Prompt engineering is already dead. I suspect any skills you learn now to utilize AI is not going to last more than a few years.

I feel like I'm taking crazy pills a little when it comes to this subject. Maybe everyone else already has ridiculous money saved, or has other things lined up, or are just ready to move into a Monastery. But for those of us in the middle of our careers and with no AI-proof capabilities the future is at the very least uncertain.

Previously there was no way to pay someone to solve a problem without someone going through the process of solving it. I think what people are upset about is that any kind of problem solving is no longer a stable career path. Even the skills replacing the problem solving jobs are liable to disappear as the interfaces are refined and models improve.

There is a difference between the process of solving a problem and a problem being solved. If I solve a problem myself, I understand it, I find out something new, I get to try lots of things. It's engaging and fun. If I tell you to go solve a problem, I can learn it afterwards but I miss out on the entire process.

Personally, I enjoy the process of solving problems. I do not enjoy wrangling unpredictable AI agents.

Unfortunate for those of us who really dislike that work.

Hard to truly understand the work unless if you're actually doing it.

AI is great at reviewing code. It is not great at reviewing intention. If the prompt was bad, not understanding or thinking about how to implement the feature properly, the review usually doesn't point out exactly what's wrong. This can lead to a sort of "polishing a turd" approach to code reviews where you patch some of the negative side effects for an implementation that is completely wrong.

This is a result of AI still being bad at telling the prompter "no". Not only because it will blindly reproduce what you tell it to while writing code without pushing back on assumptions without asking, but because it will often blindly accept an implementation approach while reviewing.

I suspect this is a hard problem, because if AI stops listening at the wrong time it can be a massive inconvenience.

I have noticed that AI is slowly getting better at pushing back on different types of things each time the frontier models get better though. I've also noticed on reviews that it will tend to hallucinate or nitpick around the problem. I assume it sees something wrong there, starts generating output, and points out something different there instead because there is pressure to be both agreeable and helpful, which are not always compatible.

I think it is getting better, but it can't always see the forest for the trees.

Two very useful directives to give AI when it comes to documentation:

1) Document what's there, not the diff. Documentation of how code was removed or changed to fix a bug or add a feature is not useful and difficult to maintain; documentation should explain how code works now.

2) Documentation should live close to the source as possible. Prefer line based comments and standardized function documentation. Top-level sweeping architectural essays are not maintainable for every change.

The last will depend on your codebase. It CAN be very useful to have a human-readable spec documented for the entire program and have it updated when anything changes. But the key is again, you're CHANGING it every time. If you add a whole new disconnected documentation file it should set off alarm bells; nothing in one system is truly disconnected.

They believe in the danger of out of control super-intelligence. The generous interpretation is that they believe they can contain it.

The worst part about this to me is if someone routes a response through AI, I have no idea what they, personally, are trying to tell me that they may have included specifically in their prompt, what is hallucination, and what is something in-between.

It makes it hard to pick apart hallucinations from the miscommunications and disagreements. Picking apart every single point and treating it with the same tact you have to treat human output with, while still accounting for the fact that it could be a hallucination, takes an extremely skewed amount of effort compared to the effort of sending someone AI output. The worst part is, it's probably going to be pasted right back into the LLM chat box.

It's astonishingly bad form to send someone AI output, and this is only one of the reasons.

It's not an acceptable tradeoff to allow AI code in without reviewing the code currently, if not when it comes to code structure (which will introduce long term maintenance issues if it creates endless spaghetti code regardless of if AI is contributing or not), then at least when it comes to security.

Finally, a tool optimized for creating Git commit hash collisions

I view current LLMs as new kinds of search engines. Ones where you have to re-verify their responses, but on the other hand can answer long and vague queries.

I really don't see the harm in using them this way that can't also be said about traditional search engines. Search engines already use algorithms, it's just swapping out the algorithm and interface. Search engines can bias our understanding of anything as much as any LLM, assuming you attempt to actually verify information you get from an LLM.

I'm of the opinion that if you think LLMs are bad without exception, you should either question how we use technology at all or question this idea that they are impossible to use responsibly. However I do acknowledge that people criticize LLMs while justifying their usage, and I could just be doing the same thing.

I only reached the 100s back in the day. What amazed me was that it seemed like every problem had a paper solution, when it would take any computer algorithm thousands or millions of computations to solve the same problem.

Keywords should definitely be highlighted. It's part of the structure of the code. Being highlighted makes it very quick to distinguish between keywords and variables and helps readability by making them easier to skim over and jump to. Maybe they could be the same color as punctuation, if number of colors is a problem.

All of this guy's software and music seems so cool, and there's so little information on it. Can you share anything else?