DEV Community: 𝗝𝗼𝗵𝗻

The AI Code Review Checklist I Use Before Merging Any TypeScript PR

𝗝𝗼𝗵𝗻 — Thu, 30 Apr 2026 10:40:00 +0000

AI can write code quickly.

That is no longer the interesting part.

The interesting part is what happens after the code is generated.

Because in real projects, the bottleneck is rarely “how do we get code faster?”
It is usually:

Is this correct?
Does it match the architecture?
Does it handle edge cases?
Is it safe to merge?
Can someone else maintain it next month?

That is why I stopped treating AI output like finished code.

Now I treat it like a draft that needs a reliable review system.

This is the checklist I use before I merge any AI-generated TypeScript PR.

Not a theoretical checklist.
A practical one.

1. Can I explain the change in one sentence?

Before I look at the code, I force myself to summarize the PR in one sentence.

For example:

“This change validates uploaded image metadata before saving records to the database.”

If I cannot describe the change clearly, one of two things is probably true:

the PR is doing too much
the code is hiding the real intent

AI often produces code that looks organized while actually mixing multiple concerns.

If the purpose is fuzzy, I stop there and split the change.

2. Does the code match the requested scope?

AI loves to be helpful.

Sometimes too helpful.

It will often:

rename unrelated variables
refactor nearby code
introduce “small improvements”
create utility functions nobody asked for
solve adjacent problems

That makes review harder.

So one of my first checks is simple:

Did the model change only what needed to change?

If a PR was supposed to fix one validation bug but now touches eight files, I get suspicious immediately.

A good AI-generated PR is usually narrower than you think.

3. Are the boundaries explicit?

For TypeScript projects, this is one of the biggest signals of quality.

I look for clear boundaries:

input types
output types
domain models
DTOs
API contracts
validation layers

AI-generated code is much easier to trust when the edges are visible.

Bad sign:

async function saveUser(data: any) {
  // ...
}

Better:

interface CreateUserInput {
  email: string;
  displayName: string;
}

interface CreateUserResult {
  id: string;
  email: string;
  displayName: string;
}

async function saveUser(data: CreateUserInput): Promise<CreateUserResult> {
  // ...
}

If the AI patch adds logic without tightening the contract, I usually improve the boundary before I approve the implementation.

4. Did the AI generate code, or did it generate a new abstraction?

This matters a lot.

Sometimes AI gives you useful implementation.
Sometimes it gives you a brand new architecture you did not ask for.

Watch for:

extra layers
generic helpers
“reusable” wrappers
configuration systems
class hierarchies for simple logic
abstraction before repetition actually exists

A useful question here is:

Would I still create this abstraction if a human teammate had not suggested it?

If the answer is no, I remove it.

AI-generated code often becomes bloated not because it is broken, but because it is too eager to generalize.

5. Is there a test for the thing that actually changed?

I do not just ask, “Are there tests?”

I ask:

Is there a test for the exact behavior this PR claims to fix or add?

That means:

one test for the happy path
one test for the expected failure mode
one test for the edge case that is easiest to miss

If the PR fixes a parsing bug, I want a parsing test.
If it changes authorization logic, I want an authorization test.
If it adds fallback behavior, I want a test that proves the fallback works.

AI often writes tests that mirror the implementation too closely.

So I look for tests that verify behavior, not just structure.

6. Does the code fail safely?

A surprising amount of AI-generated code handles success better than failure.

So I explicitly review:

missing values
invalid input
timeouts
third-party failures
null and undefined cases
partial success scenarios
retries
logging
user-facing error messages

I ask myself:

What happens if this dependency is down?
What happens if the payload shape changes?
What happens if this field is missing?
What happens if the operation succeeds halfway?

If the answer is “the app probably throws something weird,” the PR is not ready.

7. Are runtime checks present at the system edges?

TypeScript is great, but it does not validate runtime data by itself.

So any AI-generated code that touches:

request bodies
query parameters
local storage
database results
webhooks
environment variables
third-party APIs

should make me ask:

Where is the runtime validation?

Types help inside the codebase.
Validation protects the boundary.

For example:

import { z } from "zod";

const CreatePostSchema = z.object({
  title: z.string().min(1),
  body: z.string().min(1),
  tags: z.array(z.string()).default([]),
});

type CreatePostInput = z.infer<typeof CreatePostSchema>;

function parseCreatePostInput(input: unknown): CreatePostInput {
  return CreatePostSchema.parse(input);
}

If AI writes strongly typed code without validating incoming data, it creates a false sense of safety.

8. Are names better after the change — or worse?

AI can produce valid code with terrible naming.

And bad names are expensive because they survive code review surprisingly often.

So I check:

function names
variable names
type names
file names
booleans
enum values
error messages

I want names that reflect the domain, not the implementation trick.

Bad:

const dataProcessorManager = createHandler();

Better:

const invoiceRetryScheduler = createRetryScheduler();

When naming gets vague, maintainability drops fast.

9. Does the PR introduce duplicate logic?

AI often rewrites something that already exists somewhere else in the codebase.

That creates:

near-duplicate validators
inconsistent helpers
slightly different parsing functions
multiple ways to do the same thing

So I always scan for duplication before approving.

My rule is simple:

if the logic already exists, reuse it
if the existing abstraction is bad, improve it
do not allow AI to create parallel versions of the same idea

Duplicate code is especially dangerous when it looks clean.
It feels harmless at first and becomes expensive later.

10. Would I be comfortable debugging this at 2 AM?

This is one of my favorite review questions.

Because code can be technically correct and still be operationally terrible.

I look for:

meaningful logs
useful error messages
predictable branching
obvious control flow
easy-to-trace data transformations
no “magic” hidden in helpers

If production breaks, will this code help the next person understand what happened?

Or will it force them to reverse-engineer AI-generated cleverness under pressure?

If debugging would be painful, I simplify the code before merge.

11. Is the security model still intact?

Any AI-generated PR that touches:

auth
permissions
tokens
cookies
headers
uploads
database access
redirects
HTML rendering
shell commands

gets a slower review.

I specifically check:

authorization, not just authentication
input handling
secret leakage
unsafe defaults
overly broad permissions
accidental exposure of internal fields
client/server boundary mistakes

I do not trust “looks secure.”

I want the security assumptions to be obvious in the code.

12. Can I roll this back easily?

This final check is underrated.

Even a good change can fail in production.

So before merging I ask:

is the change isolated?
is it behind a flag?
can it be reverted cleanly?
does it change data shape or persistence behavior?
does it create migration risk?
does it depend on coordinated deployment?

AI makes it easy to create larger patches than necessary.
Rollback thinking forces the patch back into a safer shape.

My quick merge rubric

If I need a fast decision, I use this simple rubric.

I merge when:

the scope is narrow
the intent is obvious
the boundaries are typed
runtime input is validated
tests prove the claimed behavior
failure paths are handled
naming is clear
security assumptions are visible
rollback is simple

I request changes when:

the PR does more than requested
the code adds unnecessary abstractions
tests are shallow
boundary validation is missing
names are vague
duplicate logic appears
debugging would be painful
the operational or security story is unclear

Final thought

AI can absolutely make teams faster.

But speed only matters if the output is reviewable, understandable, and safe to ship.

That is why I do not ask:

“Did AI write this?”

I ask:

“Would I still approve this if I had to own it in production?”

That single question has improved my reviews more than any tool setting.

If you are using AI heavily in your TypeScript workflow, build a checklist like this one.

It does not have to be identical.

It just has to be consistent.

Because the real productivity gain is not generated code.

It is generated code that survives review without creating future pain.

I recommend this!

𝗝𝗼𝗵𝗻 — Tue, 28 Apr 2026 16:37:34 +0000

Ready-to-use markdown template

Giorgi Kobaidze

Apr 26

15 Essential Sections Every README Needs: Give Your Project What It Deserves

#documentation #opensource #tutorial #development

153

Comments 80

11 min read

How I Started Learning Kotlin by Building a Real Android App

𝗝𝗼𝗵𝗻 — Wed, 22 Apr 2026 09:20:00 +0000

For a long time, Kotlin was one of those technologies I kept meaning to learn “properly.”

You probably know the feeling.

You read a few examples.

You understand the syntax.

You save a few tutorials.

You tell yourself you’ll build something with it “soon.”

And then nothing happens.

That was me for a while.

The problem wasn’t that Kotlin looked hard.

The problem was that learning it in isolation felt abstract.

I could read about:

null safety,
data classes,
coroutines,
when,
extension functions,

but none of it really stuck until I had a reason to use it inside a real Android app.

That’s when things changed.

Instead of trying to “finish a Kotlin course,” I decided to learn Kotlin by building something real — small enough to complete, but real enough to force me to understand how Android development actually works.

This post is about what that approach taught me, what slowed me down, and what I’d focus on first if I started learning Kotlin again today.

Why I chose to learn Kotlin by building instead of studying longer

At some point I realized I was consuming too much “learning material” and not enough actual friction.

And friction is where real learning starts.

It is easy to feel productive when you are:

reading docs,
watching tutorials,
highlighting syntax,
copying code examples.

But you don’t really understand a language until you hit questions like:

How should I structure this screen?
Where should this logic live?
Why is this nullable?
Why does this state not update the way I expected?
What is the most Kotlin-like way to write this instead of just translating Java or JavaScript habits?

Building an app forces those questions to happen naturally.

It also gives you a much better feedback loop:

write code,
break something,
fix it,
understand one concept more deeply,
repeat.

That loop taught me more than another week of passive learning would have.

The kind of app I built

I did not start with a big idea.

I didn’t try to build:

a full social app,
an e-commerce platform,
a chat system,
or a feature-packed productivity tool.

That would have been a mistake.

Instead, I picked something small and realistic:
a simple Android app with a few clear screens, local state, user input, and enough structure to feel like a real product.

That mattered a lot.

A good beginner project should be:

small enough to finish,
useful enough to stay motivating,
and complex enough to teach real patterns.

The goal is not to impress people with scope.

The goal is to create a project that forces you to use:

Kotlin syntax in real conditions,
Android UI structure,
state handling,
user interactions,
navigation,
and a bit of architecture.

That’s where the language starts making sense.

What helped me most when learning Kotlin

A few things made a huge difference early on.

1. Writing Kotlin every day, even in small amounts

I learned very quickly that consistency mattered more than long study sessions.

A focused 30–45 minutes of building something real helped me much more than occasionally spending 4 hours jumping between tutorials.

Kotlin started to feel natural only after repeated exposure:

writing functions,
handling nullable values,
creating data models,
wiring UI interactions,
refactoring small pieces of code.

At first, even simple things felt slower than they should.

But that’s normal.

The important part was not speed.

It was repetition.

2. Accepting that Kotlin is not just “better Java”

This was one of the biggest mental shifts.

If you come from another language, especially something like Java, JavaScript, or TypeScript, it is tempting to treat Kotlin as “the same thing with nicer syntax.”

That mindset slows you down.

Kotlin becomes much more enjoyable when you stop translating your old habits directly and start asking:

What is the idiomatic Kotlin way to do this?
Why does this language encourage immutability here?
Why is null handling so explicit?
Why do data classes feel so natural in app development?

The more I leaned into Kotlin as its own language, the easier it became to write cleaner code.

3. Building features instead of collecting concepts

At the beginning, I thought I needed to “learn coroutines,” “learn data classes,” or “learn sealed classes” one by one.

That was not the best approach for me.

What worked better was learning those things inside real features.

For example:

user input taught me about state,
screen transitions taught me about navigation,
modeling items taught me about data classes,
error handling taught me about nullability,
asynchronous work pushed me toward coroutines.

That approach made the concepts feel useful immediately.

And useful concepts are easier to remember than isolated definitions.

What confused me the most at first

Learning Kotlin through a real Android project was helpful — but not frictionless.

A few things definitely slowed me down.

1. Null safety felt great… until I had to actually design around it

At first, null safety looked like one of Kotlin’s cleanest features.

And it is.

But it also forced me to become more deliberate.

Instead of casually passing values around and “handling it later,” I had to think earlier about:

what can actually be null,
what should be required,
what should have a default value,
and where I was making assumptions.

That was frustrating at first because it exposed weak decisions immediately.

But looking back, that was a good thing.

Kotlin was not making development harder.

It was making sloppy assumptions harder.

2. Android structure is part of the learning curve, not just Kotlin

This is important.

When you learn Kotlin for Android, you are not learning just one thing.

You are learning at least three layers at once:

Kotlin itself,
Android concepts,
and your chosen UI / architecture approach.

That means confusion is not always caused by the language.

Sometimes the real question is:

Is this a Kotlin issue?
an Android lifecycle issue?
a UI state issue?
a project structure issue?

Once I understood that, I stopped blaming Kotlin for every confusing moment.

A lot of beginner frustration actually comes from trying to learn the whole Android stack at once.

3. There is a difference between “it works” and “this is clean”

One of the biggest lessons was realizing how easy it is to build something that works… and how much harder it is to build something that still feels clean after the third or fourth feature.

Early in the project, I often wrote code like this:

directly inside the screen,
with too much logic in one place,
and without thinking much about separation of concerns.

That got me moving quickly, which was good.

But after a while, I could feel the cost:

harder refactors,
messier UI code,
less confidence when adding features.

That was actually one of the most valuable parts of the project.

It taught me that learning Kotlin is not just about syntax.

It is also about learning where code should live.

The Kotlin features that clicked fastest for me

Some Kotlin features made sense almost immediately once I used them in a real app.

Data classes

These were one of the quickest wins.

As soon as I started modeling app data, data classes felt obvious and useful.

They reduce boilerplate and make data easier to reason about.

`when`

This felt much cleaner than long conditional chains.

It became especially useful for handling UI states and branching logic in a more readable way.

Null safety

Even though it was frustrating at first, it made my code more intentional.

Once I stopped fighting it, I started trusting my code more.

Immutability by default

This changed how I thought about state.

When building UI, predictable state matters a lot.

Kotlin nudged me toward better habits there.

Extension functions

These made code feel more expressive once I understood where they were actually useful.

Not “clever” useful — but genuinely cleaner in small repeated patterns.

What I would focus on first if I started again

If I had to restart from zero today, I would not try to learn everything.

I would focus on this order:

1. Core Kotlin basics

variables
functions
classes
nullability
collections
control flow

2. Kotlin features that matter quickly in apps

data classes
when
immutable patterns
simple extension functions

3. Basic Android app flow

screens
user input
state
navigation
local data

4. Code organization

separating UI from logic
keeping files readable
avoiding giant screens or giant classes

5. Then only later: deeper architecture and advanced patterns

I would avoid over-optimizing too early.

The first milestone should not be:

“Build the perfect architecture.”

It should be:

“Build something working, understandable, and easy enough to improve.”

That makes everything else easier.

My biggest takeaway

The biggest thing I learned is this:

Kotlin became much easier once I stopped trying to “master Kotlin” and started trying to build something with it.

That shift changed everything.

A real app gave every concept a reason to exist.

Without a project, Kotlin was just a list of language features.

Inside a project, it became:

a way to model data,
a way to structure UI logic,
a way to write safer code,
and a way to think more clearly about app development.

That’s when learning started to feel real.

Final thoughts

If you are trying to learn Kotlin right now, my honest advice is:

Don’t wait until you feel “ready.”

Don’t try to complete every tutorial first.

Build something small.

Make it real.

Let the project expose the gaps in your understanding.

That is where the best learning happens.

Not when everything is clear.

But when the code forces you to ask better questions.

If you’re learning Kotlin too, I’d love to know:

What has been harder for you so far — the language itself, Android concepts, or figuring out how to structure a real app?

NatureNode: An AI-Powered Biodiversity Research Tool for Earth Day

𝗝𝗼𝗵𝗻 — Sat, 18 Apr 2026 09:30:00 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

NatureNode is a professional biodiversity research tool and Progressive Web App that transforms a smartphone photo into a comprehensive ecological dossier — instantly, in the field, with no backend and full offline capability.

Most identification apps give you a name and a pretty photo. NatureNode gives you what a field researcher actually needs:

🔬 Full scientific taxonomy — family, genus, species
🌍 Conservation status (IUCN scale) and native range
♻️ Ecological role — what this organism contributes to its ecosystem
🛡️ Protection guidelines — actionable tips to conserve what you found
📓 Specimen Journal — a persistent local database of all your discoveries
🗺️ Location tagging + one-tap Google Maps navigation

The design philosophy matched the ambition: dark botanical aesthetics, high information density, and interactions that feel deliberate — like a research dashboard, not a social app.

Demo

🌿 Live PWA: https://johnnylemonny.github.io/naturenode/

To try it: Get a free Gemini API key at Google AI Studio, paste it into the app, and upload any photo of a plant, insect, animal, or mushroom. Your key is stored securely in your browser — never on any server.

Code

johnnylemonny / naturenode

🌿 NatureNode: A premium Progressive Web App (PWA) for advanced biodiversity identification. Powered by Google Gemini AI, featuring professional field research tools, specimen journaling, and ecological conservation insights. Built as part of the DEV Weekend Challenge.

🌿 NatureNode

NatureNode is a professional biodiversity research and identification tool. Designed for field researchers and nature enthusiasts, it leverages state-of-the-art AI to transform simple photos into comprehensive ecological dossiers.

🌟 Key Features

Botanical Precision UI: A high-density, research-oriented design system using Tailwind CSS v4 and the OKLCH color model for superior visual clarity.
AI-Driven Identification: Powered by Google Gemini 3 Flash for instant, high-accuracy recognition of plants, animals, insects, and fungi.
Specimen Journal: A persistent, local history of all your discoveries, allowing you to build your own personal biodiversity database.
📱 PWA & Offline Support: Fully installable as a Progressive Web App. Designed to work in the field with robust offline capabilities.
🗺️ Manual Location Mapping: Easily log observation points by town or area name.
📍 Google Maps Integration: One-click navigation and mapping of find locations directly in Google Maps.
Ecological Insights…

View on GitHub

How I Built It

Architecture: Zero-Backend, Privacy-First PWA

The core constraint was: no backend, no running costs, no privacy compromise. Everything that isn't AI inference runs locally in the browser. The Gemini API call goes directly from the user's browser to Google's servers using their own key — a "Bring Your Own Key" model that is the most honest approach to privacy-first AI tooling possible.

User Browser
├── React 19 + TypeScript          # UI & state management
├── Vite 8 (Rolldown engine)       # Lightning-fast builds
├── Tailwind CSS v4 (OKLCH model)  # Design system with perceptual color
├── Vite PWA Plugin + Workbox      # Offline support & installability
└── @google/generative-ai SDK      # Direct browser → Gemini calls

Gemini Integration: Typed JSON Schema

The intelligence layer is engineered around Gemini's responseSchema API — instead of parsing or validating free-form AI text, the model is constrained to return exactly the data shape that TypeScript expects. Zero parsing errors, deterministic structure:

const responseSchema = {
  type: SchemaType.OBJECT,
  properties: {
    commonName:         { type: SchemaType.STRING },
    scientificName:     { type: SchemaType.STRING },
    conservationStatus: { type: SchemaType.STRING },
    ecologicalRole:     { type: SchemaType.STRING },
    protectionTips: {
      type:  SchemaType.ARRAY,
      items: { type: SchemaType.STRING }
    }
    // ...
  }
};

const model = genAI.getGenerativeModel({
  model: "gemini-3-flash-preview",
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema,           // ← model is constrained to this shape
  },
});

This approach is more reliable than prompt-engineering your way to JSON and faster than asking the model to explain its reasoning. The result: sub-3-second identifications with zero unparseable responses.

Secure API Key Storage

GitHub's CodeQL scanner flagged clear-text storage of the user's key in localStorage. The fix: Base64 obfuscation with a generic storage key name. Not encryption — but it prevents the key from sitting as a plain string visible in browser dev tools, and satisfies static analysis:

const obfuscate   = (s: string) => window.btoa(unescape(encodeURIComponent(s)));
const deobfuscate = (s: string) => decodeURIComponent(escape(window.atob(s)));

// Save
localStorage.setItem("nn_secure_session", obfuscate(apiKey));

// Load
const raw = localStorage.getItem("nn_secure_session");
return raw ? deobfuscate(raw) : "";

PWA & Offline

Workbox precaches all static assets at build time — the shell, fonts, and full UI load instantly even with no connection. Only the Gemini API call requires internet, and the app communicates this clearly. The manifest enables full "Add to Home Screen" installability on both Android and iOS.

CI/CD Pipeline

Three GitHub Actions workflows run on every push:

Workflow	Tool	Purpose
`deploy.yml`	`actions/deploy-pages@v4`	Build → GitHub Pages (no branch needed)
`linter.yml`	Super-Linter slim v7	JS / TS / HTML / JSON quality gates
`codeql.yml`	CodeQL	Security vulnerability scanning

Prize Categories

🥇 Best Use of Google Gemini — Gemini 3 Flash Preview is the entire intelligence layer, used with typed JSON schema enforcement for production-grade, zero-parse AI responses delivered directly from browser to API.

5 Developer Trends That Actually Matter in 2026 (Not Just the Hype)

𝗝𝗼𝗵𝗻 — Thu, 16 Apr 2026 12:45:32 +0000

Every year, developers get flooded with trend lists.

Most of them are either too broad to be useful or too early to matter in real projects.

So instead of listing every shiny new thing, I want to focus on the shifts that are already changing how modern apps are built, shipped, and maintained right now.

Because 2026 does feel different.

GitHub’s latest Octoverse data says more than 1.1 million public repositories now use an LLM SDK, with 693,867 of those created in the last 12 months alone. It also reports that TypeScript became the most-used language on GitHub in August 2025, overtaking both Python and JavaScript. 1

That is not just noise. That is a signal.

Here are the five trends I think actually matter in 2026 — and what developers should do about them.

1. AI coding agents are moving beyond autocomplete

For a while, AI coding tools were mostly “fancy autocomplete.”

That is no longer the right mental model.

Anthropic’s 2026 Agentic Coding Trends Report argues that in 2025, coding agents moved from experimental tools to systems that can handle real implementation workflows, including writing tests, debugging, generating docs, and navigating large codebases. At the same time, the report notes an important nuance: developers may use AI in roughly 60% of their work, but they still report being able to fully delegate only 0–20% of tasks. 2

That means the real shift is not “AI replaces developers.”

The real shift is:

developers are becoming managers of execution loops.

Instead of asking:

“Can the tool write this function?”

we now ask:

“Can the agent plan this task?”
“Can it inspect the codebase safely?”
“Can it run tests and recover from failure?”
“Can it return something reviewable?”

What this means in practice

The best teams will stop treating AI as a tab in the IDE and start treating it as an async collaborator.

That changes what matters in your codebase:

clean file structure,
consistent naming,
reliable tests,
good docs,
and explicit constraints.

Messy code used to slow down humans.

Now it also slows down agents.

2. MCP is becoming the integration layer developers should pay attention to

One of the biggest shifts happening quietly is the rise of MCP — the Model Context Protocol.

Cloudflare describes MCP as an open standard that connects AI systems to external applications, comparing it to a “USB-C port for AI applications.” Vercel describes it similarly as a standard interface that lets LLMs communicate with external tools and data sources. 3 5

Why does that matter?

Because once agents become useful, the next bottleneck is tool access:

databases,
issue trackers,
deployment platforms,
logs,
docs,
cloud resources,
and internal APIs.

MCP is interesting because it reduces custom glue code and pushes the ecosystem toward a common contract.

And this is no longer theoretical.

Cloudflare explicitly supports building and deploying MCP servers. Vercel has its own official MCP server and documents support for clients including Claude, ChatGPT, Cursor, VS Code with Copilot, Codex CLI, Windsurf, and more. 3 4

What this means in practice

If you build developer tools, internal platforms, APIs, or anything that might be used by agents, you should already be asking:

Should this expose an MCP interface?
What tools would actually be safe and useful for an agent?
What permissions should be scoped tightly?
What tasks should remain human-only?

In 2026, “AI-ready” increasingly means “toolable by standards.”

3. Type safety and boring developer experience are becoming competitive advantages

One of the most underrated trends right now is that typed and predictable systems are becoming more valuable, not less.

GitHub’s Octoverse says TypeScript overtook both Python and JavaScript in August 2025 to become the most-used language on GitHub, calling it the most significant language shift in more than a decade. GitHub also ties that rise to agent-assisted coding, arguing that typed languages make production work more reliable. 1

This matches what many teams are noticing already:

When humans and agents work together, ambiguity becomes expensive.

That is why “boring” qualities are suddenly strategic:

strong types,
explicit contracts,
stable interfaces,
predictable scripts,
clear schemas,
readable errors.

If your stack is easy to reason about, it is easier to automate, test, review, and evolve.

What this means in practice

The question is not:

“What is the trendiest stack?”

The better question is:

“What stack minimizes ambiguity for both humans and machines?”

That is one reason TypeScript-heavy workflows feel stronger right now:

they reduce guessing,
improve refactors,
and make AI-assisted changes less fragile.

In 2026, good DX is no longer just a human experience.

It is also an agent experience.

4. Passkeys are moving from “nice idea” to default modern authentication

Authentication is also going through a real shift.

Passkeys are no longer just something security people talk about at conferences.

The FIDO Alliance describes passkeys as phishing-resistant credentials based on FIDO standards that let users sign in with the same process they use to unlock their device. FIDO also says passkeys lead to 20% more successful sign-ins over passwords, and reports that 53% of people have enabled passkeys on at least one account, while 22% enable them everywhere they can. 6

On the implementation side, Microsoft now documents passkeys in ASP.NET Core Identity, and MDN describes WebAuthn as a widely available browser capability that enables strong authentication with public key cryptography. 7 8

That makes passkeys relevant far beyond enterprise identity teams.

They now matter to:

SaaS builders,
indie hackers,
frontend engineers,
full-stack teams,
and anyone trying to improve signup/login conversion without weakening security.

What this means in practice

If you are building a modern app in 2026, authentication should probably be designed around:

passkeys,
OAuth/OIDC where appropriate,
and fewer custom password flows.

The old “email + password + reset flow + 2FA patchwork” setup is no longer the most compelling default.

The modern question is:

“How do I reduce friction and improve security at the same time?”

Passkeys are one of the few trends that genuinely do both.

5. Open source maintainership is changing because AI lowers contribution friction

One more trend that deserves attention: AI is increasing contribution volume, but not always contribution quality.

GitHub’s Octoverse reports record growth in repositories, pull requests, and commits, with more than 36 million new developers joining GitHub in the past year, more than 230 new repositories created every minute, and 43.2 million pull requests merged on average each month. 1

That growth is exciting — but it also creates pressure.

InfoQ, summarizing GitHub’s open source trend analysis, highlights a growing maintainer burden from low-quality AI-generated issues and pull requests, and argues that projects without clear written governance, contribution guidelines, and review expectations will struggle to scale sustainably. 9

What this means in practice

In 2026, if you maintain a public repository, your project needs more than code.

It needs:

contribution rules,
issue templates,
review expectations,
a clear roadmap,
and documentation that helps people help you.

Open source is becoming more accessible.

That is good.

But it also means maintainers need better systems, not just better instincts.

So what should developers actually do now?

If I had to turn these trends into a practical 30-day plan, it would look like this:

1. Upgrade how you use AI

Stop using AI only for snippets.

Start testing it on:

scoped feature implementation,
test generation,
documentation updates,
and repetitive refactors.

2. Audit your codebase for agent-friendliness

Ask:

Is the structure obvious?
Are scripts predictable?
Are errors readable?
Are tests reliable?

3. Learn the MCP mental model

Even if you do not build an MCP server this month, understand:

hosts,
clients,
servers,
permissions,
and where this fits in your stack.

4. Revisit authentication

If your product still treats passwords as the default forever-plan, it is time to reassess.

Passkeys are no longer “future tech.”

5. Treat repositories like products

If you maintain public code, improve:

README,
contribution docs,
labels,
issue templates,
and release notes.

Because in 2026, the quality of your repo operations matters almost as much as the quality of your code.

Final thought

A lot of trend posts focus on what is new.

The more useful question is:

what is already reshaping real developer workflows?

Right now, the answer looks something like this:

AI agents are becoming real collaborators,
MCP is becoming the connector layer,
typed systems are gaining strategic value,
passkeys are becoming practical default auth,
and maintainership is becoming more operational.

That is not just hype.

That is a workflow shift.

The developers who adapt fastest will not be the ones who try every new tool.

They will be the ones who build systems that are:

clearer,
safer,
more automatable,
and easier for both humans and machines to work with.

What trend are you actually seeing in your day-to-day work right now?

Is it AI agents, passkeys, TypeScript everywhere, better repo hygiene, or something else?

How to Build a Public Open-Source Project People Actually Want to Clone, Use, and Contribute To

𝗝𝗼𝗵𝗻 — Mon, 13 Apr 2026 12:42:18 +0000

Most public repositories do not fail because the code is bad.

They fail because:

nobody understands why the project exists,
it is hard to run locally,
the repository looks like an abandoned side experiment,
and there is no clear reason for anyone to come back a second time.

If you want to build public open-source projects that attract attention on GitHub, earn stars, and gain real users, you have to think about your repository as more than a folder of code.

You have to treat it like a public product.

In this article, I’ll show you how to build modern open-source projects so they:

look credible from the first visit,
are easy to run,
invite contributions,
and have a much better chance of growing organically.

1. Start with a problem, not with a stack

A very common mistake looks like this:

“I’m going to build a new project in Next.js / FastAPI / Rust / Bun to practice.”

That may be a fine learning project, but it rarely turns into a strong public project.

Repositories that have the best chance of getting traction usually solve one clear problem:

they save time,
simplify something,
automate something repetitive,
or show a modern, opinionated way to build something useful.

Better ideas than “another starter”:

a starter with a real-world use case,
a boilerplate for a specific product type,
a tool that solves a small but frequent developer pain point,
a team-ready repository template,
a dashboard, generator, CLI, integration, or mini-SaaS released as open source.

A good rule of thumb:

If you can’t describe the project in one sentence without naming technologies, the idea is probably still too vague.

Instead of:

“This is a project built with React, Node, Prisma, and Docker.”

Say:

“This is an open-source starter for building admin panels with authentication, roles, billing, and deployment already set up.”

People click on problems.

Not on stacks.

2. Build a small but complete vertical slice

A public project does not need to be huge.

It needs to feel complete.

That is a big difference.

It is far better to show:

working authentication,
one clean core workflow,
solid UI,
sensible folder structure,
documentation,
and a simple deployment path,

than to show 27 half-finished features.

The most shareable open-source projects are often the ones that create this feeling quickly:

“Okay, this works. I can see how I would use this.”

That’s why modern public apps should include:

clear onboarding,
a demo or screenshots,
fast local setup,
sample data,
a useful .env.example,
and one obvious way to run the project.

If someone needs 40 minutes just to reach the first useful screen, you lose most potential users.

3. Treat your README like a landing page

In practice, your README is your project’s homepage.

That is where visitors decide, often within seconds:

whether to stay or leave,
whether to star the repo,
whether to clone it,
or whether to close the tab.

A good README does not begin with:

“Project X is a modern application that aims to…”

It begins with a clear value proposition.

What your README should include near the top

1. A one-line pitch

Make it obvious:

what it is,
who it is for,
and why it matters.

Example:

An open-source SaaS starter for building modern web apps with auth, billing, roles, and deployment built in.

2. A screenshot, GIF, or live demo

People understand software much faster when they can see it.

If it’s an application, show:

the dashboard,
onboarding,
settings,
or the core workflow.

3. A “why this exists” section

Briefly explain:

what problem you are solving,
how the project is different,
when someone should use it.

4. A fast start section

Keep it short and practical:

clone,
install,
env,
run.

5. Key features

Not every feature.

Only the ones that actually communicate the value.

6. A roadmap

People are more likely to follow a project when they can see where it is going.

7. A contributor section

Even a short one helps.

It should be obvious how someone can get involved.

A README does not need to be long.

It needs to be clear, concrete, and easy to scan.

4. A public repository has to inspire trust

A lot of repositories look promising at first glance.

Then you open them and discover:

no license,
no idea whether the code can be used,
no contribution rules,
no issue templates,
no signal that the project is actively maintained.

If you want people to take your project seriously, you need the trust layer of open source.

At minimum, have:

README.md
LICENSE
CONTRIBUTING.md
CODE_OF_CONDUCT.md
SECURITY.md
issue and pull request templates
a meaningful repository description

These are the details that separate:

“I uploaded some code” from
“I’m building a project people can join.”

5. Optimize the first five minutes

The most important moment is not when someone stars your repo.

The most important moment is when someone tries to run it locally.

If they hit:

missing environment variables,
outdated setup instructions,
confusing scripts,
broken migrations,
or secrets hidden in config files,

they are usually gone.

That’s why you should test your project as if you were a stranger discovering it for the first time.

My simple pre-release checklist

Before making a repo public, I ask:

Can a new person run this without asking me questions?
Does the README answer the most obvious setup questions?
Is the configuration predictable?
Are the error messages understandable?
Do sample data or seed scripts help show value quickly?
Are the script names obvious?
Can this project run on a clean machine without guesswork?

This usually matters more than one more feature.

6. Package the repository like a product

Strong public projects are not only well-built.

They are also well-packaged.

If you want more visibility:

choose a clear repository name,
write a sharp description,
use relevant tags/topics,
add a social preview image,
publish real releases,
show progress through changelogs and updates.

This is especially important for:

modern web apps,
starters,
boilerplates,
developer tools,
templates,
and infrastructure projects.

People often judge project quality from the repository page itself:

is the name clear,
is the description useful,
is the value obvious,
does the project look active?

Your code can be excellent and still get ignored if the repository looks neglected.

7. Build community around the problem, not just the code

A lot of people think open source is only about pull requests.

That is too narrow.

People can add value in many ways:

reporting bugs,
suggesting features,
improving documentation,
testing edge cases,
sharing feedback,
explaining how they use the project.

That is why you should create a space not only for code changes, but for discussion and learning.

Helpful tools include:

issue templates,
labels like good first issue,
help wanted,
a public roadmap,
a list of contribution ideas,
an FAQ,
discussion threads,
or a feedback board.

The less friction people feel, the more likely they are to participate.

8. Publish early, but do not publish chaos

“Ship early” is good advice.

But “make it public early” does not mean:

“Throw everything online before it makes sense.”

Before you promote a project, make sure it is at least:

understandable,
runnable,
documented,
and safe to share publicly.

This matters even more if you are building in public on:

X,
LinkedIn,
DEV,
Reddit,
Hacker News,
newsletters,
or YouTube.

One of the most common mistakes in open source is promoting a project too early:

before the README is useful,
before setup works,
before the value proposition is clear.

The result?

Traffic arrives, but it does not turn into:

stars,
watchers,
issues,
contributors,
or real users.

It is better to publish a week later and make a strong first impression.

9. Think repo-first for modern apps

If you are building a modern app in public, your repository is part of the product.

It does not just store code. It:

sells the idea,
documents decisions,
builds trust,
shows quality,
and invites people in.

A modern repository should answer these questions immediately:

What does this do?
Why does it exist?
How do I run it?
How do I use it?
How do I report a problem?
How do I contribute?
What direction is the project going?

If those answers are visible from the beginning, your repository starts working for you even when you are offline.

10. A simple checklist before publishing on GitHub

Use this as a lightweight definition of done for any public project.

Product

[ ] The project solves a specific problem
[ ] There is a clear use case to show
[ ] The value can be explained in one or two sentences

Repository

[ ] The README is clear and concrete
[ ] There is a screenshot, GIF, or demo
[ ] There is a LICENSE
[ ] There is a CONTRIBUTING.md
[ ] There is a CODE_OF_CONDUCT.md
[ ] There is a SECURITY.md
[ ] Issue and PR templates are ready

Developer Experience

[ ] There is an .env.example
[ ] Setup works from zero
[ ] Commands are simple and predictable
[ ] There is seed or sample data
[ ] The project runs without guesswork

Visibility

[ ] The repo has a good description
[ ] The repository name is easy to understand
[ ] Relevant tags/topics are added
[ ] A first release is prepared
[ ] The next steps are visible

Final thought

Open source does not win on code quality alone.

It wins through a combination of:

usefulness,
clarity,
trust,
easy onboarding,
and consistent visible progress.

If you want to build public projects that actually grow, do not just ask:

“How do I write better code?”

Also ask:

“Will a random developer on the internet understand this project, run it, and want to come back?”

Because that is where real public open source begins.

If you are building public repositories yourself, I’d love to know:

What kills open-source projects fastest in your experience — scope creep, weak onboarding, poor README, inconsistent updates, or something else?

Working on Cabal v3: reviving a P2P mobile chat app with React Native

𝗝𝗼𝗵𝗻 — Mon, 13 Apr 2026 08:33:42 +0000

Right now I’m working on Cabal v3 — a modern peer-to-peer chat app for Android built on top of the Cable protocol.

This project is both a modernization and a revival of the older cabal-mobile effort:
https://github.com/cabal-club/cabal-mobile

The original project was created to let people chat with the P2P swarm on mobile devices, and its last tagged release (1.0) goes back to June 17, 2018. Later, the project README pointed development toward a v2 branch, so the idea of evolving the mobile client has already been part of its history. 1 2 3

What makes this especially interesting to me is the protocol underneath it.

Cable is a lightweight protocol for peer-to-peer private group chats, where peers communicate directly instead of depending on a centralized server. The protocol is designed around encrypted communication between equal peers and the exchange of cryptographically signed chat data. 4 5

For me, this is not just an interesting open-source revival.

It’s also a really good opportunity to learn more about building a mobile frontend with React Native while working on something rooted in decentralized communication.

So this project sits at a really interesting intersection for me:

mobile development
React Native
Android
open source
and peer-to-peer systems

Still early, but I’m excited to keep pushing it forward.

From NASA Exoplanet Query to ExoVault: Building a Better Data Exploration Experience

𝗝𝗼𝗵𝗻 — Sat, 11 Apr 2026 13:25:13 +0000

Other project idea I recently decided to build in public was inspired by the NASA Exoplanet Query prompt from the App Ideas repository.

That project eventually became ExoVault:
https://github.com/johnnylemonny/ExoVault

What started as a structured data query idea turned into something much more interesting for me:
a more polished, cinematic interface for exploring NASA exoplanet archive data.

The original prompt

The NASA Exoplanet Query idea is already a really good challenge.

It’s built around:

working with NASA archive data,
loading CSV efficiently,
minimizing delays at startup,
and building a query interface that lets users filter exoplanet data by fields like discovery year, method, host name, and facility.

That made it appealing right away.

It wasn’t just about rendering data.
It was about thinking carefully about:

ingestion,
structure,
search,
and presentation.

What pulled me into this idea

What interested me most wasn’t only the dataset.

It was the possibility of taking something that could have been “just a query tool” and pushing it toward a better exploration experience.

I kept thinking:

What if this felt less like a utility screen and more like a discovery product?

That question shaped the direction of the whole project.

Instead of building only the minimum query UI, I wanted to create something that felt more deliberate, more visually refined, and more enjoyable to explore.

That’s where ExoVault came from.

How ExoVault evolved

In my version, the project became a more premium archive explorer built around:

a custom CSV-to-JSON data pipeline,
a high-performance frontend,
compare mode for exoplanetary systems,
glassmorphic visuals,
and a more cinematic browsing experience.

I built ExoVault with:

Astro
React
Tailwind CSS
TypeScript

and used a custom data pipeline to process NASA’s raw CSV into optimized JSON payloads.

That part was especially satisfying because it made the project feel more complete end-to-end:
not just UI, not just data handling, but both working together.

What I wanted the project to feel like

One of my goals with ExoVault was to make exploration feel intentional.

Not just:

filter,
search,
render rows,
done.

I wanted the archive to feel like something people would actually want to browse.

That meant paying attention to things like:

visual hierarchy,
transitions,
compare flow,
and how the interface frames the data.

I think there’s a big difference between “showing information” and “creating a discovery experience.”

This project made me think a lot about that difference.

What I learned while building it

A few things stood out while working on ExoVault:

1. Data projects become more interesting when presentation is treated seriously

A structured dataset can feel dry or compelling depending on how the experience is shaped.

2. Prompt-based ideas are often stronger than they first appear

The original App Ideas brief gave me a very solid technical core.
The interesting part came from deciding how to evolve it.

3. Frontend polish matters even in data-heavy apps

If the interface feels flat, the whole experience feels flatter too.
Good data presentation is also a UX problem.

4. Public repos push me toward stronger execution

Knowing the project would live openly on GitHub made me care more about the quality of the pipeline, repo structure, documentation, and overall presentation.

Why I like using structured prompts as a starting point

I think structured prompt repositories are one of the best ways to build momentum — especially if you don’t treat them as the finish line.

That’s how I’m trying to use them.

Not as instructions to copy,
but as a framework to build from.

The prompt gives me:

direction,
constraints,
and technical focus.

Then the real project begins when I start asking:

how should this feel?
what should be improved?
what makes this worth sharing publicly?
how can this become more than the base brief?

ExoVault is probably one of my clearest examples of that so far.

From a Calorie Counter Prompt to a Local-First Nutrition Tracker

𝗝𝗼𝗵𝗻 — Sat, 11 Apr 2026 13:06:38 +0000

One of the things I’ve been trying to do lately is take project prompts seriously enough to turn them into public, polished repositories instead of leaving them as half-finished exercises.

That’s exactly what happened with NutraFlux:
https://github.com/johnnylemonny/NutraFlux

The project was inspired by the Calorie Counter idea from the App Ideas repository, but I didn’t want to stop at “search foods and show calories.”

I wanted to push it into something that felt faster, cleaner, and more product-like.

The original idea

The original Calorie Counter prompt is already a strong one.

It focuses on:

searching foods,
showing matching results,
calorie values,
and working with structured nutritional data.

It also introduces useful technical constraints:

transforming raw food data into a format that is easier to search,
limiting results,
and thinking about performance and search strategy.

That made it a really good foundation.

What interested me most

What grabbed my attention wasn’t just the calorie tracking part.

It was the opportunity to build a nutrition tool that felt:

immediate,
search-first,
and frictionless.

A lot of apps in this space feel slower or heavier than they need to.

So instead of treating this as a basic exercise, I started asking:

What would this feel like if I designed it more like a fast, privacy-friendly product?

That question eventually led to NutraFlux.

How NutraFlux evolved

In my version, the idea became a local-first daily calorie and macro tracker built around speed, privacy, and a more refined frontend experience.

NutraFlux includes:

instant search-first logging,
wildcard food lookup,
meal categories,
calorie budgeting and progress indicators,
favorites and recently used foods,
adaptive design,
and a more polished visual system.

What I liked most about building it was that the original prompt gave me a functional core — but the product identity came from the decisions I made around it.

That’s where it stopped feeling like a challenge and started feeling like my own project.

Why I made it local-first

One of the biggest choices behind NutraFlux was making it strictly local-first.

Everything lives in the browser:

nutritional data,
settings,
and food history.

No account wall.
No cloud sync.
No user data leaving the device.

I really liked that direction because it made the product feel:

faster,
more private,
and more focused.

It also changed how I thought about UX.

When everything happens instantly and locally, the interface itself has to carry more of the experience.

That made clarity, speed, and smooth interaction much more important.

What I learned from building it

A few things really stood out while working on this project:

1. A strong prompt is a good starting point — not a limitation

The base idea gave me a clear direction, but the interesting part was deciding how far to take it beyond the original brief.

2. Product feel matters as much as base functionality

The app can technically work, but it still won’t feel complete unless the UI, feedback, and flow are treated with care.

3. Privacy can be part of the product identity

Making NutraFlux local-first wasn’t just a technical detail.

It became one of the reasons the app feels different.

4. Public repos raise the bar in a good way

Once I knew this would live publicly on GitHub, I thought more carefully about polish, structure, and presentation.

Why I like building from prompts this way

I think project prompt repositories get underestimated sometimes.

But for me, they’re useful because they remove just enough uncertainty to let me focus on what really matters:

interpretation,
technical decisions,
UX,
polish,
and project identity.

NutraFlux is a good example of that.

It started as inspiration from a calorie counter prompt.
Now it’s part of the kind of public open-source work I want to keep building more of.

I Built a Free Hydration Tracker with No Signup: Here’s What I Learned

𝗝𝗼𝗵𝗻 — Fri, 10 Apr 2026 16:56:20 +0000

I recently built Drink Daily, a hydration tracking web app designed to be free, simple to use, and available without registration.

🔗 Live app: https://drink-daily.vercel.app/en

This is one of the projects I’m most proud of so far, not just because it works, but because it reflects the kind of products I like building: practical, lightweight, and polished enough to feel good to use.

Why I built it

A lot of small health-related apps create friction too early.

You open the app and immediately hit:

a sign-up wall,
limited functionality,
too much clutter,
or an interface that feels more like a form than a product.

I wanted to build something different:

useful from the first visit
no registration required
clear and focused
pleasant to interact with
good enough to feel like a real product, not just a demo

Hydration tracking felt like a good fit for that kind of experience.

What Drink Daily is

Drink Daily is a free hydration tracking app that helps users keep track of daily water intake without forcing account creation.

The goal was to keep the experience:

frictionless,
fast,
understandable,
and easy to return to.

Instead of overcomplicating the idea, I focused on making the core experience feel smooth and intentional.

What I wanted to get right

When I started building it, I cared about more than “just making it work.”

I wanted the app to feel:

1. Simple

The app should be easy to understand immediately.

2. Lightweight

No unnecessary barriers, no bloated flows, no forced registration.

3. Polished

I enjoy building interfaces that feel refined, so I paid attention to layout, spacing, clarity, and the overall experience.

4. Actually usable

Even for a small app, I wanted it to feel like something people could genuinely use — not just click through once.

What I learned while building it

Building Drink Daily taught me a lot about the difference between having features and creating a good experience.

A few things stood out:

Product decisions matter as much as technical ones

It’s easy to keep adding features, but choosing what not to add is just as important.

Small UX details make a huge difference

Spacing, hierarchy, naming, and flow can completely change how “finished” a project feels.

Friction shows up fast in simple apps

When the app itself is simple, every unnecessary step becomes more noticeable.

Public projects feel different

Building something you’re willing to show publicly makes you think more carefully about quality, clarity, and polish.

What I’d improve next

Like most projects, this one still has room to grow.

Some things I’d like to improve or expand over time:

deeper progress insights
more personalized tracking options
more refinement in the user flow
additional quality-of-life improvements
continued UI/UX polishing

I also want to keep improving how I present and document my public work.

Why I’m sharing it

I’m currently growing my public developer profile and becoming more active in open source and build-in-public style sharing.

This project felt like a good first thing to share because it reflects what I enjoy most:
building practical web apps with a strong focus on clean UI, smooth UX, and modern frontend development.

If you try the app, I’d genuinely appreciate any feedback:

What feels good?
What feels unclear?
What would you improve?