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 .
I have a cli script(wtq) that takes whatever is in my clipboard, creates a new worktree, cds into that worktree, installs dependencies, and then starts a claude session with the query in my clipboard. Once im done i can rune `wtf` and it it does the finish up work you described.
It’s not about the workflow. A skill doesn’t make sense when you have a deterministic describable workflow, it’s just slower, because you have an interpretation and consuming step in there.
You can just tell claude to turn the skill into a bash script and then alias it to whatever you like.
A skill is useful if you have a variety of use cases that need to be interepretated and need a lot of the same utility.
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.
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)
It's a fascinating bit of information that demands minimal time to absorb and comprehend. It's a refreshing break from the usual content seen here while still being intellectually stimulating.
English can do reasonably well if you don't mind poetic sounding language (and, to be fair, Shakespeare compressed down a lot of things into shorter, poetic idioms we use today). Something like her farewells overran, perhaps.
I am not sure why I upvoted this. Perhaps because I have dealt with C, C++, Java, JavaScript and some Python. I know a smattering of French, German, Dutch, Japanese and Czech. So perhaps that too. Or perhaps because of the Sapir–Whorf hypothesis.
Aside from anything else, human language and its comprehension is an important aspect of AI, and the sheer variety among grammars is a salient feature that cannot be ignored.
I think it's useful mostly as a sort of Linnæan classification device—it's a lot easier to compare different type systems by placing them on a 'standard' cube, than by choosing ad hoc points of comparison.
Type theories are formal logic languages. People use formal logic for all sorts of things but mathematics has the longest history. This is where people first defined formal languages and assigned meaning (mathematical meaning.)
Starting from simply typed lambda calculus ("simple type theory", also "higher order logic"), one can make various extensions that make the logic language more expressive. The lambda cube is a way to systematically organize the space of type theories.
Interestingly, the theory has become very relevant for type systems of normal programming languages. Milner invented ML as "meta language" for helping with logic and theorem proving, but it was used widely and today everyone expects generics to work more or less as in System F polymorphic lambda calculus.
This is why people think these concepts aren’t useful, because this was a lot of words without any practical example of what it would be used for.
Here’s a practical example: there are type systems in the lambda cube that allow us to statically check that a list has a certain length. That means a compiler can prevent an out of bounds access error, without human intervention. I have written code that crashes because of an out of bounds access, so the idea is interesting to me.
> The lambda cube is a way to systematically organize the space of type theories.
All of this was already meaningful before the lambda cube. The cube just organizes what we knew in a systematic way. It shows the relationships between the various systems that exist when they are differentiated on the features that describe their expressive power.
Not cool. It sets a bad precedent for the community by trying to game the (unwritten) rules. In equilibrium, HN is drowned by blogspam and people leave HN.
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.
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.
_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.