4.2 -> 5 is a problem. Pretty sure official docs recommend creating a new application and porting it rather than trying to perform a 4.2 -> 5 upgrade.
1,069 karma · joined May 5, 2013
mferrara -. at .- gmail
This one only needs electricity and internet access.
It's rather dumb at the moment, but when number gets too high, it kicks on for 1 hour and if it's back below threshold it shuts off. There's also a human presence detector that will "pause" it for 5 minutes since it's in my kitchen window.
It's built out of cardboard (laminated, with wheat paste) as a proof of concept/tinker with design and placement of things and also serves as a platform for the cats to nap in the window.
This, mainly, helps from bringing in all the outside humidity during the summer and the bitter cold during the winter. Otherwise, prior, I'd just keep an exhaust fan running all the time (eating the losses on air conditioning/heat) but we'd end up closing the window when it was super hot/cold and then the iaq would get terrible.
Lots and lots of people are automating their various systems due to monitoring these values. An application I've seen lots of is to just kick on the hvac systems fans when the aq drops below a particular threshold in one room or another.
> Lastly, ensuring your house is positively pressurized by paying a testing and balancing contractor to come over and adjust your HVAC system will do more to keep out particulate matter than measuring it ever will.
Sadly, it took me a while to figure out that having this window fan in my kitchen on "exhaust" rather than "intake" was creating a negative pressure environment and that was.. not optimal.
This is exactly why he's doing it the way he is and why what he describes is still the most effective, albeit labor intensive, way to work on hard/complex/difficult problems with LLMs.
Those tricks are for saving money. They don't make the LLM better at its task. They just make it so the LLM will do what you could/should be doing. We're using agents because we're lazy or don't have time or attention to devote, or the problems are trivial enough to solved with these "tricks" and added complexities. But, if you're trying to solve something complex or don't want to have a bunch of back and forth with the LLM or don't want to watch it iterate and do some dumb stuff... curate that context. Actually put thought and time into what you provide the LLM, both in context and in prompt - you may find that what you get is a completely different product.
Or, if you're just having it build views and buttons - keep vibing.
Before claude code was around I had already learned very quickly that exactly what antirez is describing, literally copy/pasting code into the chat verbatim, was _wildly_ effective. So much so that I had Claude build me a jetbrains plugin to streamline the process for me - I would select the files I wanted to include in context in a tree-style view of the project and it simply had a 'Copy' button that would, when pressed, compile the files into a single markdown document with simple metadata about each included file (filename, path) and a simple "divider" between files.
And, also like OP states, it's wildly more effective to take this approach combined with a new context/session/chat for each new task. (So, with Claude, I used projects heavily for this and this copied context markdown document was added to the project files and then I'd just start a new chat in that project any time I wanted to work on something that included them/that context I had crafted)
Claude Code and the "agent" approach is wildly effective, no doubt. But it doesn't really support this sort of very specific and "heavy" approach the the "problem". Rather - it's actually working pretty hard to use as few tokens as possible and weave through the maze of trying to be token efficient while getting/finding/using context that _is_ available to it but not presented directly to it. Rather - if you just feed it the whole ass class/module/package and provide a detailed, focused and intentful prompt you might be really surprised what you get.
These agents are _really_ going to thrive when the context window isn't a problem anymore. Claude (not code, but the desktop app, so using a "project") essentially one-shot implementing the necessary updates to phpredis (PHP extension in C for Redis) to support the new vector set data type. I first cloned the phpredis repo locally, initialized claude code and told it what I wanted to do and what the repo it was working with was and asked it to analyze the repo and the code and provide me a list of the files that would be essential for it to have in context when building out that new functionality. It provided me the list of files - I packed them up in a claude project and started over there. The only issues were related to it mixing up/assuming some stuff related to standard Redis commands and versions. And it's own tests caught that, fixed it. I only used this extension in my local/dev environments as I wanted to test the vector sets in Redis from within the same ecosystem my application was already working within (phpredis is significantly more performant that it's alternatives (which support the new commands) and it, also, serves as a perfect example of another of antirez's points... the utility provided by these tools to do things as "throwaway" proof of concepts is just amazing. I'm not a C developer, I didn't know anything about compiling php extensions (or how weird that whole ecosystem is in PHP-land) - I would have never gone through that effort to test just one method of doing something prior. I would have just used what was available rather than even contemplating doing something like forking an extension in a language I'm not familiar with and fixing it up the way I needed it to work (only because of time, I'm always down for a challenge, but I can't always afford one).
Context is king. Your ability to communicate to the box what you want is next in line for the throne.
> It's not that hard to write boilerplate and standard llm auto-predict was 95% of the way to Claude Code, Continue, Aider, Cursor, etc without the extra headaches.
Uh, no. To start - yea, boilerplate is easy. But like a sibling comment to this one said - it's also tedious and annoying, let the LLM do it. Beyond that, though, is that if you apply some curiosity and that "anyone that already knows what they are doing" level prior knowledge you can use these tools to _learn_ a great deal.
You might think your way of doing things is perfect, and the only way to do them - but I'm more of the mindset that there's a lot of ways to skins most of these cats. I'm always open to better ways to do things - patterns or approaches I know nothing about that might just be _perfect_ for what I'm trying to do. And given that I do, in general, know what I'm asking it to do, I'm able to judge whether it's approach is any good. Sometimes it's not, no big deal. Sometimes it opens my mind to something I wasn't aware of, or didn't understand or know would apply to the given scenario. Sometimes it leads me into rabbit holes of "omg, that means I could do this ... over there" and it turns into a whole ass refactor.
Claude code has broadened my capabilities, professionally, tremendously. The way it makes available "try it out and see how it works" in terms of trying multiple approaches/libraries/databases/patterns/languages and how those have many times led me to learning something new - honestly, priceless.
I can see how these tools would scare the 9-5 sit in the office and bang out boilerplate stuff, or to those who are building things that have never been done before (but even then, there's caveats, IMO, to how effective it would/could be in these cases)... but to people writing software or building things (software or otherwise) because they enjoy it or because they're financial or professional lives depend on what they're building - absolutely astonishing to me anyone who isn't embracing these tools with open arms.
With all that said. I keep the MCP servers limited to only if I need it in that session and generally if I'm needing an MCP server in an on-going basis I'm better off building a tool or custom documentation around that thing. And idk about all that agent stuff - I got lucky and held out for Claude Code, dabbled a bit with others and they're leagues behind. If I need an agent I'ma just tap on CC, for now.
Context and the ability to express what you want in a way that a human would understand is all you need. If you screw either of those up, you're gonna have a bad time.
It's astonishing to me the ease of which software developers can wreak _real_ measurable damage to billions of lives and have no real liability for it.
Software developers shouldn't call themselves engineers unless they're licensed, insured and able to be held liable for their work in the same way a building engineer is.
Example;
I'm wrapping up, right now, an updated fork of the PHP extension `phpredis` because Redis 8 recently was released with support for a new data type, Vector Set but the phpredis extension (which is far more performant that non-extension redis libraries for PHP) doesn't support the new vector-related commands. I forked the extension repo, which is in C (I'm a PHP developer, I had to install CLion for the first time just to work along with CC) and fired up claude code with the initial prompt/task of analyzing the extensions code and documenting the purpose, conventions, and anything that it (claude) felt would benefit the bootstrapping process of future sessions such that whole files wouldn't need to be read into a CLAUDE.md file.
This initially, depending on the size of the codebase, could be "expensive". Being that this is merely a PHP extension and isn't a huge codebase, I was fine letting it just rip through the whole thing however it saw fit - were this a larger codebase I'd take a more measured approach to this initial "indexing" of the codebase.
This results in a file that claude uses like we do a readme.
Next I end this session, start a new one and tell it to review that CLAUDE.md file (I specifically tell it to do this, every single new session start moving forward) and then generate a general overview/plan of what needs to be done in order to implement the new Vector Set related commands so that I can use this custom phpredis extension in my PHP environments. I indicated that I wanted to generate a suite of tests focused on ensuring each command works with all of it's various required and optional parameters and that I wanted to use docker containers for the testing rather than mess up my local dev environment.
$22 in API costs and ~6 hours spent and I have the extension, working, in my local environment with support for all of the commands I want/need to use. (there's still 5 commands that I don't intend to use that I haven't implemented)
Not only would I have certainly never embarked upon trying to extend a C PHP extension, I wouldn't have done so over the course of an evening and morning.
Another example:
Before this redis vector sets thing I used CC to build a python image and text embedding pipeline backed by Redis streams and Celery that consumes tasks pushed to the stream by my Laravel application that currently manages ~120 million unique strings and ~65 million unique images that I've been generating embeddings for. Prior to this I'd spent very little time with Python and zero with anything related to ML. Now I have a performant python service that's portable that I run from my Macbook (M2 Pro) or various GPU-having Windows machines in my home that generate the embeddings on an 'as available' basis, pushing the results back to a redis stream that my Laravel app then consumes and processes.
The results of these embeddings and the similarity-related features that they've brought to the Laravel application are honestly staggering. And while I'm sure I could have spent months stumbling through all of this on my own - I wouldn't have, I don't have that much time for side project curiosities.
Somewhat related - these similarity features have directly resulted in this side project becoming a service people now pay me to use.
On a day to do - the effectiveness is a learned skill. You really need to learn how to work with it in the same way you, as a layperson, wouldn't stroll up to a highly specialized piece of aviation technology and just infer how to use it optimally. I hate to keep parroting "skill issue" but - it's just wild to me how effective these tools are and how there's so many people who don't seem to be able to find any use.
If it's burning through cash, you're not being focused enough with it. If it's writing code that's always slightly wrong, stop it and make adjustments. Those adjustments likely/potentially need to be documented in something like I described above in a long-running document used similarly to a prompt.
From my own experience, I watch the "/settings/logs" route on anthropics website while CC is working once I know that we're getting rather heavy with the context. Once it gets into the 50-60,000 tokens range I either aim to wrap up whatever the current task is, or I understand that things are going to start getting a little wonky into the 80k+ range. It'll keep on working up into the 120-140k tokens or more - but you're likely going to end up with lots of "dumb" stuff happening. You really don't want to be here unless you're _sooooo close_ to getting done what you're trying to. When the context gets too high and you need/want to reset but you're mid task - /compact [add notes here about next steps] and it'll generate a summary that will then be used to bootstrap the next session. (Don't do this more than once, really, as it starts losing a lot of context - just reset the session fully after the first /compact)
If you're constantly running into huge contexts you're not being focused enough. If you can't even work on anything without reading files with thousands of lines - either break up those files somehow or you're going to have to be _really_ specific with the initial prompt and context - which I've done lots of. Say I have a model that belongs to a 10+ year old project that is 6000 lines long and I want to work on a specific method in that model - I'll just tell claude in the initial message/prompt which line that method starts on, ends on and what number of lines from the start of the model it should read (so it can get the namespace, class name, properties, etc) and then let it do it's thing. I'll tell it specifically not to read more than 50 lines of that file at a time when looking for something or reviewing something, or even to stop and ask me to locate a method/usages of things, etc rather than reading whole files into context.
So, again, if it's burning through money - focus your efforts. If you think you can just fire it up and give it a generic task - you're going to burn money and get either complete junk, or something that might technically work but is hideous, at least to you. But, if you're disciplined and try to set or create boundaries and systems that it can adhere to - it does, for the most part.
As someone who works primarily within the Laravel stack, in PHP, the LLM's are wildly effective. That's not to say there aren't warts - but my productivity has skyrocketed.
But it's become clear that when you venture into the weeds of things that aren't very mainstream you're going to get wildly more hallucinations and solutions that are puzzling.
Another observation is that I believe that when you start getting outside of your expertise you're likely going to have a correlating amount of 'waste' time spent where the LLM is spitting out solutions that an expert in the domain would immediately recognize as problematic but the non-expert will see and likely reason that it seems reasonable/or, worse, not even look at the solution and just try to use it.
100% of the time that I've tried to get Claude/Gemini/ChatGPT to "one shot" a whole feature or refactor it's been a waste of time and tokens. But when I've spent even a minimal amount of energy to focus it in on the task, curate the context and then approach? Tremendously effective most times. But this also requires me to do enough mental work that I probably have an idea of how it should work out which primes my capability to parse the proposed solutions/code and pick up the pieces. Another good flow is to just prompt the LLM (in this case, Claude Code, or something with MCP/filesystem access) with the feature/refactor/request asking it to draw up the initial plan of implementation to feed to itself. Then iterate on that as needed before starting up a new session/context with that plan and hitting it one item at a time, while keeping a running {TASK_NAME}_WORKBOOK.md (that you task the llm to keep up to date with the relevant details) and starting a new session/context for each task/item on the plan, using the workbook to get the new sessions up to speed.
Also, this is just a hunch, but I'm generally a nocturnal creature and tend to be working in the evening into early mornings. Once 8am PST rolls around I really feel like Claude (in particular) just turns into mush. Responses get slower but it seems it loses context where it otherwise wouldn't start getting off topic/having to re-read files it should already have in context. (Note; I'm pretty diligent about refreshing/working with the context and something happens in the 'work' hours to make it terrible)
I'd imagine we're going to end up with language specific llms (though I have no idea, just seems logical to me) that a 'main' model pushes tasks/tool usage to. We don't need our "coding" LLM's to also be proficient on oceanic tidal patterns and 1800's boxing history. Those are all parameters that could have been better spent on the code.
Is it a tool problem or a skill problem when a surgeon doesn't know how to use a robotic surgery assistant/robot?
It's almost always the users fault when it comes to tools. If you're using it and it's not doing its 'job' well - it's more likely that you're using it wrong than it is that it's a bad tool. Almost universally.
Right tool for the job, etc etc. Also important that you're using it right, for the right job.
Claude Code isn't meant to refactor entire projects. If you're trying to load up 100k token "whole projects" into it - you're using it wrong. Just a fact. That's not what this tool is designed to do. Sure.. maybe it "works" or gets close enough to make people think that is what it's designed for, but it's not.
Detailed, specific work... it excels, so wildly, that it's astonishing to me that these takes exist.
In saying all of that, there _are_ times I dump huge amounts of context into it (Claude, projects, not Claude Code - cause that's not what it's designed for) and I don't have "conversations" with it in that manner. I load it up with a bunch of context, ask my question/give it a task and that first response is all you need. If it doesn't solve your concern, it should shine enough light that you now know how you want to address it in a more granular fashion.
Sure, it might cost a few dollars here and there. But what I've personally been getting from it, for that cost, is so far away from "expensive" it's laughable.
Not only does it do things I don't want to do, in a _super_ efficient manner. It does things I don't know how to do - contextually, within my own project, such that when it's done I _do_ know how to do it.
Like others have said - if you're exhausting the context window, the problem is you, not the tool.
Example, I have a project where I've been particularly lazy and there's a handful of models that are _huge_. I know better than to have Claude read those models into context - that would be stupid. Rather - I tell it specifically what I want to do within those models, give it specific method names and tell it not to read the whole file, rather search for and read the area around the method definition.
If you _do_ need it to work with very large files - they probably shouldn't be that large and you're likely better off refactoring those files (with Claude, of course) to abstract out where you can and reduce the line count. Or, if anything, literally just temporarily remove a bunch of code from the huge files that isn't relevant to the task so that when it reads it it doesn't have to pull all of that into context. (ie: Copy/paste the file into a backup location, delete a bunch of unrelated stuff in the working file, do your work with claude then 'merge' the changes to the backup file and copy it back)
If a few dollars here and there for getting tasks done is "too expensive" you're using it wrong. The amount of time I'm saving for those dollars is worth many times the cost and the number of times that I've gotten unsatisfactory results from that spending has been less than 5.
I see the same replies to these same complaints everywhere - people complaining about how it's too expensive or becomes useless with a full context. Those replies all state the same thing - if you're filling the context, you've already screwed it up. (And also, that's why it's so expensive)
I'll agree with sibling commenters - have claude build documentation within the project as you go. Try to keep tasks silo'd - get in, get the thing done, document it and get out. Start a new task. (This is dependent on context - if you have to load up the context to get the task done, you're incentivized to keep going rather than dump and reload with a new task/session, thus paying the context tax again - but you also are going to get less great results... so, lesson here... minimize context.)
100% of the time that I've gotten bad results/gone in circles/gotten hallucinations was when I loaded up the context or got lazy and didn't want to start new sessions after finishing a task and just kept moving into new tasks. If I even _see_ that little indicator on the bottom right about how much context is available before auto-compact I know I'm getting less-good functionality and I need to be careful about what I even trust it's saying.
It's not going to build your entire app in a single session/context window. Cut down your tasks into smaller pieces, be concise.
It's a skill problem. Not the tool.
I'm running a Meilisearch instance on an AX52 @ Hetzner (64GB DDR5 memory / NVMe / Ryzen 7 7700) dedicated to just meilisearch
- 191,698 MB in size - 13 indexes - ~80,000,000 documents
The primarily searched indexes have 5, 6 and 10 million records each. The index with 10 million records has 4 searchable attributes, 10 filterable attributes and 7 sortable attributes.
I don't have any idea what kind of search volume there is - the search form is public, the website it's on is displaying content relative to those 5, 6 and 10 million records (each having their own page) and the AI bots are having a field day crawling the site. I don't cache the search results, nor is cloudflare caching the resulting pages since the site is dynamic and records are _constantly_ being added.
So with all that said - here's the current top output:
top - 06:33:47 up 257 days, 12:10, 1 user, load average: 1.05, 1.18, 1.24 Tasks: 274 total, 1 running, 273 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.8 us, 0.1 sy, 0.0 ni, 93.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 63439.1 total, 403.6 free, 16698.8 used, 47065.0 buff/cache MiB Swap: 32751.0 total, 2.2 free, 32748.8 used. 46740.3 avail Mem
2747823 meilise+ 20 0 24.1t 52.0g 36.2g S 94.7 84.0 5w+5d /usr/local/bin/meilisearch --config-file-path /etc/meilisearch.toml
It's bored. Searches are fast. Doesn't need as much memory as the size of the index to be so.
The only hiccups I ran into were back before they introduces the batch indexing. Things were fine in testing/development but when I started _really_ loading the documents on production it was clear it wasn't going to keep up with the indexing - but then it just _never stopped_ indexing, CPU usage very high. I jumped into their discord, connected with someone on the team who I gave access to the server and they made a few adjustments - didn't fix, but helped. Then the next update basically solved the issue with the high CPU use. I still had issues when loading a lot of documents but found a Laravel package for batch indexing Laravel Scout-based indexes and the solved things for me. Then they released the batch indexing, I stopped using the Laravel specific batch indexer and it's been smooth sailing.
I'll be testing/playing with their vector stuff here shortly, have about 10mil of 60mil generated and a new server with a bunch more memory to throw at it.
Would recommend Meilisearch.
Sure, WP isn't going away overnight. But it's dead in the water at this point. Literally like a dead whale, still going to support an ecosystem for some period of time. Though, it's peak is behind us and the unwinding was accelerated immeasurably.
1: https://www.therepository.email/wp-engine-sues-automattic-an...
I've implemented a handful of methods to detect 'networks' of these bots/spammers/karma farming accounts and, from the subreddits I'm monitoring, it's _more than half_ of the total accounts posting to them. This is across subreddits of all types, sizes and topics. Massive subs, regional subs, local subs, they're all completely inundated with these accounts - and these are the ones that make it through Reddit's own spam detection and whatever each subreddit has in place to handle moderation. These are the posts that do go public, more than half of the _accounts_ I've determined are spam/karma farming/bots. It's an even greater proportion of the _posts_ that belong to these accounts. (Thus, there are more spammers than "real" users, and they're posting more than the "real" users)
And this is with rather elementary methods of determining "spam" from "real" users/content. Those spammers who aren't being very lazy can pretty easily slide through my filters. (I'm detecting 'duplicates' of images and post titles/account descriptions using perceptual hash/simhash and hamming distance only - I'm rolling out text/image vector embedding based duplicate detection now and the numbers are even worse with this in place but I don't have it properly tuned yet) They're literally just re-posting the same content that successful/high karma accounts have previously posted en masse across as many subreddits as they can find/aren't banned from and it's wildly effective.
What's crazy to me is that many of them are in the 6 and 7 digits of karma - obviously spam accounts with > 1,000,000 karma is wild.
It seems to me that Reddit has zero interest in controlling this. Some might argue this is confirmed by the lack of moderation tools available to subreddit mods (which was ultimately the motivation of me building this system - but when they changed the API stuff I changed my goals/intention with it).
If he's not having some sort of mental health crisis it really begs to question how we got here with someone like him running those organizations for this long.
If he is, and he makes it out of this state, I feel for the emotions he's going to have to deal with when he sees (with a different perspective) what he's done to what is ultimately his life's work.
It's sad. All the way around, truly just sad.