Sure, you can't hear it from 10ft away - but how much air is it moving at that setting?

I have various configurations of these PC fan setups and the Arctic P14 Pro that you can get 5 for $32 on amazon are honestly wildly effective and designed for applications with some static pressure (radiators and such).

So we're back to; effective or quiet, you're only going to get both with the PC fans, for now.

Re: Filter costs - stock up when costco has them on sale, which seems like every few months. They've got Filtrete 2500 (merv 14) for 3 filters for ~$35 if I remember correctly. I use them in my CR boxes and those I built for family (which I give them with a 3 pack of new filters and also instruct them to refill during costco sales)

I built one for a local stray cat rescue where it literally sits in the middle of the living space for 10+ cats, it's 4 months now since they started using it and the filters look quite dirty but the air flow is surprisingly still very good. (4x Noctua NF-F12 iPPC 3000 fans and 4x 16"x25"x1" Filtrete 2500 filters)

Here's some info re: which merv levels work best with various fan combinations (looks like if you're going to go with higher merv you'll need the static pressure to be able to continue to pull through them with any reasonable airflow once they're getting loaded up with stuff) - https://www.cleanairkits.com/blogs/news/what-happens-to-cadr...

My plan is something similar to this feed the cats thing - except, a twitch live stream of an fpv water turret in which they can "deter" those unwanted visitors.

```

Something that seems to have been a consistent gotcha when working with llm's on this project is that there's no specific `placement` column on the table that holds the 'results' data. Our race_class_section_results table has it's rows created in placement order - so it's inferred via the order relative to other records in the same race_class_section. But this seems to complicate things quite a bit at times when we have a specific record/entry and want to know it's placement - we have to query the rest of them and/or include joins and other complications if we want to filter results by the placements, etc.

  Can you take a look at how this is handled, both with the querying of existing data by views/livewire components/etc and how we're storing/creating the records via the import processes and give me a
   determination on whether you think it should be refactored to include a column on the database for `placement`? I think right now we've got 140,000 or so records on that table and it's got nearly
  20 years worth of race records so I don't think we need to be too concerned with the performance of the table or added storage or anything. Think very hard, understand that this would be a rather
  major refactor of the codebase (I assume, since it's likely used/referenced in _many_ places - thankfully though that most of the complicated queries it would be found in would be easily identified
  by just doing a search of the codebase for the race_class_section_results table) and determine if that would be worth it for the ease of use/query simplification moving forward.

This comes with a rather developed CLAUDE.md that includes references to other .md documents that outline various important aspects of the application that should be brought into context when working in those areas.

This prompt was made in planning mode - the LLM will then dig into the code/application to understand things and, if needed, ask questions and give options to weigh before return with a 'plan' on how to approach. I then iterate on that plan with it before eventually accepting a plan that it will then begin work on.

See below about context.

> I mean in the movies for example, advanced AI assistants do amazing things with very little prompting. Seems like that's what people want.

Movies != real life

> To me, the fact that so many people basically say "you are prompting it wrong" is knock against the tech and the model. If people want to say that these systems are so smart at what they can do, then they should strive to get better at understanding the user without needing tons of prompts.

See below about context.

> Do you think his short prompt would be sufficient for a senior developer? If it's good enough for a human it should be good enough for a LLM IMO.

Context is king.

> I don't want to take away the ability to use tons of prompting to get the LLM to do exactly what you want, but I think that the ability for an LLM to do better with less prompting is actually a good thing and useful metric.

What I'm understanding from your comments here are that you should just be able to give it broad statements and it should interpret that into functional results. Sure - that works incredibly well, if you provide the relevant context and the model is able to understand and properly associate it where needed.

But you're comparing the LLMs to humans (this is a problem, but not likely to stop so we might as well address it) - but _what_ humans? You ask if that prompt would be sufficient for a senior developer - absolutely, if that developer already has the _context_ of the project/task/features/etc. They can _infer_ what's not specified. But if you give that same prompt to a jr dev who maybe has access to the codebase and has poked around inside the working application once or twice but no real in depth experience with it - they're going to _infer_ different things. They might do great, they might fail spectacularly. Flip a coin.

So - with that prompt in the top level comment - if that LLM is provided excellent context (via AGENTS.md/attached files/etc) then it'll do great with that prompt, most likely. Especially if you aren't looking for specifics in the resulting feature outside of what you mentioned since it _will_ have to infer some things. But if you're just opening codex/CC without a good CLAUDE.md/AGENTS.md and feeding it a prompt like that you have to expect quite a bit of variance to what you get - exactly the same way you would a _human_ developer.

You context and prompt are the project spec. You get out what you put in.

Valid as well. I guess I'm just nitpicking based on how much I see people saying these models aren't useful combined with seeing this example, triggered my "you're doing it wrong" mode :D

> GPT-5-Codex allows me to write a pretty quick & dirty prompt, yet still get VERY good results.

I have a reputation with family and co-workers of being quite verbose - this might be why I prefer Claude (though haven't tried Codex in the last month or so). I'm typically setting up context and spending a few minutes writing an initial prompt and iterating/adjusting on the approach in planning mode so that I _can_ just walk away (or tab out) and let it do it's thing knowing that I've already reviewed it's approach and have a reasonable amount of confidence that it's taking an approach that seems logical.

I should start playing with codex again on some new projects I have in mind where I have an initial planning document with my notes on what I want it to do but nothing super specific - just to see what it can "one shot".

And I left that window at 5-20x because, again, no real context. But unless I was already in the middle of a task and I was giving direction that there was already context for - my prompt is generally almost never _this_ short. (referring to the prompt in the top level comment)

> A 20x longer prompt doesn't sound like a satisfying solution to whatever issue is happening here.

It wouldn't be, given the additional context given by the author in a sibling comment to yours. But if you had specific expectations on the resulting code/functionality that 20x longer prompt is likely to save you time and energy in the back and forth adjustments you might have to make otherwise.