neilkakkar

I see what you mean - I have a setup-worktree script that does this, but I use the skill for knowing when to do bits and pieces. I would agree, if it were 100% deterministic script is much better.

I think you'd like this post I wrote: https://neilkakkar.com/agentic-debt.html , parts of why I think we wouldn't get automated away just yet. It might be true eventually - and when it does happen, I'm sure I'll find something else to do, most probably up the stack. Managing for now seems like a terrible task for agents. I need to guide them to the right solution.

_Parts_ of what I write are drudgery, which gets automated away. The "why" we talk about in sync, so it's much less of an issue in general.

When I say management, I mean more like a staff engineer or a tech lead, rather than a traditional manager.

This is exactly why I use a custom skill - I can tell it what to focus on, I can give it a ill formatted blurb of why I'm making the changes, and it will format it nicely, and add more context based on the changes.

Most of the time, the PR descriptions it generates for me are great.

I think the issue is you're assuming it's always a poor output, which isn't the case. I'm in a much smaller team than you'd expect, so the why is talked about sync more often than not, and it becomes less of an problem.

OP here, I disagree, it's great to have a skill for cases where you have extra steps and want the agent to run some verification steps before making a PR. It's called making a PR, but it's not _just_ running the gh cli to make a PR.

It's checking if I'm in a worktree, renames branches accordingly, adds a linear ticket if provided, generates a proper PR summary.

I'm not optimising for how fast the PR is created, I want it to do the menial steps I used to do .

Hello! OP here, a lot of comments have this common theme of wondering if this is overloading / context switching / the brain thrashing.

Helped me surface an important distinction on why it doesn't really happen for me. I think there's three parts to it:

1. I work on only one thing at a time, and try to keep chunks meaty

2. I make sure my agents can run a lot longer so every meaty chunk gets the time it deserves, and I'm not babysitting every change in parallel, that would be horrible! (how I do this is what this post focuses on)

3. New small items that keep coming up / bug fixes get their own thread in the middle of the flow when they do come up, so I can fire and forget, come back to it when I have time. This works better for me because I'm not also thinking about these X other bugs that are pending, and I can focus on what I'm currently doing.

What I had to figure out was how to adapt this workflow to my strengths (I love reviewing code and working on one thing at a time, but also get distracted easily). For my trade-offs, it was ideal to offload context to agents whenever a new thing pops up, so I continue focusing on my main task.

The # of PRs might look huge (and they are to me), but I'm focusing on one big chonky thing a day, the others are smaller things, which together mean progress on my product is much faster than it otherwise would be.

Interesting, I feel humans are a lot more likely to consolidate because it's easier to reason / maintain when there's one component vs two.

Agree that it's _possible_ people don't do it, and things end up in a decaying codebase. But in my experience people tend to leave things better than they found them (or that's the culture I like to promote, at least when dealing with humans)

I'm very confused, why is this so upvoted, someone mind explaining?

Asking because I see something that's a lot of mappings with zero context: Why/ for what is the Lambda-Cube useful?

Broadly: I agree Alex, that was my bad.

Minutely: The fact that I couldn't game it means it isn't that vulnerable.

Noted, I was starting to submit way too much as a part of an experiment. That experiment failed miserably (and led to a shitlist addition).

I don't submit things more than 4x now. What you see are the remnants of the experiment.

At the same time, I don't think things make it to the front-page if they're bad.

Partially, yes! - And partially about priorities.

So, you're doing whatever sequence is better. It's a general case of the example you mention:

With one permutation (yours), you can get everything done. With another permutation (relax first, meeting prep later) - you might be leaving the prep for the last minute.

There's some cases when the first permutation is better - when you have enough energy, say, and the meeting is important.

There's other cases when the second permutation is better - when, say, you're already low on energy and the meeting isn't that important - so you're prioritising relaxing.

There's more examples on the linked page[0]

An example of neither delayed gratification, nor priorities:

Permutation 1: Accusing someone of spewing non-sense, then understanding what they really meant.

Permutation 2: Understanding what they really meant, and then, if necessary, accusing them of spewing nonsense.

Permutation 2 as a habit leads to better outcomes. Mostly.

[0]: https://neilkakkar.com/sequencing-things-in-the-right-order....

Aside, but on similar lines:

I have to keep reminding myself that everyone isn't like me.

In my private talks with myself, I refer to this skill as modelling other people well: in effect, I'm trying to build models for different kinds of people.

There's lots of different kinds, and a few broad types show up, explaining most of their (general / broad) actions.

This is still very much a work in progress for myself too, but would be very interesting to see if I get somewhere substantial.

I started with EverNote, but I really like Roam's daily pages now. It powers my Human Log well.[0]

[0]: https://neilkakkar.com/the-human-log.html

Ekk! Thanks for pointing this out - I was hacking around a script to do some distribution analysis, didn't realise the shitlist was a thing.

Do you know what's the general limit per day/week/month?

(and ofcourse I'll stop now :)

Thank you, darkerside!

One meta-goal of the post was to figure out how I can grow further. Are there things on top of your mind which I should be exploring next?

I was a bit worried about the title saying "Senior Software Engineer" because this may trigger people.

But, surprised that all the discussions are about this, instead of the content.

Can someone explain how the title fits the article? I was .. pretty pissed once I reached the end (almost all of it interesting) to find it's not related to the title at all.

Possibly leads to teams backing up pages and "recreating" the same ones again.

Would love to hear if anyone actually tried this

Author here. I agree with some of your concerns.

From the post:

> The mind doesn’t always work like Bayes Theorem prescribes. There’s lots of things Bayes can’t explain. Don’t try to fit everything you see into Bayes rule. But wherever beliefs are concerned, it’s a good model to use. Find the best beliefs and calibrate them!

The one concern I'm really interested by, and don't understand, is this:

> There are thus lots of reasons to believe that we do not think and should not think in a Bayesian way.

Can you give an example that can serve as motivation to read the entire paper linked?

Ah, yes indeed! Thank you.

I really enjoyed this explanation of Simpson's Paradox: http://michaelnielsen.org/reinventing_explanation/

Fair point, the beginning section does seem to suggest that. I have a note in the middle explaining this is not the case.

I make the connection to demonstrate that Bayes is not some arcane statistical artifact, but qualitatively in line with intuition, albeit miscalibrated. This opens up avenues to then move towards ideal bayesian-ness.

Haha, this is amazing! I'd use it in the post, but I fear it's a strawman of the Frequentist side.

> In real life usually we have no idea about priors

Priors are your previous knowledge on the topic.

> One textbook example of Bayes theorem is how doctors overestimate the probability of being positive for a disease. But what are the priors?

In this example, doctors overestimate precisely because they don't take the priors into account.

Doing something risky the day before / feeling funny is extra evidence that is assimilated (or should be) into the likelihood ratio P(D|H) / P(D). This is information the patient should share with the doctor.

Of course, if they don't, then the Bayes estimate is the best guess given all the information the doctor has.

Edit: Your criticism about how we choose priors is fair. The better you are at this, the more accurate your answers become. I mention more about this in the "putting it to practice" section.

An old discussion on this article: https://news.ycombinator.com/item?id=20795526

I enjoyed reading this, thanks!

.. I don't think you're disagreeing with me at all.

I agree with this: "You don't need to know what this is in order to know it exists. Having a word for it helps tremendously, but it is not required in order to reason about it."

Cheers :)

For the first one: Have you heard of the Piraha Tribe and their counting system?

http://web.archive.org/web/20040825185826/http://paulgraham....

Thanks!

I think there's a lot of person matching involved here. Hard to find a one-fits-all guide.

Luckily, there's lots of people publishing on the internet.

But how do you search through them? I don't know. That's something text based search hasn't solved yet.

Same for fiction. I used to read a lot as a kid, but it tapered off as I switched to non-fiction. 5 years later, I'm now coming back to it.

There's something about fiction that makes things click - it's the story standing in for experience :)

Hey Nathan, sorry you feel that way.

The third paragraph has a footnote stating that the 3 para above were "heavily inspired" by the "Eat Dirt" chapter. I'm assuming you didn't see this first footnote.

And a bit later, I do link to the manual as well (which is what you saw, I guess)

Not my intention to copy Duncan's work. A big red disclaimer hurts readability, and not attributing the source would indeed be plagiarism. I think I struck the right balance.

I use that example because I love how it shows the concept I was trying to explain pretty well. It's not the main point of the post.