DEV Community: Kevin Alemán

AI Has a Problem With Functional Programming

Kevin Alemán — Thu, 15 Oct 2026 20:09:09 +0000

There is a pattern I keep seeing in AI-generated code. You ask it to implement something relatively simple and you get this:

const result = await processRequest(request);

async function processRequest(request) {
  const data = await getData(request);
  return transformData(data);
}

async function getData(request) {
  return repository.get(request.id);
}

function transformData(data) {
  return mapper.transform(data);
}

Every function looks perfectly reasonable in isolation. But most of those functions add almost nothing. We've turned two operations into a small guided tour of the codebase.

Very modular. I'm already tired.

And yes, saying AI has a functional programming problem is technically unfair. Functional programming isn't the issue. The problem is that LLMs seem unusually comfortable creating shallow abstractions: functions whose only purpose is calling another function.

And abstraction isn't free. Every function introduces another name, another place to jump to, another interface you need to keep in your head. You wanted to understand where the data comes from and now you're opening your fourth file.

Same job. More doors to open.

John Ousterhout describes a similar problem with shallow modules: abstractions whose interface is large relative to how much complexity they actually hide. They don't really remove complexity. They move it.

web.stanford.edu

Why does AI do this?

There isn't much evidence that LLMs inherently prefer functional or modular code.

In fact, an EMNLP 2024 study compared modular and non-modular versions of functionally equivalent code across several code models. Their conclusion was interesting: modularity itself was not a core factor in improving code-generation performance.

Revisiting the Impact of Pursuing Modularity for Code Generation - ACL Anthology

aclanthology.org

So the problem may be less about what the model wants and more about what we ask it to produce. We constantly tell AI to write code that is:

clean
modular
reusable
maintainable
single-responsibility

Those are good goals. But they are incredibly easy to satisfy mechanically:

Take these five lines and give them a name.

There you go. Clean code. We can all go home.

The model also doesn't experience the code like we do. Creating another helper costs it almost nothing. A human maintaining the result six months later has to navigate through it, figure out whether the helper does anything special and discover that, no, it just calls the next one.

And we're starting to get actual evidence that functionally correct LLM code can still have structural quality problems.

Both lights are green. Guess which one you want to debug six months from now.

An ICSE 2026 study measured how likely LLM-generated code was to contain code smells and found that generation strategy, model architecture, model size and, importantly, prompt formulation influence those smells.

A Causal Perspective on Measuring, Explaining and Mitigating Smells in LLM-Generated Code - Microsoft Research

microsoft.com

Another 2026 study looking at real repositories found that code detected as likely AI-generated showed substantial intra-repository code cloning. Basically, repeated code inside the same repository. That's another sign that generating locally reasonable code doesn't necessarily produce a cleaner system globally.

[2607.01867] An Exploratory Study on LLM-Generated Code and Comments in Code Repositories

The use of LLMs in software development has become increasingly widespread on tasks such as code generation and summarization. Reports from large technology companies showed that around 20% to 30% of their code are generated by LLMs. However, there remains skepticism about the practical usage of LLM-generated code and comments, such as concerns on more time for debugging the generated code and the unnaturalness of the generated comments. In this paper, we study the code and comments detected as likely to be generated by LLMs and their characteristics, the differences between company- and community-maintained repositories, and how likely bugs are associated with LLM-generated code. We conduct extensive experiments on active company- and community-maintained repositories from 2021 to 2025 using various tools and techniques that detect code and comments generated by LLMs. Based on our detector-based proxy analysis, the results suggest that code detected as likely to be generated by LLMs decreased over time and appeared frequently in test cases, while that of comments remains relatively stable. Proxy results further suggest that code detected as likely to be generated by LLMs shows substantial intra-repository code clones, whereas comments exhibit a relatively low proportion of grammatically correct sentences. In addition, the company-maintained repositories show a higher percentage of code and comments detected as likely to be generated by LLMs, and only a small percentage of the human-labelled bugs are detected as being likely associated with LLM-generated code.

arxiv.org

Maintainability research has moved far enough that researchers are now trying to predict the maintainability and code-smell characteristics of generated code before the model even generates it. One October 2026 paper, PreMaQ, evaluated 2,695 tasks across four models and found that its predictions correlated meaningfully with the eventual maintainability metrics of the generated code.

[2610.05858] PreMaQ: Predicting Maintainability-Related Quality of LLM-Generated Code Before Generation

As large language models (LLMs) become increasingly capable of code generation, adopting generated code in software development requires assessing not only its functional correctness but also its maintainability-related quality. If such quality could be estimated before generation, developers could avoid the cost of generating, reviewing, and discarding low-quality code. Although prior work has shown that the functional correctness of the LLM-generated code can be predicted in advance, it remains unclear whether maintainability-related quality is similarly predictable. We introduce Pre-Generation Maintainability-Related Quality Prediction (PreMaQ), which predicts the Code Smell Score (CSS) and Maintainability Index (MI) of generated code from the internal representations of LLMs before generation. Our evaluation covers four open-weight LLMs and four Python code generation benchmarks, comprising 2,695 tasks in total. Our results show that predicted CSS and MI consistently correlate with their observed values across all 16 model-benchmark combinations, achieving mean Spearman rank correlations of 0.57 and 0.65, respectively. When used for model selection, PreMaQ achieves 59.5% of the maintainability-related quality improvement attainable by an ideal maintainability-based selector over random selection on tasks for which multiple models generate functionally correct code. Combining predictions from PreMaQ and prompt embeddings increases this proportion to 60.7%, indicating that the two signals are complementary. These findings suggest that PreMaQ can be used to predict and improve the maintainability-related quality of LLM-generated code.

arxiv.org

None of these studies proves that AI loves one-line wrappers. They do show that "the code works" doesn't tell you everything about the code you're going to maintain.

So how do we stop it?

Tell the AI that abstractions need to pay rent.

A small entrance is useful when there's an actual workshop behind it.

I've started preferring instructions closer to:

Do not extract a function merely to make another function shorter. Create an abstraction only when it hides meaningful complexity, represents a domain concept, or is genuinely reused. Avoid pass-through functions and one-line wrappers. Prefer fewer concepts and a shorter call path.

The ICSE study above found that prompt formulation materially affects the kinds of code smells models generate, and that targeted mitigation can reduce their occurrence. That doesn't mean this exact prompt has been scientifically blessed. It means being specific about what you want is probably more useful than asking for "clean code" and hoping we all agree on what that means.

One final rule I like:

If the function's name is basically an English translation of its body, consider deleting it.

Consider, not automatically delete. A one-liner that expresses a real domain rule can still be useful. But if the only reason it exists is that the other function was getting a little long, maybe we don't need it.

AI is extremely good at producing more code. We're reaching the point where one of the most important skills when using it is asking it to produce less.

I used AI to cheat my way to a 156-day reading streak

Kevin Alemán — Tue, 13 Oct 2026 20:20:36 +0000

I asked Codex to recover my Apple Books reading streak. Very important engineering work, obviously.

Books showed two days. I had an 80-day run in the history, then a gap, then a few scattered reading days. It happens to the best of us. The app was reporting exactly what it had recorded. I wanted the old streak back anyway, so I asked an agent to fill the gap.

It ended up showing 156 days and New Record. I have read so much.

Before we go any further: don't try this at home. This is cheating. Do actual reading. The agent added reading time to dates that were below the goal. Those entries were manufactured. Nobody read 71 extra days while a script was running.

But the process was interesting. It involved private Swift APIs, backups, a background process, and, of course, a cache. Apparently even my questionable reading decisions need cache invalidation.

Start with the embarrassing part

My daily goal was one minute. One minute. Apple Books was already being very generous with me. Had it on 15 mins a day, but I had to travel and reduced to 1 minute (talk about commitment issues).

The old streak ran from May 11 through July 29, 2026. Continuing it through October 13 would make 156 calendar days. Of those, 85 already met their goals: the original 80, plus five later dates. That left 71 dates to fill.

Seventy had no daily record. August 1 had six seconds, so it needed another 54. How do you even get six seconds of reading? IDK. A date that already met its goal needed no changes, even if it contained much more reading time.

The calculation was small enough:

# Pseudocode
for day in requested_range:
    goal = stored_goal(day, default=60)
    recorded = recorded_seconds(day, default=0)
    additional = max(0, goal - recorded)

    if additional:
        increment_reading_time(day, additional, default_goal=60)

The dates also needed the correct timezone. The edits used America/El_Salvador and local noon, keeping each increment inside its intended calendar day. It would be a pretty annoying way to discover a timezone bug, after going through all this to change a number. A big part of this was possible (within the 5 hour window of my $20 codex subscription) thanks to the work previously done to understand the Apple books data model. Give it a read if you want to read about sqlite databases.

Kevin Alemán

Jun 22

The Apple Books data model

#macos #sqlite #programming #database

6 min read

Now, let's start.

Make the backup before getting clever

The history file involved was:

~/Library/Group Containers/group.com.apple.iBooks/CRDTModelLocalFile/ReadingHistoryModel

Before changing it, Codex backed up the history, its context and sync metadata, and the relevant Books preferences. The SQLite context databases were copied through SQLite's backup API. A permanent backup went into Documents, separate from the scratch files.

Then the experiments happened on copies. That was useful because some of the first attempts at calling Apple's private Swift code failed.

An agent having access to your files is a good reason to make the original easy to restore. Keep the backup somewhere separate, give it a name you understand, and be clear about which dates the agent is allowed to change. In this case, the scope was the missing goal time within one specific streak.

The C bridge that called Apple's Swift code

This was the part I wanted to understand properly. Codex found an operation in the installed frameworks:

ReadingHistoryModel.incrementReadingTime(date:amount:defaultGoal:)

But having a method name and calling the method are two separate problems. There was no available SDK module to import for this private interface. The tool used a C bridge to load the framework, resolve the Swift entry points, and call them with the required binary calling convention.

The calls went in both directions. The Swift driver called ordinary C functions declared in native.h. Those C functions called Apple's compiled Swift functions through typed function pointers. The framework was loaded at runtime with dlopen; the C object file was linked into the driver at build time.

Below is the complete C bridge used in this experiment, split into pieces so the explanation can stay next to the code. These are the actual functions and symbols used on this Mac. The Swift snippets are excerpts from the driver.

Start with the C interface

native.h

#include <stdint.h>
typedef struct { uint64_t a, b; } Bits;
void *history_decode(uint64_t a, uint64_t b);
Bits history_describe(void *model);
Bits history_encode(void *model);
void history_increment(void *model, double date, int64_t amount, int64_t goal);
void *history_error(void);
void *history_type(void);
void history_set_streak(void *model, void *dictionary_metadata, void *date, int64_t length);

Bits carries two 64-bit words across the C boundary. On this installation, that matched the representation used for the Data arguments and the Data and String results involved in these calls. Those words can contain storage references or inline information; they are the Swift value's representation, rather than a byte-buffer API.

The C interface exposes opaque pointers for the model and its metadata. The driver uses history_error() to retrieve a captured Swift error and history_type() when reflecting on the model later.

Tell Clang how to call Swift

native.c — attributes, function types, and symbol lookup

#include "native.h"
#include <dlfcn.h>
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#define SWIFT __attribute__((swiftcall))
#define SELF __attribute__((swift_context))
#define ERROR __attribute__((swift_error_result))
#define RESULT __attribute__((swift_indirect_result))
typedef struct { void *value; uintptr_t state; } MetadataResponse;
typedef MetadataResponse (*MetadataFn)(uintptr_t) SWIFT;
typedef void (*DecodeFn)(void * RESULT, uint64_t, uint64_t, void *, void *, void * SELF, void ** ERROR) SWIFT;
typedef Bits (*BitsFn)(void * SELF) SWIFT;
typedef Bits (*EncodeFn)(void *, void *, void *, void *, void * SELF, void ** ERROR) SWIFT;
typedef void (*IncrementFn)(void *, int64_t, int64_t, void * SELF) SWIFT;
static void *metadata, *witness, *last_error;
void *history_error(void) { return last_error; }
void *history_type(void) { return metadata; }
static void *symbol(const char *name) {
    void *value = dlsym(RTLD_DEFAULT, name);
    if (!value) { fprintf(stderr, "Missing symbol: %s\n", name); exit(1); }
    return value;
}

The attributes carry the calling-convention information:

Macro	Role in the bridge
`SWIFT`	Call the function using Swift's calling convention
`SELF`	Give the context parameter its special Swift ABI treatment
`RESULT`	Pass storage for an indirectly returned value
`ERROR`	Receive the error result from a throwing Swift call

What's ABI

No, it's not the name of a girl ;) even tho it may be. ABI stands for Application Binary Interface. In short, it defines how already compiled Swift code interacts at the binary level and how the code talks to the runtime.
Type layout conventions, representation, metadata, etc.
You can find way more about this on the web, and probably better explained :)

Clang still needs a function type that describes the lowered arguments correctly. swiftcall handles their low-level placement; the bridge must supply indirect pointers, generic arguments, context, and error parameters in the right shape. The Clang attribute reference documents this distinction.

The symbol() helper resolves an address with dlsym. The $s... strings are Swift's mangled symbol names. They carry information about the module, type, operation, and signature. One of the names used here can be inspected with:

xcrun swift-demangle --compact '$s13BookDataStore19ReadingHistoryModelV09incrementD4Time4date6amount11defaultGoaly10Foundation4DateV_S2itF'

The result identifies ReadingHistoryModel.incrementReadingTime(date:amount:defaultGoal:). Finding that address gives us a place to call. The typedef determines how the call gets there.

Decode a type C doesn't know about

native.c — loading and decoding

void *history_decode(uint64_t a, uint64_t b) {
    assert(dlopen("/System/Library/PrivateFrameworks/BookDataStore.framework/BookDataStore", RTLD_NOW | RTLD_GLOBAL));
    MetadataFn meta = symbol("$s13BookDataStore19ReadingHistoryModelVMa");
    metadata = meta(0).value;
    void *(*conforms)(void *, void *) = symbol("swift_conformsToProtocol");
    witness = conforms(metadata, symbol("$s9Coherence4CRDTMp"));
    assert(metadata && witness);
    uintptr_t *vwt = ((uintptr_t **)metadata)[-1];
    size_t size = vwt[8];
    assert(size > 0 && size < 4096);
    void *model = calloc(1, size);
    void *error = NULL;
    DecodeFn decode = symbol("$s9Coherence4CRDTPAAE14serializedDatax10Foundation0D0V_tKcfC");
    decode(model, a, b, metadata, witness, metadata, &error);
    if (error) { last_error = error; return NULL; }
    fprintf(stderr, "Native model decoded (%zu bytes)\n", size);
    return model;
}

dlopen loads BookDataStore. RTLD_GLOBAL makes its loaded exports available to the subsequent RTLD_DEFAULT lookups; the required Coherence symbols were available through the loaded dependencies.

The metadata accessor returns the runtime type information for ReadingHistoryModel. MetadataResponse models its pointer-and-state result; meta(0).value keeps the metadata pointer. swift_conformsToProtocol then retrieves its conformance to Coherence.CRDT. That conformance is represented by a witness table: the information the generic decoder needs to use this particular type's implementation.

C also needs somewhere to put the decoded value. The pointer immediately before the metadata points to its value witness table, which includes layout and value-management information. The bridge reads the size slot used by this ABI, allocates storage, and passes it as the indirect result. The decoded model occupied 24 bytes in this run. Swift's type metadata documentation describes the metadata and value witness table relationship.

The decoder call has more arguments than its Swift source-level spelling suggests. It receives the output storage, the two Data words, generic type metadata, the protocol witness table, the initializer's metatype context, and the error result. The metadata pointer appears twice because those are distinct roles in this entry point.

The driver supplied the Data representation like this:

import Foundation

let arguments = CommandLine.arguments
guard arguments.count >= 3 else { fatalError("input output [increments.json]") }
let data = try Data(contentsOf: URL(fileURLWithPath: arguments[1]))
precondition(MemoryLayout<Data>.size == MemoryLayout<Bits>.size)
let bits = unsafeBitCast(data, to: Bits.self)
guard let model = history_decode(bits.a, bits.b) else {
    let error = unsafeBitCast(history_error()!, to: (any Error).self)
    print("Native decode failed: \(error)")
    exit(1)
}

unsafeBitCast reinterprets the value's bits. The size check catches a size mismatch, but it does not establish that an arbitrary Swift type can safely be passed this way. This bridge depended on the representation and ownership behavior of these specific calls.

Inspect and serialize the model

native.c — description and encoding

Bits history_describe(void *model) {
    BitsFn describe = symbol("$s13BookDataStore19ReadingHistoryModelV16debugDescriptionSSvg");
    return describe(model);
}
Bits history_encode(void *model) {
    EncodeFn encode = symbol("$s9Coherence11CRMergeableP14serializedData_7version10Foundation0D0VAA9CRContextC_AA16CRCodableVersionOtKFTj");
    void *(*conforms)(void *, void *) = symbol("swift_conformsToProtocol");
    void *mergeable_witness = conforms(metadata, symbol("$s9Coherence11CRMergeableMp"));
    assert(mergeable_witness);
    MetadataFn context_meta = symbol("$s9Coherence9CRContextCMa");
    void *(*create_context)(void * SELF) SWIFT = symbol("$s9Coherence9CRContextC6sharedACvgZ");
    void *context = create_context(context_meta(0).value);
    uint8_t version = *(uint32_t *)symbol("$s9Coherence16CRCodableVersionO8version3yA2CmFWC");
    void *error = NULL;
    Bits bits = encode(context, &version, metadata, mergeable_witness, model, &error);
    if (error) { last_error = error; return (Bits){0,0}; }
    return bits;
}

history_describe calls the model's debug-description getter. The Swift driver interprets the returned Bits as a String and uses that description in its round-trip checks.

Encoding uses a separate CRMergeable conformance, its serialization dispatch thunk, and the shared CRContext. The bridge resolves the installed enum case tag for version3 and passes its address to the encoder. That tag lookup and argument representation were checked for this installation.

Both throwing calls start with a null error pointer. On failure, the bridge captures the returned error for the driver. On success, encoding returns the representation of a Swift Data value, which the driver writes to a scratch file and decodes again before any live replacement.

The increment, and the pointer that mattered

native.c — adding reading time

void history_increment(void *model, double date, int64_t amount, int64_t goal) {
    IncrementFn increment = symbol("$s13BookDataStore19ReadingHistoryModelV09incrementD4Time4date6amount11defaultGoaly10Foundation4DateV_S2itF");
    increment(&date, amount, goal, model);
}

This is the function that added the missing seconds. The driver already had the intended day and the amount needed to reach its goal:

history_increment(
    model,
    date.timeIntervalSinceReferenceDate,
    Int64(edit["amount"]!),
    60
)

The important detail in C is increment(&date, amount, goal, model).

For this entry point on the installed build, Swift expected Date indirectly. Its storage contained the reference-date time interval, so the wrapper put that value in a local double and passed its address. The model pointer received the Swift context treatment specified by SELF. The int64_t arguments also assumed the 64-bit Swift.Int representation used on this Mac.

An earlier attempt declared the date as a directly passed double. The scratch process crashed inside Calendar.component(_:from:), attempting to read address 0x3c: decimal 60, one of the other argument values. The callee was reading the wrong thing as its date pointer. A small Swift probe compiled to LLVM IR confirmed the indirect date argument.

That's a fairly concrete reason to inspect the calling convention before trusting a function-pointer cast. The compiler can accept the cast while the call is still wrong.

Update the record dictionary

native.c — adding streak milestones

void history_set_streak(void *model, void *dictionary_metadata, void *date, int64_t length) {
    intptr_t (*offset)(void *, intptr_t) = symbol("swift_reflectionMirror_recursiveChildOffset");
    intptr_t field_offset = offset(metadata, 1);
    assert(field_offset == 8);
    void (*set)(void *, void *, void *, void * SELF) SWIFT = symbol("$s9Coherence15CRDictionary_v1Vyq_Sgxcis");
    set(date, &length, dictionary_metadata, (char *)model + field_offset);
}

The Swift driver reflected on the decoded model, checked that the selected field was named streakRecords, and obtained its dictionary type metadata. On this build, it was CRDictionary_v1<Int, Date>.

The C helper asks for the field's offset, asserts the observed eight-byte offset, and calls the installed dictionary setter. The setter gets the optional date value, the integer key, the dictionary metadata, and the address of the dictionary field as its Swift context.

The date argument here is a pointer to the actual Swift Date? representation. The driver prepared it with:

var date: Date? = start.addingTimeInterval(Double(length-1)*86400)
withUnsafeMutablePointer(to: &date) {
    history_set_streak(model, dictionaryMetadata, $0, Int64(length))
}

That allowed the native setter to add milestones 81 through 156 while keeping the existing records. The field index, offset, dictionary type, and symbol name are all assumptions that need checking on another build.

Build the bridge and the driver

In the scratch directory, the build commands were:

clang -c native.c -o native.o

swiftc \
  -module-cache-path /private/tmp/books-streak-recovery/module-cache \
  -import-objc-header native.h \
  repair.swift native.o -o repair

-import-objc-header exposes the C declarations to the Swift driver; the header itself contains ordinary C. Linking native.o supplies those helper implementations. The private Swift entry points are resolved later, when the running tool loads the framework.

The full driver also handled the requested dates, error reporting, serialization, and verification. The snippets above focus on the language boundary.

Keep the assumptions visible

This was a short-lived repair process with global state and build-specific layout assumptions. It leaves decoded allocations alive until process exit. A reusable library would need proper Swift value destruction, ownership and alignment handling, allocation checks, and a fuller error lifecycle. But the goal is to not make this an habit and start reading like a functional human being

There is also a very practical footgun in the actual code: dlopen sits inside assert. These builds had assertions enabled. Defining NDEBUG would remove the framework load along with the check; a maintained implementation should load it separately and handle failure explicitly.

The code is here because it explains what made the experiment work. It should also explain why I keep saying to leave your reading-history files alone.

And then Books still said two days

After the daily entries were filled, Books recognized another completed day in the current week. The streak still said two days. The record still said 80.

Of course there was more state. It's Apple, there should be something else, somewhere.

Three pieces needed to agree:

The daily history needed enough credited time for the missing dates.
streakRecords needed the newly reached streak lengths and their dates.
ReadingHistory.CurrentStreak needed the new cached count.

The record dictionary ended at 80 days. Codex preserved those entries and added milestones 81 through 156, dated July 30 through October 13. We had to populate this data too.

Swift reflection identified the record field and its dictionary type, and the bridge used the installed dictionary implementation's setter. Another check confirmed that these changes left the daily history unchanged. Finally, with Books closed, the cached count was updated:

BOOKS_PREFS="$HOME/Library/Containers/com.apple.iBooksX/Data/Library/Preferences/com.apple.iBooksX.plist"

defaults write "$BOOKS_PREFS" ReadingHistory.CurrentStreak -int 156

That command only handles the cache. The daily records and streak milestones had already been edited. ReadingHistory.LastStreakDate already contained 20261013, so it stayed unchanged.

Make the app use the edited history

Books and bookdatastored can keep history in memory. Editing the file while they're using it creates an opportunity for a later write to replace your changes. Then we had to close Books app for the cache to be read again.

Before replacement, the live daily history was compared with the version used to prepare the edits. The validated file was staged beside the live one, given the same permissions, flushed, and installed with os.replace. The cache was refreshed while Books remained closed.

Opening Books started the helper again. This time, Reading Goals showed 156 days, a 156-day record, and New Record.

The checks covered both the file and the app. The serialized output was decoded again, its model description was compared with the in-memory result, and every daily date, time, and goal was checked. The app then confirmed that it was displaying the intended result. FINALLY!

The advice I should probably follow

There's an awkward connection to my last article about AI. I wrote about how much easier it is becoming to produce a result, and how we still need to pay attention to the work and understanding behind it:

Kevin Alemán

Oct 8

The future, after AI

#ai #programming #career #beginners

6 min read

Here I was, asking an agent to produce a very impressive number in a book app. It did the software work. It inspected the state, made the edits, and checked the result. My reading habit still needs me to open a book tomorrow, but I'll start from 156 rather than 2 ;)

If you want something practical to do with Books, set a daily goal you can actually meet. On the Mac, that's under Home → Reading Goals → Adjust Goal. Then read. After a missed day, start another streak.

Gotta be honest: my reading goal was 1 minute and even with that low value, I couldn't do it (commitment issues? who?).

The fun lesson, as always, is: you can have the streak you want. It's just a number. The actual value is never in the milestone, is what you learn in the road :)

The future, after AI

Kevin Alemán — Thu, 08 Oct 2026 19:52:28 +0000

I've been using AI coding tools for a while now, and the progress is honestly insane. Something that would take a junior developer a day can sometimes be done by an agent in 20 minutes, with tests, documentation and probably better error handling than what I would've written on a Friday afternoon. That, alone, is insane: imagine the time you save on writing code and how you can invest that in some other stuff.

But there's something about this that has been bothering me lately:

What happens when producing good code no longer requires understanding how to produce good code?
And more importantly: what happens to the next generation of senior developers?

Juniors are becoming very productive

Imagine you're learning backend development and I ask you to create an endpoint.

You need to:

validate some input
query the database
handle errors
return the proper HTTP codes
write tests

A few years ago, you probably had to learn at least something about each of those things to finish the task.

Maybe your SQL query was horrible and you learned about indexes because of it.
Maybe two requests modified the same thing and you discovered race conditions.
Maybe you returned 200 for literally everything because HTTP status codes were still a mystery to you (we've all been there), that’s the point where I learned about httpcat.com lol

Today, you can ask an agent:

“Implement this endpoint following the patterns in this repository. Add validation and tests.”

And there's a pretty good chance it will do it correctly. The junior is now more productive. You are more productive. I am more productive. Everyone is happy.

But did you actually learn why the implementation is correct? That's a different question.

A 2026 study from the Technical University of Munich tested this with 275 programming students. Students using AI performed better on the programming tasks, but that improvement did not translate into significantly better conceptual understanding compared with students using traditional resources.

This is interesting for one very important reason: we're getting better at producing the result, but not necessarily better at understanding how we got there. It’s like eating a frozen pizza: you ate a pizza, that’s great. But, did you learn how to make a pizza?

The boring stuff was useful

The problem is that a lot of the annoying parts of learning programming were actually... learning. Spending two hours debugging something stupid sucks, reading documentation because Stack Overflow didn't have your exact answer (or they just threw rocks at you for asking a “dumb” question) sucks, writing a slow database query, discovering it's slow, understanding why and fixing it sucks.

But you remember those things.

I've said this before and I'll probably keep saying it until AI replaces me: You cannot prompt what you don't know exists.

And there's a second part to that: You cannot properly review what you don't understand.

AI can generate a perfectly reasonable database query. But, *how do you know it's going to murder your database when the table has 20 million rows? *

AI can implement retries. But, how do you know retrying that specific operation can charge someone twice?

AI can add caching. But, *how do you know the thing you're caching should not be cached? *

The answer is experience. And experience usually comes from doing stuff, breaking stuff and sometimes wondering why the hell production is on fire. If we let AI remove too much of that process, _we may be removing part of the path that creates good engineers. _

There's already some evidence that this isn't only a programming thing. Microsoft Research surveyed 319 knowledge workers about 936 real uses of generative AI. Higher confidence in AI was associated with less critical thinking effort, while people who were more confident in their own knowledge tended to think more critically about the result. Which makes sense. If you know the topic, AI is something you supervise. If you don't, AI can easily become something you trust.

Ok, but they'll learn later... right?

Maybe.

But here's where things get more complicated. We're also starting to need fewer junior developers. Stanford's Digital Economy Lab has been tracking employment in occupations exposed to AI using payroll data from millions of workers. Their August 2026 update found something pretty noticeable: employment for workers aged 22–25 in highly AI-exposed occupations was about 19% below where it would've been if it had followed the same trend as less-exposed occupations. More experienced workers did not show the same gap.

They also found that the difference seems to be coming mostly from reduced hiring, not people getting fired. That doesn't mean "AI killed 19% of junior jobs". Labor markets are way more complicated than that and the researchers themselves don't claim that, but the direction is something to take a closer look.

Companies can give experienced developers AI tools and suddenly get a lot more output from them. So why hire five juniors when your existing team can now do more? Economically, that can make perfect sense. Until it doesn’t.

Where do seniors come from?

This is the part I think we're not discussing enough, Senior developers don't spawn with 8 years of experience. Every senior was a junior. Even the ones you see on the web with thousands of followers or the ones that have created truly amazing stuff, they were juniors some day (except from the guy that wrote TempleOS, I think he received his knowledge by divine grace). Every staff engineer wrote stupid code. Every database expert probably created at least one query they're not particularly proud of. You become experienced by accumulating a ridiculous amount of small lessons over many years.

But imagine the direction we're heading:

Companies hire fewer juniors.
The juniors we hire skip more of the low-level work using AI.
Experienced developers become insanely productive using agents.
Companies need even fewer developers.

Looks pretty good on an Excel sheet, then 10 years pass and someday you turn around and ask yourself: “Where are the new senior engineers?”. We could end up creating some kind of experience debt. Similar to technical debt: you move faster today by borrowing from the future.

Except this time we're borrowing engineers.

So... should juniors stop using AI?

No. That would be dumb. AI is probably one of the best learning tools we've ever created. You have something available 24/7 that can explain a concept 20 times without getting tired of you.

Use it.

But there's a big difference between: “Build this for me” and “help me understand how to build this”.

There's also a difference between accepting the first implementation and asking: “What can go wrong here?” Or “Why did you choose this approach?” Or even closing the AI for an hour and trying to solve the damn thing yourself.

We're not going back. AI is here, agents are getting better and software will probably continue becoming cheaper to produce, which is good, but we have to be careful not to optimize the learning out of learning, because in the future the problem may not be that there’s no longer a “programming” career, or that AI finally replaced everyone and now we have to adore Sam Altman for a living.

It might be that we have the most powerful tools available, the better models… but not enough people who actually understand what the hell is going on anymore.

Gotta Earn 'Em All: The Gym Badges of Agentic Engineering (Part 2)

Kevin Alemán — Fri, 03 Jul 2026 02:35:20 +0000

Last time we earned four badges: bedrock, context, scoped speed, and the patience to garden instead of shaking a vending machine. If you missed it, it's linked above. The guard at the gate hasn't moved. But you did.

Quick refresher if you're just walking in: by "agentic engineering" I mean using AI agents like Claude Code or Copilot to build real software, not just tab-complete. And fair warning, one of today's badges comes with receipts. 211 million lines of code worth.

The first four gyms give you the basics. Useful! But nobody becomes Champion by learning just the basics. Past Celadon the game changes: it stops being about doing the work and starts being about not getting fooled by it.

Let's finish this.

Badge 5: Soul Badge: learn to taste poison

Koga. Poison type. His gym is a maze of invisible walls, so you spend twenty minutes walking face-first into nothing while ninjas watch you. Foreshadowing.

This might be THE badge of the agent era, and the hardest to teach. Not spotting code that's wrong. Spotting code that's wrong while looking completely, beautifully right.

// looks done. runs. passes the demo.
users.forEach(async (user) => {
  await sendNotification(user);
});
console.log("All notifications sent!");

// what actually waits
for (const user of users) {
  await sendNotification(user);
}
console.log("All notifications sent!");

Every line in the first block is real, and the 3-user demo works. But forEach ignores your await: the log prints before a single notification goes out, and if one fails, the error evaporates into the void. Nothing is broken enough to fail. Everything is broken enough to hurt you in two weeks.

That's what poison tastes like. Not bitter. Slightly, slightly off.

And you can't outsource the taste test: asking an LLM "is this slop?" can produce slop in the answer. Tasting is a human skill, and you earn it by having eaten some poison before. (Hello again, Badge 1.)

If you can't tell legit from slightly-off, the agent is driving and you're asleep in the passenger seat. Don't offload your life to the agents. Control them. You are the human in charge.

Badge 6: Marsh Badge: it's not telepathy

At some point the agent finishes your thought, matches your style, and your brain quietly files it under "understands me."

It doesn't. What actually happens when you get good is way less mystical: you build a mental model of how it screws up. It invents APIs with total confidence. It knows nothing newer than its training. And it will happily agree with a wrong premise if you say it like you mean it:

// what most people send
"since the bug is in the cache layer, fix the cache invalidation"

// what you could be doing
"users report stale data after profile updates.
here's the request flow and the cache config.
where would YOU look first, and why?"

State it with enough conviction and the agent will find you a bug in the cache, whether one lives there or not. Ask it to reason first and it suddenly can.

Prompting is talking to a very smart coworker with amnesia about your project and a habit of bluffing. Internalize that and half your prompts fix themselves for free.

There's plenty of "skills" that would help you on this matter. A few examples:

https://github.com/multica-ai/andrej-karpathy-skills

Superpowers | Claude by Anthropic

Claude learns brainstorming, subagent development with code review, debugging, TDD, and skill authoring through Superpowers.

claude.com

Use them. They're not magic, they're frameworks. You can still produce bad things with them. But they'll help you not to shoot yourself in the foot too frequently.

Badge 7: Volcano Badge: the fire doesn't care who wrote the code

Blaine makes you answer quiz questions before he'll even battle you. Which is just debugging with extra steps: you answer the riddles, then you get the fight.

Generating code is the tutorial. This badge is everything after it ships, when the thing the agent wrote is live and gently combusting at 2 AM. No clever prompt saves you here. You need logs you can actually read. Traces. The hard-won knowledge that one container's JSON log file can quietly eat a whole disk while you sleep (don't ask how I know. ok, ask, it was bad).

Unlike the other badges, this one has a concrete training regime:

Make your logs readable before you need them. Structured logs with request IDs, not console.log("here 2"). Future-you at 2 AM is a dumber person. Write for him.
Learn one tracing tool. Any. "Where did this request die" should be a query, not a vibe.
Read your own logs cold. Trace one request end to end on a normal day. If you can't follow it when nothing's broken, you have zero chance when everything is.
Treat your agent as a coworker. Share with it all the context you would share with a human: stack traces, logs, screenshots, etc. Anything that it can use to understand and help you investigate. That's very useful.

This also means you should know your product even if you vibe coded it. If you don't, then when the fire happens and Claude is down (and that happens very often, recently) you will be alone with your thoughts, and with some code that you've never seen in your life...

Badge 8: Earth Badge: it's your name on the commit

I said I wasn't explaining this one until we got here, so: Giovanni isn't just the eighth gym leader. He's the boss of Team Rocket. You spend the whole game dismantling his operation, and the final badge, the one the guard is waiting for, gets handed to you by the villain himself.

Kid-me thought that was a cool twist. Adult-me sees what the twist is actually saying. Think about what Team Rocket is: they don't raise Pokémon, they steal them. Their entire philosophy is getting the power without doing the training. And Giovanni is living proof it works: he's rich, he's feared, he runs a whole city. The game puts him, of all people, between you and the League. The final obstacle isn't a stronger trainer. It's the successful guy offering you his way of doing things.

That's why I call it a temptation. The final boss of agentic engineering isn't a gnarly bug. It's the shortcut philosophy, and it visibly works, at least at first. Let the agent's judgment quietly replace yours. Ship volume because merging feels like progress. Paste 200 lines you didn't read because it looked right and it was late. Shipping unread agent output is stealing Pokémon instead of training them: same power on paper, none of it yours.

And before you tell me this is a "skill issue" that only happens to juniors: the industry is drifting into it at scale, and we have receipts. GitClear analyzed 211 million changed lines of code across five years. Duplicated code blocks jumped 8x in a single year. Copy/pasted lines exceeded refactored ("moved") lines for the first time in the dataset's history. Churn, the code you rewrite within two weeks of committing it because it wasn't right the first time, roughly doubled from its pre-AI baseline. And Google's own DORA report found delivery stability dropped 7.2% as AI adoption went up.

You can watch the same movie at a single company. Spotify's VP of Engineering recently shared that they ship 4,500 production deploys a day, with 73% of PRs now AI-assisted. Genuinely impressive numbers. Meanwhile, their own community forums are an endless scroll of "the app gets slower and worse with every update," and the most viral reaction to those 4,500 deploys was someone asking what in the hell they're all for, since the product barely feels different. I'm not saying the AI-assisted PRs caused the complaints, that would be lazy. I'm saying throughput went vertical and perceived quality didn't follow, and that's a problem.

Sources, so you can check me. The 211M lines analysis:

gitclear.com

DORA on delivery stability:

DORA | Accelerate State of DevOps Report 2024

DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.

dora.dev

Spotify's 4,500 deploys/day and 73% AI-assisted PRs + reaction:

// Detect dark theme var iframe = document.getElementById('tweet-2071817938076860432-787'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2071817938076860432&theme=dark" }

Everyone is shipping faster. What's shipping is not clearly getting better. Nobody decided this. Millions of developers drifted into it, one skipped review at a time. That's what makes it the boss fight.

The annoying fact that keeps you grounded: the agent doesn't own the PR. You do. When it breaks, nobody opens a ticket against the model. Code is cheap now. Your name isn't.

Eight badges. Now what?

The gate isn't the end. It's a new beginning. As everything in life, once you reached the summit, you realize it was one of many...

The Apple Books data model

Kevin Alemán — Mon, 22 Jun 2026 19:54:21 +0000

Apple Books stores everything about your reading on disk, in plain SQLite. Your books, your highlights, your shelves, your ratings, the dates you finished things, all of it sits in a handful of databases you can open and query right now. The app surfaces only a fraction of it.

This is a reference for that data model: where it lives, the conventions it follows, the entities that matter, and, most importantly, how those entities connect. The relationships are the interesting part. A single table is just a list; the model is the set of links between tables, and Apple Books has three distinct relationship patterns worth understanding.

Everything below is observable on any Mac with Books installed. No private APIs, no entitlements, just SQLite.

Storage layout

Sandboxed macOS apps keep their data under ~/Library/Containers. Apple Books spreads its across a few SQLite files in two containers:

~/Library/Containers/com.apple.iBooksX/Data/Documents/
├── BKLibrary/
│   └── BKLibrary-1-091020131601.sqlite           # the library: one row per book
├── AEAnnotation/
│   └── AEAnnotation_v10312011_1727_local.sqlite  # highlights and notes
└── BCRecentlyOpenedBooksDB/
    └── BCRecentlyOpenedBooksDB.sqlite            # recently-opened events

The numeric suffixes in the filenames are not stable across installs, so match on the prefix (BKLibrary-1-*.sqlite) rather than hardcoding the full name.

Core Data conventions

Every table and column is uppercase and prefixed with Z: ZBKLIBRARYASSET, ZTITLE, ZANNOTATIONASSETID. That prefix is the signature of Core Data, Apple's persistence framework, which generates the SQLite schema underneath. Recognizing it tells you what to expect:

Z_PK — integer primary key on every entity table.
Z_ENT — which entity (table) a row belongs to.
Z_OPT — Core Data's optimistic-locking version counter.
Application columns carry the Z prefix too (ZTITLE, ZRATING, ...).

Two quirks follow from this that affect almost every query:

Booleans are nullable. Flags like ZISFINISHED are 1 or NULL, not 1 or 0. WHERE ZISFINISHED = 0 matches nothing. Use IS NULL / != 1 for the negative case.

Timestamps use a 2001 epoch. Core Data counts seconds from 2001-01-01, not the Unix 1970-01-01. The two differ by exactly 978307200 seconds. To read any date column as a real date:

SELECT date(ZDATEFINISHED + 978307200, 'unixepoch') FROM ZBKLIBRARYASSET;
-- 2026-05-16

Every date column in every one of these databases uses the same offset.

Reading the files safely

Books keeps these databases open in WAL mode (Write-Ahead Logging). Recent changes live in -wal and -shm sidecar files next to the main .sqlite and have not yet been checkpointed into it. Opening the main file directly while Books is running yields stale reads or lock errors.

The safe approach for read-only analysis is to copy the database and its sidecars to a scratch location, then open the copy read-only:

BKLibrary-1-...sqlite      →  copy
BKLibrary-1-...sqlite-wal  →  copy   (must travel together)
BKLibrary-1-...sqlite-shm  →  copy

SQLite reconstructs the current state from the copied set, and the originals are never touched.

The central entity: ZBKLIBRARYASSET

ZBKLIBRARYASSET is the hub of the model: one row per item in your library, and the table nearly everything else links back to. It has over a hundred columns; these are the ones that carry meaning:

Column	Meaning
`ZASSETID`	stable identifier for the book — the join key for the entire model
`ZTITLE`, `ZAUTHOR`, `ZGENRE`, `ZLANGUAGE`	descriptive metadata
`ZPAGECOUNT`, `ZREADINGPROGRESS`	length, and progress as a 0–1 float
`ZISFINISHED`, `ZDATEFINISHED`	completion flag (1/NULL) and date
`ZRATING`	user star rating; `0` means unrated
`ZPURCHASEDATE`, `ZLASTENGAGEDDATE`	acquisition and last-interaction timestamps
`ZCONTENTTYPE`	format/role of the row (see the series section)
`ZSERIESID`, `ZSERIESNEXTFLAG`	series membership and "next up" marker
`ZDURATION`	runtime in seconds for audiobooks (`0` otherwise)

A baseline query, books finished:

SELECT count(*) FROM ZBKLIBRARYASSET WHERE ZISFINISHED = 1;

ZASSETID is the thread that runs through the whole model. Hold onto it.

The relationships

Three relationships connect to ZBKLIBRARYASSET, and each uses a different structural pattern: a cross-database join, a junction table, and a self-join.

1. Highlights — a cross-database relationship

Highlights and notes are not stored with the books. They live in a separate database, AEAnnotation, in the table ZAEANNOTATION. Each row is one annotation:

Column	Meaning
`ZANNOTATIONASSETID`	foreign key to the book
`ZANNOTATIONSELECTEDTEXT`	the highlighted text
`ZANNOTATIONNOTE`	attached note, if any
`ZANNOTATIONSTYLE`	highlight color, `0`–`5`
`ZANNOTATIONDELETED`	soft-delete flag — filter `= 0`

The link is ZANNOTATIONASSETID, and the non-obvious detail is which library column it targets. It is not ZEPUBID; it matches ZASSETID.

ZBKLIBRARYASSET.ZASSETID  ──1:N──  ZAEANNOTATION.ZANNOTATIONASSETID

Because the two tables live in different files, the join requires attaching one database to the other first. SQLite's ATTACH makes them queryable as one:

ATTACH DATABASE 'annotations.sqlite' AS ann;

SELECT b.ZTITLE, count(*) AS highlights
FROM ann.ZAEANNOTATION a
JOIN ZBKLIBRARYASSET b ON b.ZASSETID = a.ZANNOTATIONASSETID
WHERE a.ZANNOTATIONDELETED = 0
  AND a.ZANNOTATIONSELECTEDTEXT IS NOT NULL
GROUP BY b.ZTITLE
ORDER BY highlights DESC;

Become an Effective Software Engineering Manager | 404
La Atalaya, marzo de 2026                        |  53
The Midnight Library: A Novel                    |  25

2. Shelves — a many-to-many via junction table

Collections (Want to Read, Finished, and custom shelves) are a many-to-many relationship: a book can belong to several collections, and a collection holds many books. Core Data models this with a junction table in the middle.

ZBKCOLLECTION           ZBKCOLLECTIONMEMBER          ZBKLIBRARYASSET
  Z_PK   ◄──────────────  ZCOLLECTION                     ZASSETID
  ZTITLE                   ZASSETID  ─────────────────────────►
                           ZSORTKEY

ZBKCOLLECTIONMEMBER holds one row per membership, pointing both ways: ZCOLLECTION references the collection's Z_PK, and ZASSETID references the book. Listing the contents of a named shelf means traversing the junction:

SELECT b.ZTITLE
FROM ZBKCOLLECTIONMEMBER m
JOIN ZBKCOLLECTION c   ON c.Z_PK = m.ZCOLLECTION
JOIN ZBKLIBRARYASSET b ON b.ZASSETID = m.ZASSETID
WHERE c.ZTITLE = 'Want to Read'
ORDER BY m.ZSORTKEY;

3. Series — a self-join with a container row

Series have no dedicated table. Instead, two things encode them inside ZBKLIBRARYASSET itself:

Every book in a series carries a shared ZSERIESID.
The series itself is a placeholder row in the same table, identified by ZCONTENTTYPE = 5. It stores the series' name and metadata but is not a readable book.

Reporting on a series therefore means joining ZBKLIBRARYASSET to itself: the real members on one side, the container row on the other, matched on ZSERIESID.

SELECT
  (SELECT c.ZTITLE FROM ZBKLIBRARYASSET c
     WHERE c.ZSERIESID = m.ZSERIESID AND c.ZCONTENTTYPE = 5 LIMIT 1) AS series,
  count(*)                                           AS total,
  sum(CASE WHEN m.ZISFINISHED = 1 THEN 1 ELSE 0 END) AS read
FROM ZBKLIBRARYASSET m
WHERE m.ZSERIESID IS NOT NULL AND m.ZCONTENTTYPE != 5
GROUP BY m.ZSERIESID;

The ZCONTENTTYPE != 5 predicate matters beyond this query. The container row counts as a row in the table, so any aggregate over books, totals, format breakdowns, library size, must exclude type 5 or it will overcount by one per series.

The model at a glance

The three relationships form one compact graph, all anchored on ZASSETID:

                    ┌─────────────────────┐
   highlights ──────┤                     ├────── shelves
ZAEANNOTATION       │   ZBKLIBRARYASSET   │   ZBKCOLLECTION
(separate DB,       │      (ZASSETID)     │   via junction table
 ATTACH + JOIN)     │                     │   ZBKCOLLECTIONMEMBER
                    └──────────┬──────────┘
                               │ self-join on ZSERIESID
                               │ (container row, ZCONTENTTYPE = 5)
                            series

One central entity, three patterns: a cross-database join for annotations, a junction table for collections, a self-join for series. Most questions about a reading library reduce to one of these traversals.

A documented limitation: reading sessions

The third database, BCRecentlyOpenedBooksDB, contains ZBCASSETREADINGSESSION, with ZTIMEOPENED and ZTIMECLOSED columns that look like they record reading duration. They do not.

opened                | closed               | duration
2026-06-10 17:49:29   | 2026-06-10 17:49:33  | 4 seconds
2026-05-05 14:53:33   | 2026-05-05 14:53:56  | 22 seconds

Each session spans a few seconds (an open event, not a reading span), ZTIMEUPDATED is empty, and only the most recent handful of rows are retained. Actual time-spent-reading is not persisted and cannot be reconstructed from this data. The open timestamps are valid, so they can support an opened-on-this-day signal, but not minutes-read.

Querying your own library

None of this requires special tooling. On any Mac with Books:

sqlite3 ~/Library/Containers/com.apple.iBooksX/Data/Documents/BKLibrary/BKLibrary-1-*.sqlite \
  "SELECT ZTITLE, ZAUTHOR FROM ZBKLIBRARYASSET WHERE ZISFINISHED = 1;"

From there, the rest of the model is reachable by following ZASSETID: attach the annotation database for highlights, walk ZBKCOLLECTIONMEMBER for shelves, self-join on ZSERIESID for series. The recurring practicalities are the same throughout: recognize the Core Data prefix, add 978307200 to every timestamp, treat boolean flags as nullable, and exclude ZCONTENTTYPE = 5.

Appendix: a reference implementation

To exercise the model end to end, I built ReadStats, a small macOS menu-bar app that reads these databases (read-only, via the copy-with-sidecars approach above) and renders the stats they imply: finished-per-year, currently-reading progress, the want-to-read backlog, stalled books, highlight counts and colors, series progress, and a searchable browser over every highlight.

Each view in it is, underneath, one of the queries from this document. The library catalog is ZBKLIBRARYASSET; the "most highlighted" list is the cross-database join; the backlog is the junction-table traversal; the series card is the self-join. The data model did the hard part. The app is mostly presentation on top of these relationships.

If it's useful as a worked example of mapping a Core Data SQLite schema into a typed domain model, that's the part worth borrowing.

The official disclaimer is that the whole discovery was assisted by Claude. Pretty fun stuff checking the databases and how they connect to each other and being able to re-present the information in a nice way.

What are your most liked agent skills?

Kevin Alemán — Fri, 19 Jun 2026 14:41:59 +0000

An space for sharing your go-to agent skills so everyone can use them.

My list:

Superpowers (planning & implementation)
Caveman (for reducing token usage)
Frontend Design (to help with styling)
Remember (memory)

I have one i created myself called teachme, which uses a bit of thinking to explain topics to you and then it evaluates your understanding.

Gotta Earn 'Em All: The Gym Badges of Agentic Engineering (Part 1)

Kevin Alemán — Wed, 17 Jun 2026 20:13:57 +0000

There's a guy who stands at the entrance to the Indigo Plateau and will not let you through. Level 80 Charizard? Doesn't care. Seven gym badges pinned to your jacket? Come back when it's eight. No matter what you do, he won't let you pass until you meet the prerequisites.

Kid-me thought he was the single most pointless NPC ever programmed. I wanted to go right to the action, not spending 5 hours to get all the badges. Replaying FireRed last month (the GOAT, don't @ me) I finally got what he's for. He isn't guarding the fun part. He's making sure that by the time you face the four people who can actually beat you, you've already survived the eight boring things that made you ready for them.

Which is, more or less, my entire complaint about how we're using agents right now.

Everybody wants to fight the Elite Four on day one. "I'll let the agent build the whole feature." "I'll let it refactor the repo while I grab a coffee." "I'll point Claude Code at the thing and vibe." And sometimes it works! Right up until it doesn't, and you genuinely cannot say why because there were eight gyms between you and that gate and you strolled past every one.

So here's the case, the way a Game Boy made it to me: before you're actually good with agents, there are badges to earn. Not tools to install, things you have to know. Let's go gym by gym.

Badge 1: Boulder Badge: rock before copilot

Brock. Rock type. The first gym. The place where you thought choosing charmander was a bad call (until you trained enough and it learned Metal Claw which helps a little bit).

This is the badge of knowing how to code without the agent holding your hand. The foundations.

I've said this before and I'll keep saying it until they revoke my keyboard: you cannot prompt what you don't know exists. If you don't know your project just changed a function's typings, you won't tell the agent, you won't catch it when it gets it wrong, and you'll merrily ship something that looks right and isn't. The agent didn't fail there. You showed up to the gym with no Pokémon.

You don't need to know everything. You need bedrock. Otherwise every badge after this one is built on sand and you're gonna have a bad time.

Badge 2: Cascade Badge: the agent only knows what you pour in

Water flows, context flows, you see where I'm going. An agent isn't psychic (we'll get to that gym), it knows exactly what's in its context window and nothing else. Not your repo's weird conventions. Not the thing your team decided in Slack last Tuesday. Not the landmine that lives rent-free in one senior dev's brain.

Look at these two and tell me they're getting the same result:

// what most people send
"fix the bug in the user evaluation"

// what you could be doing
"In src/users/evaluate.ts we hardcoded a company name to hit a deadline.
Now we ALSO need to exclude new users from company "bla",
WITHOUT touching how "fancy company" users get evaluated.
Here's the file, here's the test that has to stay green,
here's how we name things."

Same model. The first one is basically throwing a Poké Ball at a wall. The second one is, you know, engineering. Pour the context on purpose and everything downstream gets less cursed.

Don't make your agent drink from a puddle.

There's some cool skills that can make your agent "think" this way, but you have to think that way too, so both agent & you can work together on solving & creating.

Badge 3: Thunder Badge: fast is a trap

Here's what nobody warns you about: agents are fast. Stupid fast. Faster than you. Faster than me. Faster than anything likely. Issues that would take me a week to solve an agent can find a probable cause in minutes. And speed multiplies whatever you give it, your galaxy-brain ideas and your dumbest ones, at the exact same voltage.

I've ranted about this in open-source land: opening a PR now costs basically nothing, but reviewing one still costs a human their actual time and sanity. That gap is a denial-of-service attack wearing a trenchcoat. You tell the agent "do this for every file!!" and now there are 100 changes, some great, some radioactive, and you have to read all 100 because the agent will not tell you which is which. Congrats, you DoS'd yourself.

The badge here is learning to not grab the lightning with both hands. Small tasks. Bounded scope. One thing at a time. A fast wrong answer isn't a head start, it just got to being wrong sooner. :(

Badge 4: Rainbow Badge: it's gardening, not a vending machine

People treat agents like a vending machine: insert prompt, slot opens, finished feature falls out. Nope. It's gardening. You plant a thing, you look at the weird mutant that grew, you prune the cursed branches, you re-prompt, you prune again. Repeat until it's a plant and not a crime scene.

The first output is never the deliverable. It's a sprout. "Good, keep this shape, but the data layer is wrong, redo that part" is the actual loop. The people who look like wizards with agents aren't great prompters, they're patient gardeners who aren't precious about yeeting a bad draft into the sun.

Plant small, prune often, be responsible for what your agent produces cause that's your personal image too.

Halfway to the League

Four badges down. If you actually have these: bedrock, context, scoped speed, and the patience to garden instead of treating the agent like a vending machine, you're already ahead of most people loudly pretending to be good at this.

Learning is a journey. Enjoy it. Don't let agents & AI remove from you the better part of programming: you getting better at it.

Obviously, life is not Pokemon. You could perfectly bypass all of this and go straight into your terminal right now to get a "product". That's acceptable in some cases.

But... where's the fun in that?

You got selected for GSoC 2026, now what?

Kevin Alemán — Mon, 04 May 2026 04:35:06 +0000

So your inbox lit up yesterday with the email. The proposal worked, the interviews worked, the late-night drafts worked. Take a moment, breathe, tell your family, post the screenshot. You earned it 🎉
Now, the actual fun part begins.

GSoC is, at its core, a few months of getting paid to learn from people who have spent years figuring out how to build software that thousands (sometimes millions) of strangers depend on. Think of it as an internship, but instead of a single company, your "office" is the entire open source world, and your "coworkers" are engineers who chose to spend their free time making things better for everyone. That's a rare seat at the table. Don't waste it.

Here are a few things to keep in mind so you make the most of it.

What a mentor looks for from you

They want to mentor, not babysit.

Mentors signed up to guide you, answer the hard questions, and unblock you when the codebase fights back. What they did not sign up for is reading the README on your behalf. The heavy lifting, exploring the codebase, running it locally, breaking it, fixing it, writing code that smells like the rest of the repo, that's on you.

A good rule: if you can find the answer in 30 minutes of digging, dig. If you've dug for two hours and you're more confused than when you started, ping them.

Note 2: at Rocket.Chat, we have an internal meme called :call-the-police: that would fit perfectly above. Sadly, due to GDPR and other international laws, I cannot share above. End of the note.

Honesty is everything.

LLMs are great at giving you an answer. They're not great at giving you the answer for this specific repo, with this specific history, with that one weird workaround that's there because of a bug from 2019 nobody wants to revisit. When you step into that kind of fog, just say so. Mentors respect "I don't get why this is here" way more than a confident wrong guess. That said, don't ask for permission to breathe. There's a middle ground between "I'm stuck on every line" and "I haven't said anything in two weeks", and that's where you want to live.

Let git do some of the talking.

In a lot of open source repos, the git history is the real diary of the project. Match the style: if they squash, you squash; if they write essays in commit messages, you do too. Use commits as a steady drumbeat of progress, and save your mentor's inbox for the moments that actually need a human. Adding a translation? That's a commit. Untangling a nasty bug and finding a creative fix? That's worth a "hey, look at this" message.

What you can ask from your mentor

Treat them like human documentation.

Mentors are walking archives. They know why a function is named weirdly, which refactor everyone is afraid to touch, and that one PR from 2021 that explains everything. Tap into that, but don't drain the well. Try to find the answer yourself first, give it a responsible amount of time, and if you're still spinning, ask. The deadline is fixed, and running in circles is the most expensive thing you can do with your summer.

Ask about the politics the proposal couldn't see.

When you wrote the proposal, you were looking at the project from the outside. Now you're inside, and you'll start spotting things: tech debt, weird coupling, decisions that look wrong until someone explains they're load-bearing. Bring those up. Sometimes the answer will be "yes, let's fix it as part of your work." Other times it'll be "leave it, that rabbit hole eats summers." Both are useful answers, and only your mentor can give them to you.

How to deliver on the proposal you already submitted

The proposal is the map, not the territory.

You can't redraw it: the timeline, the deliverables, the headline goals are pretty much locked. But there's plenty of room inside the lines: code style, data shapes, security choices, edge cases, testing strategy. Talk those out with your mentor early. The earlier the better, because rework in week 10 hurts a lot more than rework in week 2.

Once you've aligned, write a plan.

Break the proposal into weekly chunks, with a rough idea of what "done" looks like for each one. Then, and this is the important part, don't die by the plan. Plans that are too tight have no room to absorb the inevitable: a flu, a flaky test, a rabbit hole, that one dependency that decides to deprecate itself the week you need it. If something can go wrong, it will go wrong. Plan for it.

Murphy's law is an adage or epigram that is typically stated as: "Anything that can go wrong will go wrong."

View on Wikipedia>

When to use AI (and when to put your hands on the keyboard)

Use AI to plan, not to know.

AI is genuinely great for getting your bearings in a new codebase: "what does this module do", "where is X handled", "give me a tour of this folder". The trap is that it'll happily give you confident answers that feel like understanding without actually being understanding. Always review the plan it gives you. Always question its assumptions. At the end of the summer, nobody is evaluating the LLM. They're evaluating you.

Don't let AI eat your learning.

This is the part I want you to take most seriously. GSoC is one of the safest spaces you'll ever get to make mistakes: you have a mentor, a stipend, and explicit permission to be a beginner. If you outsource the thinking to an LLM, you're trading the most valuable thing about the program for some saved keystrokes. Especially when it comes to understanding issues: sit with the problem first. Read the code. Form your own theory. Then maybe ask the AI for a second opinion. AI already "knows" a lot of stuff. The whole point of the summer is: what do you know?

Balance check: we don't want you to feel we (or I) hate AI. AI is really cool and I'm very happy on using it. But as prof. Oak liked to say: "There's a place and time for everything". AI is cool, but the human using it is cooler.

Maintainers can smell it.

I've reviewed enough PRs to tell you this isn't a cute claim: it's true. Code that's 100% AI and 0% human reads differently. The variable names are too generic, the comments explain things nobody would explain, the solution is technically correct but doesn't fit the shape of the codebase, the PR title and/or the code make no sense. Mentors will spot it. And we, the mentors, want you to learn, that's the whole point of GSoC. We want more maintainers for the future. You can be one of them if you use this opportunity.

Wrapping up

You'll quickly realize getting selected was the easiest part. This summer is the real thing. Drive your own work, ask the smart questions, ship the small stuff, keep AI as a tool and not as a crutch and you'll come out the other side a much better engineer than the one who opened that email yesterday.

See you at the final eval 👋

Got featured :noice:

Kevin Alemán — Tue, 10 Mar 2026 16:45:59 +0000

Jess Lee for The DEV Team

Mar 10

🙌🏽

Kevin Alemán — Sun, 08 Mar 2026 18:51:54 +0000

Kevin Alemán

Mar 4

In the AI Era, Code Is Cheap. Reputation Isn’t.

#ai #opensource #programming #software

6 min read

In the AI Era, Code Is Cheap. Reputation Isn’t.

Kevin Alemán — Wed, 04 Mar 2026 21:01:29 +0000

In the era of AI it's easier than ever to be an Open Source contributor!

But, at the same time, and quite paradoxically, it's harder than ever.

Why? Because it's now mechanically easier, but reputationally harder

Previously, you competed against other incredibly smart volunteers, or maybe against employed developers that contributed their expertise and free time to open source, or against newcomers. Now, you compete against all of that and an army of AI agents generating pull requests, issues, refactors and vulnerability reports faster than what any human can do.

It's pretty tempting. Using an LLM can reduce significantly the cognitive work you have to do to understand a codebase, and even to produce a valuable change request. Things that were previously "very hard" to do are now a few prompts away, and that lowered the entry barrier for contributions, which is great! But also created a massive increase in volume, which is flooding repositories.

What's the problem?
Maintainer capacity did not increase
Review cost did not decrease

These two truths have already led maintainer to resort to drastic measures, like what happened with curl:

Death by a thousand slops | daniel.haxx.se

daniel.haxx.se

So, how do you become a valuable Open Source contributor in the era of infinite code generation? Here are a few tips learned from dealing with a large volume of contributions:

1. Think. Then think again

AI can produce great code, but it can also produce the worst code ever seen by the humanity. This depends a lot on:

The prompt that you use
The quality of the LLM
The context being shared

And the most important one:

Your own coding abilities.

Why do you need to know how to code before using LLMs to contribute to open source?

Well, because an LLM cannot know everything.
For example, we had a PR that attempted to change this:

        } catch (error) {
            console.error('Some error:', error);
        }

After

        } catch (error) {
            logger.error('Some error:', error);
        }

You would say: that is a valid change, we want to use logger instead of console! What's the problem?

The problem was that the LLM didn't know (and didn't check, cause it wasn't asked to) that we recently changed the typings on our logger instances, rendering the change invalid.

What a valid change would have looked like:

        } catch (err) {
            logger.error({ msg: 'Some error', err });
        }

But, the LLM didn't know this, and it would have required quite some context for it to know. Good LLMs (Claude, Codex, etc) would have caught, but others would not, unless you asked them. How would you ask something that you didn't know? There's where your coding abilities enter into play.

Here's the key point: You cannot prompt what you don't know exists

Someone that wants to be a contributor doesn't trust blindly on what the LLM produces. Knows how to use the tooling (typecheck, in this case) to catch those issues, reads the code to understand current conventions, caveats, etc.
For this programmers, LLMs become a powerful tool, cause it helps you with the mechanical task of coding and gives you enough time to think.

This also protects your reputation. If maintainers see a pattern of low-signal PRs from you, they’ll eventually stop reviewing them. Or worse.

LLMs make contribution faster, but they don’t replace your brain unless you let them.

2. Respect volume. Review is not free.

You are happy. We're also happy that you want to contribute to open source. It's a noble endeavor and it's something that helps the repository to be safer & you to be better. It's a win-win!

But, maintainers have:

Limited capacity.
Limited time.
Limited patience.

We understand, you are happy you created your new PR, and we understand the joy in you of doing that. We've all being there. You want, for sure, your PR to be merged so you can say with honor: "I contributed to X!"

But, be reasonable:

The cost of opening a PR is now near zero.
The cost of reviewing it is not.

This asymmetry is the real tension of the AI era.

If you:

comment “please review” repeatedly,
ping maintainers aggressively,
demand merging timelines,

You’re increasing the cognitive cost of your contribution. Even if your PR is valid.

And here’s the harsh truth:

Maintainers are human.

If interacting with you feels expensive, they may subconsciously deprioritize your work. That means fewer reviews, fewer merges, fewer release notes mentions.

This is specially important when you use LLMs or Agents as they are fast, way faster than humans, so you could end up doing 100 PRs that you think are valid, and maybe they are! But if the maintainers don't have the capacity to review them all, they just won't.

That's the definition of a DoS (Denial of Service): you send more requests than what the server (maintainers) can process.

3. Quality that doesn't cut corners (pls don't sue me Wendy's)

Maintainer capacity is low. We closed around 700 issues (stale, invalid, fixed) in the past month, but at the same time, we received 300 new issues. Some of those issues were valid, some of them were not. The problem is we don't know beforehand, we have to check them all. You cannot trust an LLM to confirm if something is slop... cause the check may be slop too!

Related link, curl fighting against AI slop vulnerability reports:

HackerOne Curl report

As you see, maintainers won't be happy if you waste their time, cause they have stuff to do. The link above, as well as this beautiful list

have something in common: they look legit, until they don't. However, for realising something is slop you have to check manually, and that is time/effort wasted.

So you have to be human, respect the times maintainers have and respect their work. How you do that? Helping the maintainers reduce the cost of reviewing your code:

Before submitting:

Did you reproduce the issue yourself?
Did you run CI locally?
Did you include screenshots for UI changes?
Did you provide benchmarks for performance claims?
Did you include a PoC for security reports?
Did you check if a feature request already exists?

If you claim a performance improvement, show numbers.
If you fix a bug, explain the root cause.
If you propose a feature, ask first.

High quality contributions get reviewed faster.
Low signal contributions accumulate.

In the AI era, reputation compounds. If maintainers can trust you, your PRs will be reviewed faster, and you will feel happier. Win-win!

4. Bundle trivial changes.

Typos happen. Smol mistakes happen. For example

Before:

        if (!sub) {
            throw new Error('subsciption not found');
        }

After

        if (!sub) {
            throw new Error('subscription not found');
        }

Do you spot the bug? Yep, a missing r on subscription. The contribution is valid, yes, we want to write correct words in english.

Does it deserve a PR? Not by itself, maybe if you combine a few more. Think if you find 10 of those misspellings. What's easier for maintainers? 1 PR with 10 changes or 10 PRs with 1 change? Hehe.

If you were the maintainer, what would you prefer?

Every PR has overhead: CI runs, notifications, review time, merge time, mental context switch, etc. Reduce the overhead by batching trivial work.

AI can find an enormous list of fixes like this in a codebase, and if you use an agent like Claude or Clawd you can tell "Hey for each issue create a PR" and then become the most hated contributor on the project :(

Don't do that. Please. Be mindful. Be human.

LLMs are fun, but human work is better.

We're on the AI era, we cannot fight AIs anymore, they're here to stay. What we can fight is how we use them.

For GSoC for example, we value human contributions. That's the point of the program: more humans converting to open source contributors!

We need new generations of maintainers, of smart people that will use LLMs wisely. You can do amazing stuff with them if you use them properly, but nothing will replace your ability to do amazing stuff as a human. You have to remember that.

It's easier to contribute, but harder to stand out from the crowd.
Reputation matters.
Trust is earned.
You build it by doing good work.

As a final note, this is pretty much personal experience. Some projects may have different rules. Some may like to receive 1000 PRs a day (?) idk.

But, the main point is: AI is not human, but maintainers and contributors are. So remember that.

Welcome to Open Source!

If u want to read more:

AI is destroying Open Source, and it's not even good yet - Jeff Geerling

Over the weekend Ars Technica retracted an article because the AI a writer used hallucinated quotes from an open source library maintainer. The irony here is the maintainer in question, Scott Shambaugh, was harassed by someone's AI agent over not merging its AI slop code. It's likely the bot was running through someone's local 'agentic AI' instance (likely using OpenClaw). The guy who built OpenClaw was just hired by OpenAI to "work on bringing agents to everyone." You'll have to forgive me if I'm not enthusastic about that.

jeffgeerling.com

You're doing great, and you need to hear that :)

Kevin Alemán — Wed, 15 Sep 2021 16:09:03 +0000

I'm not the kind of person that likes to be "thanked" for something. I like to do the things, and that's it. And later I realized it was not only me who felt this way. But, is receiving recognition something reserved for super special situations?

Everyone needs to be "praised" for doing a great work

Being praised releases dopamine, that's why you feel happy when someone recognizes your work and says that it's good. Everyone likes that feeling of "doing something amazing" by receiving a simple "thanks for helping me". But, it doesn't stop there.

Your motivation is also increased. It's important to note that everyone has a different set of motivators, so what may work for someone probably won't have the same effect for others. But there are some common motivators in a workplace, like the compensation. Receiving a considerable wage and a good compensation plan on your company may motivate you to work better. Same as having a clean workstation, or having a good team composed of capable people. Recognition is also a key motivator, that means, surprisingly, that people feel good when they're recognized :)

However, as any other dopamine-releaser, the effect of recognition is transient, and, it may decrese the effect over time when it's done too much. So, recognition should be given timely.

Timely recognition

So, how do we achieve a recognition scheme that's not sporadic but is not rare at the same time? Balance, as always, is the key.

This is more an HR topic, probably at your company there's a lot of people trying to fix this same issue, because recognition is not as easy as it may look. Fairness plays a really important role. What if another employee who does the same thing I do receives recognition every week, but I receive it every year? Then, recognition becomes a problem and a demotivator, so it's important to watch out how recognition will be conducted.

But, let's return to the frequency. From this BI Article, a weekly recognition scheme is good. Probably you don't need it to be too frequent. Think for example, on sprints. If your sprints are 2 weeks long, why not dedicating some time at the end to thank your colleagues for their work?

The same article says that this type of recognition helps the employee to be engaged, and trying to get that recognition again, because people like that. Try to avoid recognizing your employees just with the normal performance review cycle, because that may be too late.

Again, if your colleague did something really good for you or the team, don't wait to say thanks. Recognition has a "shelf life", that means, it can expire if not used at the right moment!

So, key points for timely recognition:

Do it before it expires :)
Don't wait to normal performance review cycles to recognize people
Be fair

How to create a recognition culture?

Make it easy
Your team should feel that it's easy to give recognition. If people find a lot of requirements or an extremely formal process for doing so, they won't do it.
Be specific
Saying "thanks" is good, but it's even better when you know the reason for that. So saying "thanks for helping me with the last presentation" would be much more valuable than just saying thanks, because that means you're recognizing a specific effort, and not just saying a canned response.
Connect the dots :)
Relate the recognition with your company's values. This makes easier for your team to know how they're contributing to the company's objectives and culture, and that creates a strong culture :)
Make it for everyone
Avoid having only managers giving recognition. Foster p2p recognition, since that'll create bounds between your team.

(Key points taken from this article

So, as conclusion, thanks for what you're doing to improve the community :) and thanks for sharing your knowledge with the rest of the people using this platform.

Now, go there and recognize people for what they're doing :)