half the time you’re going to discover the right decision / path while you’re coding.

focus time went from hammering code to figuring out how to solve the problem. PRs are now how we exchange ideas. meetings are still productivity theater.

I think that’s untrue, I think it’s /more/ important than before. I think you’re going to have significantly more leverage with these tools if you’re capable of thinking.

If you’re not, you’re just going to produce garbage extremely fast.

The use of these tools does not preclude you from being the potter at the clay wheel.

People talk about writing the code itself and being intimate with it and knowing how every nook and cranny works. This is gone. It’s more akin to on call where you’re trudging over code and understanding it as you go.

Good code is easy to understand in this scenario; you get a clear view of intent, and the right details are hidden from you to keep from overwhelming you with detail.

We’re going to spend a lot more time reading code than before, better make it a very good experience.

I havent run into this type yet, thankfully. As an AI lover, the architecture of the code is more important than before.

* It’s harder to understand code you didn’t write line by line, readability is more important than it was before.

* Code is being produced faster and with lower bars; code collapsing under its own shitty weight becomes more of a problem than it was before.

* Tests/compiler feedback helps AI self correct its code without you having to intervene; this is, again, more important than it was before.

All the problems I liked thinking about before AI are how I spend my time. Do I remember specific ActiveRecord syntax anymore? No. But that was always a Google search away. Do I care about what those ORM calls actually generate SQL wise and do with the planner? Yes, and in fact it’s easier to get at that information now.

I was running some sentiment analysis experiments; describe the subject and the subjects emotional state kind of thing. It picked up on a lot of little detail; the brand name of my guitar amplifier in the background, what my t shirt said and that I must enjoy craft beer and or running (it was a craft beer 5k kind of thing), and picked up on my movement through multiple frames. This was a video slicing a frame every 500ms, it noticed me flexing, giving the finger, appearing happy, angry, etc. I was really surprised how much it picked up on, and how well it connected those dots together.

I don’t use Claude code for everything. I’ve fallen off the bike enough times to know when I’ll be better off writing the changes myself. Even in these cases, though, I still plan with Claude, rubber duck, have it review, have it brainstorm ideas (“I need to do x, I’m thinking about doing it such and such way, can you brainstorm a few more options?”)

In my experience these one off reports are very brittle. The app ends up making schema changes that are breaking to these one off reports, and you usually don’t find out until it goes to production.

I’ve dealt with the maintenance nightmare before. At current gig we’re exploring solutions, curious what a robust pipeline looks like in 2025.

The ORM piece is interesting — we use ActiveRecord and Ruby, and accidentally breaking schema changes within app will get caught by the unit test suite. I would love for a way to bring OLAP reports in similarly to test at CI time.

Are you implying that Biden spoke with more confidence than Trump, but Harris did not?

But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more.

Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms.

Still love Ruby but the process model gave me a reason to hate N+1s.

Many times I’ve confidently thought I understood a problem, started writing about it, and come away with new critical questions. These things are typically more visible from the abstract, or might not become apparent in the first few release milestones of work.

I’m reminded of a mentor in my career, who had designed an active/active setup retroactively for a payment gateway. He pulls up a Lucidchart and says “this diagram represents 6 months of my life”.

They’re not always necessary or helpful. But when they are you can save weeks of coding with a few days of planning.

I’m not sold on the importance of static typing though. I’ve had great results with Ruby and Python with 4o, o1, and to a limited degree Copilot.

One of the biggest benefits of Ruby is how simple testing is. The language is so dynamic that mocking/stubbing and intercepting or whatever is dead simple stupid.

So the “static types prevent you using LLM hallucinations” does not hold for me. I’m going to write tests covering the method (which the LLM will probably help with), and I’m going to get an undefined method error.

> We're active, we eat well

Respectfully, you are both obese. If you’re ok with that that’s ok; but to say your diets are appropriate is telling yourself a lie.

Tests are great for:

* High risk items (large consequence when it goes wrong)

* Documentation

* Weird unintuitive things

We had a C# project recently that needs to detect changes between a DTOs properties. At implementation, all the comparisons would be done over value types, but if someone added a reference type that didn't properly implement equality this would silently fail (likely for months). Good case for adding a test that ensures the change detection works for all properties.

Completing a big project, setting a new weight lifting or running PR only leaves me feeling empty. I've come to realize fulfillment, for me at least, is in the journey; accomplishment is merely a memento.