JohnBooty

I have seen models designed this way! Vornado used to make one, I think it's discontinued.

These directed-air "personal models" make a lot of sense to me... at least in theory. I haven't seen them properly tested.

The big air purifiers work great.. if the room is closed up. But their effectiveness approaches zero if you have the windows open or otherwise have unfiltered air entering the room. Which is kind of important, if you don't enjoy breathing in sky high levels of CO2. (If one's allergies are bad enough, or a wildfire is raging outside, CO2 might of course be preferable to particulates)

I have 4 Coway and 2 Winix purifiers and I can confirm: they're great sleep noise generators! The plastic front pieces and the filters themselves block/baffle any high frequency noise from the fans, leaving you with a pleasant low/mid frequency whooooooosh. I like it better than the sound from small cheap solid state machines; their small speakers can't do low frequencies.

    For most circumstances where someone would use 
    a white noise machine, this kind of small purifier 
    is all-around better. 

Hmm. The word "most" is doing a lot of work here.

Depends if you enjoy fresh air when you sleep or not. If you've ever monitored CO2 levels you know how quickly they climb in a closed room.

But, if you are blowing fresh air into a room, or have the windows open, the filtration effectiveness of these units approaches zero pretty rapidly. And these air purifiers aren't exactly free to run: they use ~50-100W of power and if you run them 24/7 you can expect to spend $100+ per year on filters.

So there's no perfect answer...

I smile whenever I see EBCDIC, probably because I never had to deal with it.

But I'm sorta old and some of my school's texts were outdated so they had programming examples and explanatory text that treated EBCDIC on equal footing with ASCII.

So unlike anybody who dealt with EBCDIC conversions in the wild, seeing that acronym actually takes me back to happier days!

It's a shame, because there is money in it. It's just (like most sensible preventative maintenance) that the financial benefits are typically delayed. And when it comes to software, they're notoriously impossible to quantify.

Generally the only way to get it done in a corpo environment (and receive any kind of thanks or glory, as opposed to just torpedoing your own career) is to let things get so bad that production stability suffers and/or the team's ability to ship features is severely impacted.

...I realize I'm basically just echoing what you said, except more verbose. I'm venting!

Thats badass! I like doing that kind of work, but I got very jaded about it over the years, because management generally acted as if the engineers took a shit on the conference table in the middle of a Zoom call with their most important customer whenever anybody attempted to address technical debt, as opposed to delivering more more more features. Unless it was billable agency work, in which case they’d hate it even more.

With massive amounts of effort and strong communication it was usually possible to get some tech debt time, but management acted like they were doing YOU a huge favor. It was kind of a career killer, generally.

Alternatively it was possible to get this kind of work done on my own time… but that’s a marriage killer instead of a career killer.

I burned out on trying after decades.

Wow. That was hardly ever the case in my experience in ~30 years in the industry. I enjoy(ed) what you’re describing too but… how common was this for you?

In a big production codebase with lots of active customers and data, architecture changes still feel pretty difficult even with LLMs accelerating them by an order of magnitude — migrating and backfilling data and all of that. That’s more complex than pointing Claude at a repo and saying “rewrite this in Rust.”

I guess you’re right, though - what is the ROI of keeping the architecture clean? It certainly saves time and money later, but it’s unclear if it’s a net win.

(It’s of course also significant to note that the upfront work of figuring out the right architecture and keeping the code clean has also been correspondingly reduced as well. Both sides of the equation are affected…)

The industry never really figured out a way to reliably answer this question in the pre-LLM days either, so… I suspect it will continue to be hard to determine.

Like many, I became a SWE because I loved writing code. Ruby, in particular (whatever one thinks of its other strengths and weaknesses) can be very expressive and beautiful.

However, most code is corporate CRUD stuff. The world sort of runs on CRUD. But it's rarely particularly fun, or beautiful, or fulfilling. It tends to be pretty ugly because there's rarely time to make it beautiful. So I'm not losing much joy there.

Additionally, even with an agentic workflow, my team still thinks deeply about architecture issues. We believe that well structured code is better for bots and humans alike. So I am still exercising my engineering brain; I'm writing blueprints and supervising the bricklayers now instead of laying bricks.

Does that match your teams' experience at all? Sometimes I feel like folks on these threads are working in a parallel universe where the majority of coding tasks and somehow fulfilling and fun and not 99% tweaking reports, trying to implement arcane and contradictory business logic, or fighting with shitty and frustrating externalities. Maybe people found joy in those aspects. I guess there are all types of people in the world. I mean, I'm a sicko who loves writing SQL, something that most coders seem to hate.

    I've been direct with my team about it being a legitimate 
    feeling of grief and the grieving process that comes along 
    with it. It's been helpful for folks to hear that they aren't 
    alone in that feeling.

This is super great. God, I wish all leaders had half this much empathy! Good on you.

Yeah. “Just cut bullshitters out of your life” is about as unhelpful as “Don’t get sick!” when it comes to medical advice.

Like, duh yeah that’s the goal. Do that as much as possible, but a lot of your life is going to involve dealing with these people.

On a slightly deeper level, essentially nobody is 0% or 100% bullshitter. Nearly all of humanity falls into the middle. Even the most literal, level 2+ ASD folks I’ve known were, at a minimum, cagey at times.

I think that’s a great reason to get into the psychology of bullshitters, or at least get really familiar with their tactics. You are going to have a lot of situations in your life when you can’t just flip a switch and get rid of them.

Few counterpoints:

Most people, even toxic people, do have positive qualities.

At the most basic strategic level, it’s vital to recognize this so that we don’t fall for such people in the future. It’s sooooo easy to say “well so and so can’t be too toxic… I mean, they volunteer at the soup kitchen on weekends” or whatever. That’s part of how they (intentionally or unintentionally) lure you in. All very valuable for engineer-types, who may tend to be very literal in actions and their interpretations of others’ actions.

At a more nuanced strategic level, it’s good to recognize that since all people are a mix of positive and negative traits, How can we coexist with such people in cases when we can’t avoid it? It’s simplistic to say “just avoid toxic people” — it’s a good “north star” but is often impossible or impractical. e.g. it’s convenient to say “just cut toxic family members out of your life” and sometimes it’s the right call, but I’ve heard people toss that phrase around like it’s nothing and wow it’s heartbreakingly glib.

I think it’s also valuable for introspective purposes. It’s very easy to fall into the mindset of “well, I’m a good person because of X, Y, and Z” while blinding ourselves to negative ways in which we affect others.

Finally, yeah, sure — I admit it. I like a puzzle. Specifically the puzzle of figuring out if these people believe their own bullshit!

(For the record, I thought this movie was incredible, though HN’s collective “meh” on this thread was expected)

I'd be curious to hear from other older engineers who remember the RAD (rapid application development) explosion of the 90s with Visual Basic and Delphi.

There are obvious differences, but also similarities. Particularly:

    I've been doing some fractional work and I've been 
    getting more and more outreach from organisations that 
    don't have much development knowledge internally and 
    have come to understand the limitations of what they've 
    been building and want expert review.

There was a lot of this kind of work in the late 90s and early 2000s. The IT guy or Bob from accounting would cobble together some surprisingly effective Visual Basic apps that presented a huge win over whatever they were doing previously, but quickly grew unmaintainable.

Good call, thanks.

A lot of APIs we use return JSON - Github, Semaphore, Context7, Docker, etc. We're parsing JSON dozens of times per session. I think 5-6 tokens telling it to use `jq` in AGENTS.md was the right call for us.

I eagerly await your misunderstanding!

Pulled out of my ass? Excuse you?

As I optimistically hope you may be able to eventually understand with what I assume to be significant effort on your part[1], the numbers are going to be different on a case by case basis. Thus, my generalization.

This conversation is over, as you have been moving goalposts in various random directions: careening between "no directions for LLMs!" and then talking about your "minimal" AGENTS.md and markdown files, and then disagreeing with me for having minimal AGENTS.md and markdown files, in favor of your approach which involves... minimal AGENTS.md and markdown files, apparently. Luckily, it all sounds so schizo that at least nobody will take you seriously enough to follow your bad advice. It's exhausting talking to you, but surely not as exhausting as being you, so I do still have sympathy. Good luck.

---

[1] remember to hydrate, a good night's sleep helps too

Quick, non-rhetorical sanity check, since you advocate passionately for just typing the same things into every session over and over.

You know the contents of AGENTS.md/CLAUDE.md just get injected into your context window by the harness? And that it's functionally equivalent to typing the same thing into every session?

There's no difference between typing "keep dependencies out of User" at the beginning of every session, and putting that into AGENTS.md, other than wasting a bunch of time.

    Sure, maybe it misses it, then you can just tell it.

Re-doing that work after it gets things wrong is going to take roughly 1-3 orders of magnitude more tokens than including it in AGENTS.md/CLAUDE.md.

Here's a good concrete example. I've caught Claude writing python scripts to parse JSON instead of simply using `jq`. I initially attempted to correct this by adding `jq` to my allow list, but it still always reached for Python scripting first, before eventually figuring out it could use `jq`. You think that burned a few extra tokens vs. just telling it `use jq to parse JSON` in AGENTS.md?

Architecture preferences are a great example of things that we need to tell the LLMs.

We don't need to tell the LLM where the User model is. The LLM can find it.

However, IME we need to tell the LLM preferences like, "the User model should not have dependencies on other models" (you know, to avoid the God Model problem...)

To discover that preference, the LLM would (best case scenario) need to look at every model, and notice that the User model has no dependencies, but all the other models do, and infer that this is an architecture requirement. Except, some of our other leaf models might not have dependencies anyway, so it wouldn't necessarily be apparent. Or maybe it's a new project and none of the models have dependencies in which case our preference could not be deduced. Etc. All of this is token-intensive and unreliable.

(Perhaps even more ideally than placing this instruction in AGENTS.md or similar, it could be an inline comment in the User model itself. However, I have found LLMs to be very hit-or-miss when it comes to recognizing directives inside inline comments. And some architecture rules can't be easily expressed via inline comments in a particular file...)

    I think there's a balance between the tokens 
    burned up rediscovering things vs tokens being 
    used keeping docs/decisions/skills/etc.

This mystical balance isn't difficult to measure. You don't have to believe anybody; just read the darn session transcripts. It's going to take at least one (but usually multiple) turns of grepping or other exploration to rediscover a thing. How many tokens does this add to your context? Since 1 token = ~4 characters you can count characters in your text editor.

Is this less, or greater than the number of tokens it would cost to simply add that thing to AGENTS.md?

If you're burning 5000 tokens to rediscover the same thing in every session, and it would take only 500 tokens to just put the thing in your AGENTS.md, it's an easy decision. Do you understand that paying 500 tokens in every session is less than paying 5000 tokens in every session?

If you're burning 5000 tokens to rediscover the same thing in 50% of your sessions, it's probably still worth it, but now you might consider placing it into a skill so that it only gets loaded into the 50% of sessions that need it.

If you're burning 5000 tokens to rediscover the same thing in 1% of your sessions then yeah, definitely skill. (You can add it to your prompts manually too, of course, but that is functionally equivalent to adding it to a skill that is set to manual invocation only...)

    So I HEAVILY lean towards the former especially with 
    how effective I think it is these days.

How is this different from what I already said at the beginning of this conversation, where I recommended beginning with minimal (or no) skills or instructions... and then judiciously adding very lean ones based on actual observations? You claimed that this was a waste of time.

Do you not run your tests locally? Regardless of what's happening or not happening in CI/CD, I would think that most workflows involve running the tests locally. We do TDD more or less and for the browser-based tests, the LLMs need to know how to log into stuff.

I understand what you're railing against in general: engineers who make these big memory/doc systems that quickly go stale and are at best useless and at worst actively harmful. Even more insidiously, these engineers are blind to this fact because maybe some of this stuff was effective 6-12 months ago and they haven't reassessed their workflows. Now that's dogma. We really do agree on that.

However. At least in the projects I've worked on, it's trivial to read the transcripts and notice that without enough direction, there are certain things the agents will burn lots of tokens to rediscover in every session. That's absolutely not dogma.

    Why not give the instructions on where to get 
    credentials in the original prompt?

We don't push code unless it's been QA'd, and the LLMs need to know the credentials every time they do automated QA. It's very rare for me have a session in that repo where they wouldn't need that info. So it's a great candidate for AGENTS.md

Another concrete example would be codebase conventions. We prefer lean models. Cross-model concerns go into service objects. Without this direction LLMs tend to default to stuffing too much code into the models themselves, as is the de facto standard for most MVC apps and therefore this is how LLMs are trained.

Even if they could discover our large codebase's conventions flawlessly on their own in every session, this absolutely would require nontrivial work repeated in every session: quite a few turns grepping, conversing with LSPs, or whatever.

So yes... we could describe our conventions in every single session by typing it right into the prompts... right after typing the directions to find the test credentials... and the other ten or twelve things we'd be telling it every single time...

I think they're using Skynet. They seem to be claiming that part of the reason for not giving the LLM directions is because the LLM won't follow them anyway.

That must be a remarkable model. Smart enough to flawlessly discover everything on its own in every session... but also it just straight up just doesn't obey direction.

Hmmm.

Charitably, I think we must be working on much different kinds of projects.

Yeah. Basically IMO/IME the current best practice is to start the LLMs out with minimal/no skills/instructions/docs.

Notice the things they struggle with and the small problems (typically, environment issues IME) they repeatedly encounter and re-solve across multiple sessions. That is what your instructions should cover. When possible, move those instructions into skills, so they get loaded into context selectively instead of on every session. (Example: instructions for running specs, placed into a skill that only gets loaded into context when it’s time to run specs)

Again, this can be automated by the LLMs themselves: both Codex and Claude (and I’m assuming other major harnesses) know how to read their own transcripts and are good at looking for repeated friction and making concrete suggestions to reduce that friction in the future.

It takes a bit of a time investment on the user’s part, and every now and then you probably should throw it all out and start fresh so that the new batch of instructions can be appropriate for the current state of the repo and the capabilities of whatever model(s) you’re using.

In general, as LLMs get smarter, “less is more” becomes increasingly true. You’re polluting their context with dozens or hundreds of instructions, all of which the LLM tries to satisfy. However,

    You don’t need documentation […or…] memory

…oh heck no. Easy to miss at Claude and Codex’s default detail level but if you read your actual session transcripts, you are almost certain to notice the LLM solving lots and lots of the same little problems over and over again.

    The code IS the documentation

First, lots of things cannot be learned from the code.

Trivial example: LLMs struggled with QA on our app. They didn’t know how to find the seeded test accounts. They would create new ones and do it wrong, or find the seeded test accounts but not know their passwords because they were encrypted, so they’d change the passwords but not tell the other agents. Shitloads of tokens burned. It was a no-brainer to just give them the credentials in a skill that gets loaded when they do QA.

You could say that’s an environment issue, not a code issue. But as far as actual code IME at a minimum we have to tell the agents our general repo structure and architecture patterns.

The days of “you are the world’s greatest Python programmer, write good code” or whatever are over (if that style of prompting even worked in the first place) and as I said less is more. But, still….

Can you explain your train of thought here?

It seems like you’re saying “hey, you asked for a product, so you deserve for it to have a user-hostile feature”

Like hey, you asked for trains? Well, then you have no right to complain about any aspect of a train.

Yikes. I'm not the poster you're responding to, but

1. In this absolutely wild era of model progress, with frontier and near frontier models leapfrogging themselves seemingly on a weekly basis it's good to get experience with a variety of providers

2. This isn't exactly hard with OpenRouter!

3. I've had very good results having models from one provider critique plans and code written by models from another provider. Can't do that without subs to at least two providers

I can't speak for parent poster, but it's not the cuteness. It's the "putting a cute face on something that's actually a bit sinister."

Hello Kitty isn't trying to harvest anybody's data or take anybody's job. Sanio makes cute things and they hope that you will exchange money for their goods. That's the whole relationship.

(I'm not even remotely anti-AI)

I assume there's classification going on where a really basic "Hi how are you?" style request sent to a high-effort instance can be routed to a lower-level instance. This... is pretty much fine with me, assuming they do a good job of it.

I would also assume they use nebulous labels like "Medium Effort" or "High Effort" map to quantitative amounts of compute allocation... and that these amounts can be varied manually or automatically. Right?

I mean, there's a reason why they call it "High Effort" and not "Exactly 5 Minutes of GPU Time on Exactly 10 GPUs." They want to be able to move those sliders and tweak those knobs.

Ironically, my first thought was how quickly this might be able to be re-written, in a sane way, …with the help of an LLM.

I find that if you pay a lot of human-in-the-loop attention to the design phase, LLMs can produce perfectly decent stuff.

They’re also good at writing tests. Lock in the (non-broken) behavior of the old app with tests. Then use those tests to re-create the app, except with a talented engineer (you) guiding the design this time.