moxza

The thing I find most encouraging is that the best AI detector is still humans. Don't write the Turing test off yet.

From what I understand, your approach is clever, it's like an accent detector. Known models tend toward a specific median approach. Humans have a much richer degree of randomness. Riffing on Anna Karenina... All models are alike in that they present predictable patterns. Humans inevitably write in unique ways.

I gave a lot of thought to the idea that humans will devolve to the median led by volume of AI interactions, but in the end, I think we're still interacting with each other when not at work/on machines, and the fact that we even have a genetic heritage is always going to differentiate us.

Audio first is an interesting idea. As a fluent speaker who's always felt ashamed of his poor writing skills that's actually something that I would want as well.

As for building a learning flywheel. I had a working prototype pre-AI Python project in notebook format that set the foundation for how I thought Kanji learning (or any complex interrelated domain) should build on SRS.

My premise is we should learn by associating what you know with what you should know, based on frequency across the language, not some arbitrary deck… And you shouldn't have to waste effort self reporting, the app should give you similar options to guess from, then if you're wrong, you're wrong.

Do you think that would help you?

I feel like AI is set to surpass us on most left brain tasks, yes. I know left/right is a myth, please forgive me the shorthand. I see it in my own work where the AI is incapable of brute forcing a solution because it can't do the fuzzy wet pattern matching we do. The kinds of problems I can't solve in front of the keyboard either, but that come to me when I step away and take a walk.

Cal Newport talks about this in Deep Work. My key takeaway, not all jobs let you. As romantic as the CEO role is, they don't get to spend big blocks of time alone with their thoughts. They have to be on deck and directing whenever, wherever the flow of the business demands.

I feel like commanding a fleet of AI agents forces you into that kind of role. They get things done, but if you're not constantly checking up on them, the work isn't what it needs to be. Worse, it can turn out to be a big pile of tech debt.

I don't know what the answer is yet, it's both hard to keep up and work on my own terms. It's partly my own fault, I have a stack of PRs to review, merge and UAT. That's the deepwork stream now, but it's so tempting to just kick off another agent and have it flesh out something else from the backlog.

Hard no, but for context, I discuss books with AI all the time. I wouldn't discuss Hemingway with an AI, completely pointless. His work is not about the content, it's about the beauty of the prose. By comparison, The Timeless Way of Building, I have ruminated on and used AI to explore. It wouldn't make me want to interact with a synthetic version of Christopher Alexander.

That's not to say the backstory of an author isn't something I would go for either. The Undoing Project was the perfect bookend to Kahneman's work.

For the public facing consumer functionality I have Gemini Flash running on guardrails directed by a state machine that calls it statelessly everytime. For that, it's strictly locked to a version. I can't afford to suddenly get responses that the SM is not tuned for.

As for which model does the building... I'm not at all attached. Enough logic, and CI gates/tests live outside the whims of the LLM to be able to hotswap them any time.

I wrote my own ORM for exactly this reason. It's far from enterprise grade but it solves for 1) the domain model needs to stay clean and properly normalised and 2) that's not a job that can be distributed across the whole team.

One lesson I've carried for years is that most of the time the client needs denormalised views on the data model. That's the boundary; the server has the clean domain model, and the client works with views on that model. Isn't that exactly what an ORM is for?

I built mine in Dart because I want the server and client to share DTOs. Then I built a visualizer for clientside devs to be able to explore entity relationships (DDD style) and generate a JSON contract. The end result is no REST back and forth, no GraphQL complexity, just everyone in the team focusing on what they're good at.

I think the theme that ORMs are easy to start, but you pay for it with the edge cases, so good devs end up back at SQL does not apply when you're thinking about how to build a platform. Everyone has their strengths and weaknesses. Aligning the team on playing to their strengths was my goal when I reached for yet another ORM as the solution.