garfij

* Does the series of commits tell a cohesive story of the feature, each commit building on the last one? It's surprisingly easy to have an ordering of commits where each one builds, but the ordering is nonsense. * Is each commit scoped to the right size? Not too big of course, describes a single idea or concept. That same rule can also lead to commits that are comically small or separates two changes that can obviously be argued are "two different things" but that make more sense when seen together as a single conceptual change. * When is it appropriate to split up disparate changes within a single file, interwoven together, and how to correctly orchestrate that with git commands.

I care _deeply_ about commit hygiene and presentation because it's a foundation for making code review a smooth process and in the Before Times™ I would spend a _substantial_ amount of time reworking my own commits to ensure they were up to my own standards. I can count on two hands the number of commits I've authored on my own in the last year, and the process is immediately replicated and standardized across our entire engineering organization.

It is perfect 100% of the time? No, every once in a while I'll hit some weird case and need to issue some corrective instructions, or more likely ask the model why things are like that to see if there's tuning we need to do.

Commits are effectively like automated code-formatting now. This isn't years in the future, this is already _old news_.

Of course it's a stupid amount of money sometimes, but I generally feel like we get what we're paying for.

  - Circuit breakers when it seem like it's stuck in a loop
  - Warnings about running low on context
  - Reminders about task lists (or anything)
  - All sorts of warnings about whatever

Dynamic, on-the-fly generation & execution is definitely fascinating to watch in a sandbox, but is far to scary (from a compliance/security/sanity perspective) without spending a lot more time on guardrails.

We do however take note of hallucinated tool calls and have had it suggest an implementation we start with and have several such tools in production now.

It's also useful to spin up any completed agents and interrogate them about what tools they might have found useful during execution (or really any number of other post-process questionnaire you can think of).

Let alone that dynamically modifying the base system prompt would likely break their entire caching mechanism given that caching is based on longest prefix, and I can't imagine that the model's system prompt is somehow excluded from this.

After any back and forth session I have reasonably good results asking something like "Given this workflow, how could I have prompted this better from the start to get the same results?"

  aria-hidden=true

For anyone else looking to do this, the trick is to choose "Other" instead of "Too expensive" or "My rate is going up" as the reason for cancelling. The later will just result in them trying to sell other standard subscription offers to you.

I've been coding professionally for 20 years and at every job I've ever had we've made the decision to move away from ORMs or as much as possible given the constraints of our system in preference of directly writing SQL. My previous employer dumped Rail in favor of a Go backend (a language whose userbase almost entirely eschews the idea of ORMs) and my current employer never even had one to start with, choose to write SQL directly in a typescript backend.

I'm not going to pull the stats for you but this very website is FULL of articles talking about the benefits of writing your own SQL and I can't even remember the last time someone tried to pitch me a shiny new ORM.

> teaching people arcane terminology distinctions like between WHERE and HAVING

This is akin to complaining about needing to teach people arcane terminology distinctions between FOR and WHILE. I think it's a crime that many CS degrees I see don't include a course in database and SQL. There are of course some arcade corners of SQL (I sometimes have to look up the different JSONB operators in postgres), but WHERE and HAVING ain't it.

> flipping a coin on whether the query engine will use the index and execute in 10 ms, or decide to follow a different execution plan and take 5 minutes to run

Heavens, if you think using an ORM is going to help you here, have you got another think coming.

Your take on this is so foreign to me I was honestly shocked to see it. That being said, you probably aren't the only one, so perhaps my perspective is more narrow than I had assumed as well.

Conversely it is unethical to retain the rights to shared cultural artifacts and _not_ provide a way for people to access them.

I'm papering over some grey area where if it's not available for purchase but you could get it from the library, maybe via inter-library loan, then maybe in aggregate it's better ethically to do that.

My gut reaction is that I don't agree with you, but I can't immediately put into words why. I think it's possibly that I view a "console" for gaming as a combination of a form factor and development environment and this seems to fit that bill.

I'm interested to hear the other side though.

https://www.afandpa.org/news/2021/lets-set-record-straight-p... https://www.sierraclub.org/sierra/yes-you-can-recycle-your-p...