JohnBooty
Even if the absolute number of chargebacks is small, in relative terms it’s still several times larger than it is for non-“adult” charges, and that kinda destroys profit margins — more support calls, more work, etc.
Or so they say.
I’m not in the industry, so I don’t know. I can certainly believe that many of the oligarchs in charge are weird shitheads with bizarro conservative views, but payment processor leadership doesn’t seem to give a fuck about morals in any other manner, so it’s also kind of weird to me that they’d pick porn and porn only (a seemingly passé target for most conservatives these days) as the one and only target of a uh, decades-long distributed lowkey conspiracy that spans multiple generations of payment processor leadership. ¯\_(ツ)_/¯
> It’s invisible, insidious censorship
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)
For most circumstances where someone would use
a white noise machine, this kind of small purifier
is all-around better.
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...
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!
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!
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.
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.
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.
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.
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)
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.
I eagerly await your misunderstanding!
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
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.
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?
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.
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.
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?
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...
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.
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.
You don’t need documentation […or…] memory
The code IS the documentation
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….
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.
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
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 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.