I don't want your skills

Sat, 25 Apr 2026 04:03:00 +0000

I often notice people advertising their custom skills as a solution to your agentic programming problems. They’ll provide you some genuinely useful advice, then cap it off by offering you skills that operationalizes their advice.

I found the failure modes and tips identified in Software Fundamentals Matter More Than Ever insightful. I never thought about having a glossary of shared vocabulary to make communication with AI agents more effective. AI agents outrunning their headlights by doing way too much autonomously provides metaphor for my common experience of having AI agents do underspecified work. Focusing on building deeper modules with a lot of functionality hiding behind a small interface, is a pattern I’ve been thinking around, but haven’t yet been able to put words to.

But following the insight with skills that will “solve” the problem for you, is the equivalent to giving a tutorial on how to implement nanoGPT and then capping it off by saying: but you can just use https://chatgpt.com¹.

Yes, it does seem helpful to have my AI agent /grill-me — asking detailed questions instead of providing corrections to plans reflecting a fundamental misunderstanding of the problem over and over again. Of course, I’d love to /improve-codebase-architecture modularizing my codebase. But running a skill won’t help you understand how it works.

These skills probably work in simpler codebases. But simpler codebases are also the best environment to understand the principles behind the skills and learn how to build them yourself. And without understanding the principles, you won’t necessarily understand that or how the skill failed in a more complex codebase.

I’ve noticed this pattern before in discussions with other engineers. I explained to another engineer: just giving Claude Sonnet 4.5 our feature flag documentation plus a list of files that needed to modify was enough for it to make the changes fully autonomously. They responded by asking if I could package that up into an /add-feature-flag skill.

I didn’t see the point. The skill would just be 1-2 sentences of text and a list of files that needed to be modified in order to make changes to the feature flags. The skill would encapsulate nothing but the fact that this task was now easy to automate.

My recommendation is to engage with content that offers you skills, but try to learn the principles behind the skills instead of using the skills themselves. Try to prompt your AI agent to solve the problem yourself.

Doing this, I’ve found that after a while, I want to abstract my prompt into my own skill.

I remember reading an article about adding comments to plan documents inline, instead addressing them one by one in Claude Code’s prompt. I liked this technique and after trying it, ended up building produced this skill. Though I’ve provided a link, I recommend not clicking it.

Downloading skills won’t make you a good AI engineer. Understanding why they work and operationalizing the principles behind them will.

Andrey Karpathy does not do this. ↩

Now, effect systems could matter more than ever

Tue, 21 Apr 2026 05:40:00 +0000

Side-effects are where software gets risky. Most programming languages don’t include effects in their type signatures.

func add(_ a: Int, _ b: Int) -> Int {
  launchTheMissiles()
  return a + b
}

Based just on the type signature func add(_ a: Int, _ b: Int) -> Int of this Swift function, it’s impossible to know what happens inside of the function add.

As AI agents write a larger proportion of our software, the volume of code reviewed is getting larger and larger. Skimming type signatures is useful for getting a high level sense of whether the architecture is sensible. But without effects represented in the type system, it’s hard to be confident that the type provides an accurate summary of the functions behavior.

Effect systems allow expressing side-effects a function’s type signature. In Swift this might look something like this¹:

func add(_ a: Int, _ b: Int) {IO} -> Int {
  launchTheMissiles()
  return a + b
}

func launchTheMissiles() {IO} -> Void {
  // ... send a network request that launches a missile
}

Just looking at just the type signature func add(_ a: Int, _ b: Int) {IO} -> Int { immediately signals that something suspicious is going on. A function that adds two numbers shouldn’t need to perform any IO.

And with compiler support for effects, seeing the signature func add(_ a: Int, _ b: Int) {} -> Int (i.e. no effects) can guarantee that that the function doesn’t perform any side effects. Haskell and some other functional programming languages are able to guarantee² pure functions are side-effect free.

More granular effects make it possible to capture more aspects of architecture at the effect level. Fairly detailed effect tracking through dependency injection is already fairly commonplace in OOP. The @Dependency injected userService and analytics here mark the “effects” that are available to the view model.

final class ProfileViewModel: ObservableObject {
    @Published private(set) var user: User?
    @Published private(set) var isLoading = false
    @Published private(set) var errorMessage: String?

    @Dependency(\.userService) private var userService
    @Dependency(\.analytics)   private var analytics

    private let userID: String
    init(userID: String) { self.userID = userID }

    @MainActor
    func load() async {
        isLoading = true
        defer { isLoading = false }
        analytics.track("profile_viewed", properties: ["user_id": userID])
        do {
            user = try await userService.loadProfile(userID)
        } catch {
            errorMessage = error.localizedDescription
            analytics.track("profile_load_failed", properties: ["user_id": userID])
        }
    }
}

In addition to making the ProfileViewModel more testable, injecting effects makes it possible to see what the ProfileViewModel’s dependencies are. And though compiler wouldn’t prevent using NSURLSession directly from the ProfileViewModel, a code reviewer would likely notice and comment on such a change.

The need to review more code isn’t the only way AI agents shift in favor of stronger effect tracking. The largest burden of using effect systems in practice is that they invite a lot of boilerplate. The ProfileViewModel example only requires a little more boilerplate than calling a global function, but compiler enforced effect annotations can require extra bookkeeping on every function declaration.

When updating a function to use a new effect, it’s necessary to propagate that new effect annotation to all callers. AI agents are fairly good at automating a lot of this tedious work.

The shift to agentic programming makes reading code more important than ever. Representing which side-effects may be executed used to be fairly expensive, but is getting cheaper through the use of agents. Perhaps it is time to bring compiler enforced effect systems to main-stream programming languages.

I represent effects as a set of capabilities just before the function arrow. This matches Swift’s existing async/throws syntax for the effects it already represents in the type system, e.g. func f() async throws -> Int. ↩
There’s a little bit of fine print. This requires Safe Haskell forbidding the use of unsafePerformIO, etc. which other breaks type safety. This is strong enough to implement sandboxing for haskell.org’s “Try Haskell” widget. ↩

Unformed Delta - agentic-programming

I don't want your skills

Now, effect systems could matter more than ever