DEV Community: Kevin Alemán

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 Plugin | Claude by Anthropic

Claude learns brainstorming, subagent development with code review, debugging, TDD, and skill authoring through Superpowers.. Install this plugin to extend your workflow.

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-223'); 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 :)

The beauty of Streams in Node

Kevin Alemán — Fri, 02 Oct 2020 21:06:17 +0000

Probably you have heard of them, probably you don't. But they have been around for a while. We're talking about streams, an interesting and often ignored functionality of Node.JS.

What are streams?

To make things easier, we will define a stream as a sequence of data that flows freely. Think of streams like rivers. Rivers flow from one point to another in a constant way. The receiver doesn't know when the river will stop flowing but it's always there for receiving more water.

In Node, streams are very similar. They are a constant sequence of data. They flow from one point (emitter) to another (receiver).

The receiver can decide if it wants to receive data or not. Also it decides what to do with the data received. It can ignore the data, pipe it to another receiver, parse it before receiving...

Why are streams useful?

This is a really good question. If you have lived without streams your whole life, you will think that you don't need them. And, depending on your use case, this could be true.

But the reality is that we need to use streams for some operations that otherwise will kill us. Let's put an example

Dealing with files

Let's say we want to create a compressed copy of a file on our disk with a Node application. Usually, we will end up with something like this:

fs.readFile(file, (err, buffer) => {
  zlib.gzip(buffer, (err, buffer) => {
    fs.writeFile(file + '.gz', buffer, err => {
      console.log('Done!!');
    });
  });
});

Imports removed for brevity

Here, we're doing 4 things:

We're reading the entire file and saving the data to a variable called buffer
We're using the zlib.gzip to compress the file into a gzip. We're passing the buffer to the function call. This will return a new compressed buffer
We write the compressed buffer to a new location
A console.log indicating that the operation finished

Well, this works. What's the problem with this approach? You may be wondering. Well, look again at the first 2 steps. In this approach, we're reading the whole file before starting to process it. Additionally, we're storing the contents of that file in memory. This is not a problem if the file size is in MB. But, if the file size is in the order of GB? Hundreds of GB? Will your computer have all that RAM available to hold the file in it? Probably no.

So, this approach, even when enough for more simple tasks, represents a problem when we're looking for performance and scalability, or simply we want to support larger files.

The problem can be solved by using streams. Let's see how:

fs.createReadStream(file)
  .pipe(zlib.createGzip())
  .pipe(fs.createWriteStream(file + '.gz'))
  .on('finish', () => console.log('wooh!'));

We're doing some things different here:

We're creating a read stream. This will return us chunks of the file until it reaches the end.
We're piping the chunks to zlib for compression. What's important here is that we are not waiting for the whole file to be read before starting the compression.
We're creating a write stream in which we're passing chunks of data so Node can write them to the file.
After all, we listen for the finish event, which will be triggered when there's nothing more to do.

There's a vast set of details & quirks & functions related to streams which will be covered in other blog posts.

Hope you liked it!

Building a new feature: talks preview

Kevin Alemán — Fri, 11 Sep 2020 06:59:14 +0000

I'm a backend developer, so most of the time I'm doing backend things. I feel stressed most of the time when I need to do something at the front.

Then, I started to build my own personal site. And it was great! It's a blog site located temporarily at Netlify where you can contact me, read what I wrote, share my content with a suggested tweet, and now you can see the talks I've given in my career.

The talks are mostly about basic topics, one of them is in progress yet, but I wanted to showcase that I made them. And this was when the trouble begins

How?

The first thing was to define what I wanted: I wanted to showcase my presentations. This was easy (in my mind), but, it wasn't easy in real life.

To give you more context, I store all my presentations in Google Drive, so I can work on them wherever I go. This makes things easier for working on them, but a little bit hard if you want to show them offline.

Why? Because first, you have to download the file. This is a no-brain task with a UI, just right-click and download. GG. The task gets more complex when you want your code to perform that process. So I walked a lonely road, the only one that I have ever known: looking for someone who tried the same and succeeds.

I found multiple Gatsby plugins by just typing drive or google drive into the search box. I tried every single one, with the hope of finding what I wanted. Here's a list of the highlighted ones if you are trying to do something similar:

gatsby-source-google-docs

The problem: the use case I had in mind was very different from what the library did

gatsby-plugin-drive

The problem: it only allowed me to download DOC files (not presentations, which was what I wanted)

gatsby-source-drive

The problem: it didn't work. Maybe I misconfigured something or so.

gatsby-plugin-docs-sheets

The problem: it only allowed me to download Sheets. I'm pretty sure this was based on gatsby-plugin-drive)

So, since no plugin was able to fulfill my needs, I had to make a difficult decision:

Give up on my feature
Create my own plugin

I took the second, and this plugin was the result: Gatsby-plugin-googledrive

The entire plugin was based on a single idea: given a Google Drive's folderID, download all files from the folder, and traverse the subfolders recursively to create the same structure on your selected destination. And download the files for each folder.

The technical details can be found at the GitHub of the project and, it's open-source, so if you want to build something around it feel free to do so.

How? Part 2

After creating my plugin, I "plugged" it and the download started. I finally had the files on my local, and this was one step closer to my goal.

I had the PDFs on my local, now, I wanted to do 3 things:

Get the URL from the PDF in my filesystem (and application!)
Get the first page of the PDF (the "cover page")
Convert that page to an image, and show it on a nice grid

Soo, I needed 3 things:

One way to get the PDF from my filesystem
One way to read the PDF
One way to convert the read PDF into images

For the first item, since I'm using Gatsby, I used the gatsby-source-filesystem to read my folder and get the actual asset URL pointing to my file. It was really easy, just added this to my gatsby-config.js file:

    {
      resolve: "gatsby-source-filesystem",
      options: {
        name: "talks",
        path: "${__dirname}/src/talks/",
      },
    }

And that's it! Then, to query my filesystem and get the nodes with data, some graphql was needed:

  query {
    allFile (filter: {sourceInstanceName: { eq: "talks" } }) {
      edges {
        node {
          name
          publicURL
        }
      }
    }
  }

That query will do 2 things:

Get all the files under the path of the instance name called talks (which is the name property you pass to the plugin definition)
For each node aka file, get its name and publicURL (which is the URL that the asset will have after the building)

For the second item, I had to do some research. After some looking, I finally found PDF.JS which is like the standard for managing PDFs in JavaScript. It was written by Mozilla and has a ton of useful functions. I just used the basic API to get my feature working in a few LoC.

PDFJS.getDocument(talk.publicURL).promise.then((pdf) => {
      pdf.getPage(1).then((page) => {
          // some code goes here
      })
})

The introduction to the library in its GitHub page was simple, maybe too small for my taste, but it worked. With this, the only thing left was to find a way to convert the PDF page's data into an actual image.

I found a pretty nice approach to accomplish that. It worked like this:

Read the PDF page
Scale the page's width and height (by using the viewport of the page)
Create a <canvas> element
Set the canvas context to 2d (since we'll draw an image)
Set the scaled page as the new data context for the canvas

The full code was linked in this StackOverflow's answer which even had an example of how it worked. Nice.

With all of that in place, the final result:

Hope you liked the article, feel free to also visit this post on my own website

Algos in real life: binary search

Kevin Alemán — Fri, 04 Sep 2020 20:14:12 +0000

You probably know about algorithms. You probably don't. So here's a basic definition: an algorithm is a chain of steps for moving from A to B.

If you want to make a sandwich, you probably have an algorithm for that. Mine is:

Get the ingredients
Separate bread and put it on a plate
Put some dressing on both halves
Put lettuce, tomatoes, pickles (if any) on one half
Put ham, cheese, ham again on one half
Add extra things (this is, probably whatever I can find that fits my sandwich)
Put the empty half over the other ingredients
Eat

Whatever your process is, the point is you use an algorithm for that.

Algos are really useful, in programming and real life. Here, I'll show you an example of how I used one of those algos to make my life (and work) easier.

The task

Suppose that you were assigned to solve an issue at work. Depending on the kind of issue this may be easy peasy lemon squeezy or you can end stressed depressed lemon zest.
The issue in this example is a simple one: a function was working at some time in the past, but now it's not. Easy.

You fix the function, upload your changes, and create a merge request. Everything fine at this point.

Then, someone from above asks the hard question: "Hey, this worked in the past, could you tell me when it stopped working?". If like mine, your project has a ton of commits, then you'll have fun, more if your commit history looks like this:

The solution

You have 3 options here:

Cry in a corner
Traverse all your commits until you find one where it was working
Do something good with the knowledge you have

Ok, after doing the first we can start thinking on a real solution. And here's where algorithms come handy. Let's remember one of them!

The binary search algo, or the principle of divide and conquer.

You may remember that algorithm from a class, a course, some reading, or any other place. In case you haven't, I'll leave a brief explanation here:

The main idea of this algorithm is to, given a sorted list and a value to find as inputs, traverse the list to find the value you're looking for.

The main point of difference between this and other search algos is how the list is traversed.

In traditional searching, you go from the start until the end (in the worst case) to find what you're looking for. If you reach the end and you haven't found the value, then it's not there. Something like this:

In a binary search, however, you "divide" the list in halves, then compare the middle value with what you're looking for. If the value is greater, then you repeat the process in the left half, otherwise you use the right half. You repeat this until you cannot divide your input list anymore. Something like this:

To use a binary search, you just have to follow some rules:

Your list must be sorted
Your list must be sorted
Your list must be sorted

Ok. You got this, the list must be sorted. Let's continue with the solution!

The solution (part 2)

Since our commit history is sorted (by the date of the commit) we can perform a binary search on the commit history!

I selected some old commit (like 20 days before) as my start point and my current commit as the last item.
I, then, selected the middle one (this was made visually) and checkouted to that commit.

Was functionality working? Yes? Select a more recent one! Else, use an older one.

You know how the story ends. I was able to verify the whole commit history in like 20 minutes, when it may have taken 2 hours due to the number of commits in the pool.

Moral: if you know how to do something fast, do it! And, algos are also useful in real life!

Hope you liked this history, and let me know if it helped you! Thanks for reading 🎉

DEV Community: Kevin Alemán

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

Badge 5: Soul Badge: learn to taste poison

Badge 6: Marsh Badge: it's not telepathy

Superpowers Plugin | Claude by Anthropic

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

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

DORA | Accelerate State of DevOps Report 2024

Eight badges. Now what?

The Apple Books data model

Storage layout

Core Data conventions

Reading the files safely

The central entity: ZBKLIBRARYASSET

The relationships

1. Highlights — a cross-database relationship

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

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

The model at a glance

A documented limitation: reading sessions

Querying your own library

Appendix: a reference implementation

What are your most liked agent skills?

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

Badge 1: Boulder Badge: rock before copilot

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

Badge 3: Thunder Badge: fast is a trap

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

Halfway to the League

You got selected for GSoC 2026, now what?

What a mentor looks for from you

They want to mentor, not babysit.

Honesty is everything.

Let git do some of the talking.

What you can ask from your mentor

Treat them like human documentation.

Ask about the politics the proposal couldn't see.

How to deliver on the proposal you already submitted

The proposal is the map, not the territory.

Once you've aligned, write a plan.

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

Use AI to plan, not to know.

Don't let AI eat your learning.

Maintainers can smell it.

Wrapping up

Got featured :noice:

Top 7 Featured DEV Posts of the Week

🙌🏽

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

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

Death by a thousand slops | daniel.haxx.se

1. Think. Then think again

2. Respect volume. Review is not free.

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

4. Bundle trivial changes.

LLMs are fun, but human work is better.

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

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

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

Timely recognition

How to create a recognition culture?

The beauty of Streams in Node

What are streams?

Why are streams useful?

Dealing with files

Building a new feature: talks preview

How?

How? Part 2

Algos in real life: binary search

The task

The solution

The binary search algo, or the principle of divide and conquer.

The solution (part 2)