meet.hn/city/pl-Warsaw
Socials:
- github.com/zby
- linkedin.com/in/zbigniewlukasiak
- x.com/zby ---
- zby parentLSPs should expose their api through shell commands - then integrating it with any LLM would be trivial. And it would also be very useful for humans.
- This week I vibe coded an golem-forge (https://github.com/zby/golem-forge) - exploration of prompting as programming. Since then I found https://github.com/badlogic/pi-mono and https://github.com/johnlindquist/mdflow and I think I'll rather use these existing tools to explore my idea. But I think it might be still interesting project because it is entirely vibe-coded - I don't even know Typescript (I know some Javascript from before React - but none of the new stuff). I did not look into the Typescript code at all - only at what the LLM presented to me when editing it and the docs. At some point I discovered that when I tried to have a core logic and two UI packages the LLM put only types in the core package - so I had drive a hard refactoring - but it worked.
I haven't yet tried this very extensively - but another profound change in programming that this showed me is that it is now very easy to borrow parts of Open Source libraries. It used to be that you could only base your work on a library - borrowing parts of projects that were not designed to be shared (used as libraries) was prohibitive - but with llms it is entirely possible to say: "now please borrow the UI ideas from project X" and it does that. Maybe you need to add some planning.
The project is about 27kloc now.
- Well - the point of involving the AI is that very often it explains my intuitions way better than I can. It instantiates them and fills in all the details, sometimes showing new ways.
I find the second paragraphs contradictory - either you fear that I would agree with random stuff that the AI writes or you believe that the sycophant AI is writing what I believe. I like to think that I can recognise good arguments, but if I am wrong here - then why would you prefer my writing from an LLM generated one?
- What is banned here? I can only find guidelines: https://news.ycombinator.com/newsguidelines.html not rules.
- I strongly disagree - when I post something that AI wrote I am doing it because it explains my thoughts better than I can - it digs deeper and finds the support for intuitions that I cannot explain nicely. I quote the AI - because I feel this is fair - if you ban this you would just lose the information that it was generated.
- Most of things that were considered reasoning are now trivially implemented by computers - from arithmetic, through logical inference (surely this is reasoning - isn't it) to playing chess. Now LLMs go even further - what is your definition of reasoning? What concrete action is in that definition that you are sure computer will not do in lets say 5 years?
- "The LLM learns 2nd hand heresay, with no idea of what's true or false, what generalizations are valid, or what would be hallucinatory, " - do you know what is true and what is false? Take this: https://upload.wikimedia.org/wikipedia/commons/thumb/b/be/Ch... - Do you believe your eyes or do you believe the text about it?
- I believe that what we need is treating prompts as stochastic programs and using a special shell for calling them. Claude Code and Codex and other coding agents are like that - now everybody understands that they are not just coding assistants they are a general shell that can use LLM for executing specs. I would like to have this extracted from IDE tools - this is what I am working on in llm-do.
- LLMs were trained on the how we use text interfaces. You don't need to adopt command line for an LLM to use. You don't really need RAG - just connect the LLM to the shell tools we are using for search. And ultimately it would be much more useful if the language servers had good cli commands and LLMs were using them instead of going via MCP or some other internal path - ripgrep is already showing how much more usable it is this way.
- Great idea!
I have been thinking about similar systems: https://web.archive.org/web/20061014073443/http://zby.aster....
- There is a clarification tweet from the authors:
- we cannot extract training data from the model using our method
- LLMs are not injective w.r.t. the output text, that function is definitely non-injective and collisions occur all the time
- for the same reasons, LLMs are not invertible from the output text
- I am wrapping up https://github.com/zby/DayDreamingDayDreaming - it is a project to show that https://gwern.net/ai-daydreaming can work.
It is hard to show that AI can reimplement for example special relativity - because we don't even have enough text from 19th century to train an LLM on it - so we need a new idea something that was invented after an LLM was trained. I took the Gwern's essay and checked with deep search and deep research which ideas from that essay are truly novel and apparently there are some so reinventing them seemed like a good target: https://github.com/zby/DayDreamingDayDreaming/blob/main/repo... https://github.com/zby/DayDreamingDayDreaming/blob/main/repo...
So here it is - a system that can reliably churn essays on daydreaming AIs. On one level it is kind of silly - we already knew that infinite monkeys could write Shakespeare works. The generator was always theoretically possible, the hard part is the verifier. But still - the search space in my system is much smaller than the search space of all possible letter sequences - so at least I can show that the system is a little more practical.
Here are some results: https://github.com/zby/DayDreamingDayDreaming/tree/main/data...
You can modify it to reinvent any other new idea - you just need to provide it the inspirations and evals for checking the generated essays.
I am thinking about next steps - maybe I could do it a little bit more universal - but it seems that to build something that would work as needed would require scale.
I kind of like the software framework I vibe coded for this. It lets you easily build uniform samples where you can legitimately do all kinds of comparisons. But I am not so sure about using Dagster as the base for the system.
- What do you think about: https://unlockgpu.com/? I put it on hold because the shareholder resolutions has to propose some concrete board level changes - and it seems (or seemed a few months ago) that AMD really started implementing such changes.
- It is quite frustrating that we have these discussions over and over again. Asynchronous communication is great - but it is not better than synchronous communication in some universal way. It depends. Personally I am very sensitive to interruptions - so I lean towards asynchronous. But when you are doing something and you really need to get some information from someone to proceed - then getting his response immediately means that your work is not interrupted. The other person is - but it is a trade off. In a team you have to make these trade-offs. It can be hard - because it takes from one side and gives to the other - people would like to be able to interrupt others and not be interrupted themselves. And it is even more complicated by the fact that some jobs and some people are more sensitive to interruptions and others are less - so it is hard to make fair rules about it. But it is a real trade-off to be made.
UPDATE: Or take interactivity - a conversation is really powerful way of communicating. How a computer geek could even claim that asynchronous communication is always better - is he still using batch processors to run his jobs typing everything upfront and they waiting for the full run before he can fix his syntax errors?
