I find Claude Code features fall into 2 categories, "hmmmm that could be actually useful" vs "there is more kool aid where that came from"
HN user
binocarlos
asyncrocity
I mashed F5 like a degenerate.
I love the style of this blog-post, you can really tell that Luke has been deep down in the rabbit hole, encountered the Balrog and lived to tell the tale.
I use https://github.com/braden-w/whispering with an OpenAI api key.
I use a keyboard shortcut to start and stop recording and it will put the transcription into the clipboard so I can paste into any app.
It's a huge productivity boost - OP is correct about not overthinking trying to be that coherent - the models are very good at knowing what you mean (Opus 4.5 with Claude Code in my case)
I agree with this - I hear a lot of hate towards vibe coding but my experience with voice dictation and using 20 years experience in the trenches and so being very specific telling the model what to do has been, well, refreshing to say the least.
I used to pride myself of knowing all the little ins and outs of the tech stack, especially when it comes to ops type stuff. This is still required, the difference is you don't need to spend 4 hours writing code - you can use the experience to get to the same result in 4 minutes.
I can see how "ask it for what you want and hope for the best" might not end well but personally - I am very much enjoying the process of distilling what I know we need to do next into a voice dictated prompt and then watching the AI just solve it based on what I said.
I would pay hundreds of dollars per month for the combination of cursor and claude - I could not get my head around it when my beginner lever colleague said "I just coded this whole thing using cursor".
It was an entire web app, with search filters, tree based drag and drop GUIs, the backend api server, database migrations, auth and everything else.
Not once did he need to ask me a question. When I asked him "how long did this take" and expected him to say "a few weeks" (it would have taken me - a far more experienced engineer - 2 months minimum).
His answer was "a few days".
What I'm not saying is "AGI is close" but I've seen tangible evidence (only in the last 2 months), that my 20 year software engineering career is about to change and massively for the upside. Everyone is going to be so much more productive using these tools is how I see this.
I helped work on the RAG part of this :-)
We used https://github.com/pgvector/pgvector under the hood and found it extremely easy to integrate with our database schema - being able to just specify the structure of a table and have metadata fields alongside the embeddings made the code very easy to reason about.
Excellent link thank you - I will make sure we check this out because as the README says:
Finetune Mistral, Llama 2-5x faster with 70% less memory!
Could be very useful for us!
Disclaimer: I work on Helix
Great question! scheduling workloads onto GPUs in a way where VRAM is being utilised efficiently was quite the challenge.
What we found was the IO latency for loading model weights into VRAM will kill responsiveness if you don't "re-use" sessions (i.e. where the model weights remain loaded and you run multiple inference sessions over the same loaded weights).
Obviously projects like https://github.com/vllm-project/vllm exist but we needed to build out a scheduler that can run a fleet of GPUs for a matrix of text/image vs inference/finetune sessions.
disclaimer: I work on Helix
We are finding that fine tuning is very good at setting the style and tone of responses. A potential use case we are thinking about is what if your star sales person leaves the company? Could you fine tune an LLM on their conversations with customers and then do inference where it would write text in the style of your star sales person.
We are also adding function calling so the model would know to reach out to an external API to fetch some data before generating a response.
disclaimer: I work on Helix
Thanks for the feedback - I agree that fine tuning a) has potential and b) is not easy :-)
Also, I don’t get the comparison of rag vs finetuning in articles like this - why not do both
It's interesting you say this because we are very close to adding RAG support to Helix sessions and it will be "both at the same time" not an "either or" setup. You can choose to do either or but we are interested in seeing if doing both at the same time yields better results than either or - watch this space!
disclaimer: I work on Helix
This is spot on, the thing we've not yet done is make it easy to import a repo(s) code and the associated metadata into a fine tuning session easily.
I often wonder how you'd go about organizing training data for a full historic github repo in a way that makes sense for training (or RAG)?
This is the hard part :-) But you are right - it would be intriguing to see what the output of a fune-tuned & RAG model would look like for this use-case. We are currently experimenting with adding RAG alongside the fine tuned model (so it's both, not either or) to see if it produces better results.
I will make sure we take a look at the gihub repo use case because it feels like that would be an interesting experiment to do!
disclaimer: I work on Helix
Fine tuning on your documents will really help to answer questions in the style and tone of those documents, so in that way, yes it helps.
It would be possible to include some parts of the new documents in the prompt so you can answer questions about new facts in the style and tone of your old documents, which we feel is useful. We are also experimenting with adding Retrieval Augmented Generation alongside fine tuning to see if the results are better than either or.
disclaimer: I work on Helix
I use hacker news as my "is my Internet working" test - it's fast and always up (kudos)
So yes, I also thought my Internet was broken :-)
This is a really cool blogpost - that you can influence a model with guidance towards a desired outcome feels like a really valuable feature. I'm currently working on a project that is generating stable diffusion images and this kind of technique would be so useful ;-)
thanks! we were stuck with exactly that problem and decided "it's David Bowie" let's try something different :-)
We are thinking for people writing documentation, blogs or Intranets where there are many different pages and there is a more polished sense of branding.
You are quite right that if you want to quickly publish a single page - using Google docs directly would be faster :-)
Thanks for giving it a test!
Thanks for the feedback!
Yes - dealing with access to a users entire drive is something we are looking at to try and get working for exactly that reason - the words `this app can delete all your files` is scary :-)
There isn't an option to remove the footer but should be +1 added to backlog - thanks again!
We've been working hard on https://nocode.works - which turns Google docs into nice looking websites - it's not pluggable yet but it doesn't require any setup on behalf of the user.
We do have a template system though so it would be possible for a frontend dev to design their own wrapper for the content.
Shameless plug: We've been working hard on https://nocode.works - which turns Google docs into nice looking websites.
We think it's perfect for documentation for non-technical companies who don't know what Markdown is.
Perhaps part of that was that IE was really bad at it's job and as users were told about Chrome and Firefox and they tried it and it was much faster - they switched because IE was not nearly as good. Facebook is pretty good at it's job - despite questionable practices. If Facebook started to suck from a user perspective (a bit like MySpace did) - users would move to another thing in a shot.
Take Basic Attention Token (https://basicattentiontoken.org/) as an example - it is attempting to remove YouTube as an advertising middle-man that controls and takes a cut of ad revenue. By creating a marketplace where advertisers pay content creators directly, it in my mind represents a direct threat to how YouTube operates today.
I use redux a lot and love the way you can reason about the state of the app from a single object - which opens up all sorts of useful things like time-travel etc.
However - after having plugged in a lot of reducers - the boilerplate code required to do simple stuff becomes a real bore. I've since compromised by using a simple `key-value store` reducer that I can write new values to without needing a new reducer with accompanying actions.
I'm sure this is not how it's supposed to be used but nobody ain't got no time for making all that boilerplate just for a button :-)
Like I say - it's worth it though - it's amazing how large frontend apps "just work" once you have the state in a single place and the UI rendering from it and it alone.
Thanks for the feedback - "docker push <mydata>" is nice :-)
For the same reasons as you mention in your post, we've been hard at work with Kubernetes support - Persistent Volumes but with extra features!
Thats the idea yes! you can run dotmesh on your own servers and install locally on each users machine to then push and pull just like git remotes. It's using copy-on-write so you are only pushing the difference. Another main use case is for CI to consume volumes, run tests then snapshot the results.
We have a hosted service if you don't want to run your own nodes (https://dothub.com) but the server and client are both open source. disclaimer: I work on the project
Yes good point - I was replying to the above comment:
It's being hyped like TRON
Ok - I meant non-blockchain databases
The TRON hype train has been getting a lot of kickback recently on Reddit - claims they have been stealing content from other white papers and copying non attributed GPL code from other projects - current market cap 4.7 Billion - make of that what you will :-)
* https://www.reddit.com/r/CryptoCurrency/comments/7qfjef/tron...
Indeed - Raiden is all about payment channels - funds are deposited on the main chain and then payments can be sent over channels with no fee. Only in the case of dispute or cashing out is the main chain used to resolve the conflict. This means you could make many transactions per second of very small amounts (useful for things like gambling sites or micro-payments for content). Micro-Raiden is already active which are one-to-one payment channels - the full Raiden network is not yet live but will facilitate one-to-many channels.
The eth devs are busy working on sharding - the same idea as traditional databases like Mongo where a primary key decides which node the data will reside. The main problem here is that a contract residing on shard A might reference a contract on shard B (much like a join between 2 shards). They are approaching this by using "transaction receipts" that would be passed from shard to shard. https://github.com/ethereum/wiki/wiki/Sharding-FAQ
There is a bunch of work happening with Ethereum to address the scalability problem, namely Proof of Stake and Sharding as well as complimentary systems like Raiden that use the main blockchain for dispute resolution and not every payment. I expect 2018 to be a busy year for Ethereum development!