DEV Community: whaiman

No Ship November: A Month Without Public Progress Updates

whaiman — Fri, 23 Oct 2026 17:16:41 +0000

Build in silence. Share what you did after November.

When a developer completes a significant task - merging a pull request, resolving a complex bug, or validating a new prototype - there is often an immediate opportunity to share that achievement. A screenshot on a social media platform, a commit message on a public repository, or a status update in a community channel are all standard ways to signal progress.

Public sharing serves several concrete purposes: it provides a way to receive feedback, helps in finding collaborators, assists in documenting technical decisions, and can open up professional opportunities. These are important functions of a developer's public presence. However, there is a distinct difference between making progress and preparing that progress for a public audience.

At times, a useful piece of work can be shared immediately. At other times, reaching a meaningful conclusion takes days or weeks of investigation. An unfinished architectural decision, a rejected hypothesis, or a long debugging session may not produce anything suitable for a public update. When we feel the need to report every visible milestone, the time spent on the presentation of the work can sometimes overshadow the work itself.

No Ship November is a voluntary, independent experiment designed to explore what happens when we intentionally remove that pressure to report progress for one month.

The Experiment

From November 1 through November 30, 2026, participants are invited to select one specific focus - a project, a technical problem, a research question, or a new skill - and work on it without publicly sharing any intermediate progress or achievements related to that focus anywhere online.

No Ship November is an independent initiative and is not organized, sponsored, approved, or endorsed by DEV.

The central question of the initiative is: “What changes when you spend a month working on something without turning intermediate progress into public announcements?”

This is an experiment, not a productivity method with a guaranteed result. You might find that you work with greater focus. You might also miss the feedback, discussion, or accountability that public updates can bring. Or you might notice little difference. Any of these outcomes is a valid result of trying the experiment.

Choosing Your Focus

Choosing a focus shapes the experience of the experiment. There is no expected outcome. Work on your chosen focus as you normally would, without publicly reporting its progress, and see whether anything changes for you.

The focus can be a small task, an investigation, a learning goal, or a larger project. It does not need to lead to a public release or a completed product. A suitable focus should be specific enough to navigate easily, but broad enough to allow for genuine exploration. Here are several examples of what a participant might choose:

Investigating an intermittent bug: Spending the month trying to reproduce and understand a "flaky" issue whose cause is currently unknown.
Comparing system architectures: Evaluating two different designs (e.g., comparing different database schemas, message brokers, or microservices patterns) before committing to one.
Deep learning and research: Studying an unfamiliar protocol, a complex compiler, or a new library deeply enough to form an independent technical opinion.
Improving neglected subsystems: Refactoring a "boring" part of an existing codebase - the kind of work that rarely makes for a good screenshot but significantly improves system health or maintainability.
Building a "throwaway" prototype: Creating a proof-of-concept to test a specific idea that may be discarded entirely after the first tests.
Exploring a research question: Collecting evidence for or against a specific technical hypothesis.

A participant does not need to disclose their exact goal publicly. If you wish to join the experiment, a simple comment such as “I’m in” is sufficient to signal your intention.

The Rules

To ensure a consistent experience for all participants, the following rules apply during the month of November.

Rule 1: One chosen focus

The experiment applies to one selected project, problem, question, idea, or learning goal. It does not suspend your entire public or professional life. You are not expected to stop all online activity.

Rule 2: No public progress updates

You must refrain from publicly sharing progress or achievements related to your chosen focus anywhere online during the month of November. This applies to all platforms, including but not limited to DEV.to, GitHub, X (Twitter), Reddit, and personal blogs.

Prohibited actions include:

Pushing progress-related commits or repository updates to a public repository.
Opening public pull requests or publishing project releases that reveal progress on the chosen focus.
Posting screenshots, demos, videos, benchmarks, or milestone announcements.
Publishing blog posts, technical write-ups, changelogs, or social media updates about the selected work.
Sharing progress through public community channels or livestreams.

Note on Git: Local commits are permitted. A branch that exists only on your machine is not publicly visible. A private repository is another option. If you push a branch to a public repository, however, its contents are public regardless of the branch name.

Rule 3: Private work and communication remain allowed

This experiment does not require isolation. You may continue to code, research, run tests, and keep private notes. You can continue private conversations with collaborators, internal work communication, and any coordination your work requires. The experiment does not require isolation.

Rule 4: Unrelated public activity is allowed

You are free to remain active in the developer community. You can publish articles about unrelated projects, contribute to repositories that are not your chosen focus, and join discussions.

Example: If your focus is "Investigating a new database schema," you are prohibited from posting an update about that schema. However, you are perfectly free to post an article about a book you read on CSS, or contribute a typo fix to a popular open-source library that is unrelated to your focus.

Rule 5: Responsibilities come first

Participation in this experiment must not be used as an excuse to neglect professional duties. No one should delay security fixes, violate contractual obligations, mislead a customer, or withhold necessary information from collaborators because of the experiment.

If your work involves obligations that make a temporary pause in public progress updates inappropriate or risky, choose a different focus for the experiment. Necessary emergency and professional actions take priority over the experiment.

Rule 6: No mandatory completion or reporting

There are no "streaks," quotas, or required hours. You do not have to finish your project, write a retrospective, or publish a "final" result on December 1. There are no entry fees, prizes, points, badges, or leaderboards.

Who might find it useful?

The experiment can appeal to developers whose work naturally produces visible milestones, as well as to people whose work involves long periods of uncertainty.

For an early-career developer, a month might involve learning a new codebase or trying to understand a difficult concept. For these developers, the experiment might help them notice whether sharing new discoveries changes how they approach learning.

For an experienced engineer, the month might involve architectural investigation, refactoring technical debt, or evaluating competing designs. For these professionals, the experiment might explore how much "invisible work" - the work that keeps systems running but does not make for a great headline - actually occupies their time.

For a researcher, the month might involve testing assumptions before finding an answer worth presenting. They might observe whether the absence of public updates changes how they allocate time between investigation, analysis, and presenting intermediate findings.

Different kinds of work produce different kinds of progress. A new feature is easy to demonstrate; a rejected design, a better understanding of a failure mode, or an avoided mistake is much harder to turn into a public update. This experiment allows you to see what it feels like to hold onto that "invisible" progress for a while.

What counts as a result?

From December 1, 2026, onward, participants may share their results if they wish. A "result" does not have to be a polished, finished product. In fact, some of the most interesting results may be the ones that did not "succeed" in the traditional sense.

A result could be:

A completed project or a working prototype.
A technical article, a set of notes, or a clearer explanation of a concept.
Evidence supporting or rejecting a research hypothesis.
A benchmark or comparison of different approaches.
A bug that was finally understood.
A design that was deliberately rejected.
A failed experiment that ruled out a promising idea.
A project that remains unfinished but is now better understood.
A simple account of what did (or did not) change during the month.

You are not required to provide evidence of your private work, share commit histories, or produce screenshots. You do not have to publish anything at all.

If you do choose to share, you might find it useful to reflect on these questions:

Did the absence of public updates change what I chose to work on?
Did I miss external feedback or accountability?
Did I spend less time preparing demonstrations, or did that make no difference?
Was it harder or easier to explain the eventual result?
Would I use this approach for another project?

How to participate

The goal is to keep this initiative low-friction and free of bureaucracy. There are no registration forms, no application processes, and no community servers to join.

Choose your focus: Pick one project, problem, or goal for November.
Work within the rules: Follow the guidelines listed above throughout the month.
Optional Check-in: You may leave a brief comment on this article before November to let others know you plan to participate.
Share later: From December 1 onward, you can return to this article to share your result or your reflections on the experience.

Frequently Asked Questions

Is this against "building in public"?
No. Public development is valuable for feedback, networking, and collaboration. No Ship November is a temporary, intentional alternative to that practice for one specific focus for one month.

Can I continue committing code?
Yes. Local commits and private work are encouraged. The restriction is specifically on making progress about your chosen focus public.

Do I need to publish a result on December 1?
No. That is simply the earliest date allowed for sharing results. You can share whenever you are ready, or not at all.

Hacktoberfest 2026: How to Participate, Earn Rewards, and Join a Local Fest

whaiman — Tue, 13 Oct 2026 17:36:50 +0000

Hacktoberfest 2026: a practical guide to taking part, online and in person

Hacktoberfest changed in 2026. Pull requests no longer count toward rewards. The month is now about building with open-weight models and open-source AI, online and at local events. This guide explains how to take part, whether you join online, at a Fest near you, or both. It works for anyone, anywhere.

I host a Hack Day in Baku, Azerbaijan, and I wrote this first for the people who registered. Everything here applies to any Fest and to the online activities. The last section covers our event.

This guide is not an official MLH or DEV page. Facts checked on 11 October 2026. Dates and rules can change, so check hacktoberfest.com before you plan.

Key dates

9 to 15 October: Global Hack Week, online and free. It starts on 9 October at 12:00 EDT (16:00 UTC, 20:00 Baku time) and ends on 15 October at 13:00 EDT (17:00 UTC, 21:00 Baku time).
12 to 18 October: DEV Challenge, Week 2
19 to 25 October: DEV Challenge, Week 3
26 to 31 October: DEV Challenge, Week 4
All October: livestreams, and Fests in cities around the world
17 October: Hack Day Baku (see the last section)

The Weekend Challenge (2 to 5 October) and Week 1 (5 to 11 October) have ended.

What Hacktoberfest is in 2026

Hacktoberfest 2026 runs all of October. This year's theme is "AI belongs to everyone".

Who runs it: Major League Hacking (MLH) and DEV, presented by DigitalOcean, which started Hacktoberfest in 2014.
Cost: free.
Age: 13 or older, subject to country eligibility rules. Individual Fests can set their own audience and age limits. DEV Challenges have their own eligibility rules.
Formats: online, in person at a Fest, or both. Hundreds of Fests take place around the world.

Pull requests no longer count. The organizers say low-effort and spam pull requests burden maintainers, and AI tools make them easier to produce. Contributing to open source is still encouraged. If you are new to it, start with this beginner guide: https://dev.to/opensauced/open-source-101-a-beginners-guide-to-getting-started-37fb

Set up once, in 10 minutes

Do these steps first.

Sign in to My Hacktoberfest at hacktoberfest.com with a free MyMLH account.
Add your shipping address to your MyMLH account. Steps 1 and 2 are required for any reward.
Connect your DEV account. This is optional, but it gives you a DEV badge and credit for DEV Challenges.
Join the MLH Community Discord. It earns you a sticker.

Some other sticker activities ask you to connect tools such as DevRelay or a DigitalOcean account. These are optional. Read what each tool asks for before you connect it.

How the sticker book works

The sticker book has 24 virtual stickers. Collect them to earn rewards.

Required for any reward: sign in and add your address.
3 stickers: a mailed pack of real stickers.
10 stickers: a bonus holographic sticker in your pack.
15 stickers (Completionist): automatic entry in a raffle for a Hacktoberfest 2026 T-shirt or an Arduino Uno Q board.

Ways to earn stickers:

Check in to livestreams with the code shown on screen. There are stickers for 1, 3 and 5 livestreams, and for the launch livestream.
Submit to DEV Challenges after you connect your DEV account.
Join Global Hack Week: finish the registration challenges, check in to a livestream and reach points milestones.
Connect the optional tools, and complete the pre-event and post-event surveys.
Attend a Fest in person.

Real stickers are mailed after Hacktoberfest ends. It can take a few weeks to a couple of months. See the full list of activities: https://hacktoberfest.com/activities/

What you can join online

You can join from anywhere, all month.

Livestreams. Sessions on open-weight models, agents and tools. Check in with the code on screen to earn a sticker. See the schedule: https://hacktoberfest.com/online/

Global Hack Week: Hacktoberfest. A free, week-long online festival run by MLH.

Dates: 9 October 12:00 EDT to 15 October 13:00 EDT (see Key dates for UTC and Baku time).
Daily workshops on Twitch, with recordings on YouTube.
Mini-events in the MLH Community Discord.
Challenges that earn points.
Details: https://ghw.mlh.com/events/open-source

DEV Challenges. Five challenges with cash prizes. The themes are revealed at launch.

Weekend Challenge: 2 to 5 October
Week 1: 5 to 11 October
Week 2: 12 to 18 October
Week 3: 19 to 25 October
Week 4: 26 to 31 October

You need a DEV account. You can make one submission per challenge. Build a new project during the challenge window with open-source AI at its core, and write about it on DEV. Winners are announced the week after each challenge closes.

Check the exact deadlines and rules on the challenge page: https://dev.to/challenges. Week 1, for example, closed on 11 October at 11:59 PM PDT (06:59 UTC on 12 October). Convert deadlines to your own time zone before you plan.

What happens at a Fest

A Fest is a free, one-day, in-person event. Find one near you by city, country or name: https://hacktoberfest.com/fests/

There are two formats:

Hack Day: a mini-hackathon. You build a project and demo it.
Meetup: talks, workshops or social time. There is no project to ship.

How it works:

Every Fest has its own page with the date, the venue and a register button. Register there with your MyMLH account. Each Fest has separate registration.
Read the Fest's page before you go. It lists the schedule, venue, food, accessibility, check-in instructions and what to bring.
If you are building, bring a laptop and a charger. If not, just bring yourself.
Check in in person on the day.
At a Hack Day, every team member must register and check in.
Come solo or in a team of any size. Prizes cover up to four team members, so larger teams share.
To submit a project, one teammate opens Challenges on the Fest's event page, selects Add Submission, enters the project details, selects the challenges and submits before the host's deadline.
The host chooses the winners.

What you can get:

An official participation certificate in My Hacktoberfest.
A DEV badge, if you connected your DEV account.
T-shirts and event swag while supplies last. They are not guaranteed, and the host decides how to hand them out.
Arduinos at select Hack Days, while supplies last.
A common Hack Day prize is a swag bag with MLH and DEV merch. If a prize is missing because of shipping delays, MLH says it will send a prize of equal or greater value within 60 days after the Fest ends.

Pick your level

Pick what fits your time this month.

15 minutes: sign in, add your address, connect DEV and join the Discord.
1 hour: check in to a livestream. Global Hack Week runs until 15 October.
A weekend: submit a project to a DEV Challenge. Weeks 2 to 4 are still ahead.
One day: join a Fest near you. In Baku, that can be our Hack Day on 17 October.

You can do all four.

Quick answers

Do pull requests count? No. Contributing to open source is still encouraged, but pull requests do not count toward rewards this year.

Is it free? Global Hack Week is free, and almost all Fests are free. A few pop-up Fests take place inside ticketed conferences, so check each event page.

How old do I need to be? 13 or older, subject to country rules. Individual Fests can set their own limits. DEV Challenges have separate rules.

Do I need to build an AI project? A Hack Day is about building a project, and this year's focus is open-source AI. Check your Fest's requirements. DEV Challenges need open-source AI at the core. For a Meetup or a livestream, you do not need to build anything, and beginners are welcome.

Can I come alone? Yes. You can enter a Hack Day alone or in a team of any size.

How do I find a Fest near me? Search the Fests directory by city, country or name: https://hacktoberfest.com/fests/

Who do I ask for help? Use Contact Host on the Fest's event page for questions about that Fest. Email hacktoberfest@mlh.io for swag, prizes and general questions. For harassment or safety concerns, email incidents@mlh.io.

If you are in Baku: Hack Day on 17 October

Hacktoberfest Hack Day Baku x Tea && Compile is hosted by Tea && Compile, a new open-source and Linux community in Baku. It is one example of how a Hack Day works.

When: Saturday, 17 October 2026, 10:00 to 15:00
Where: Coffee Moffie, Baku
Cost: free
Age: 18 and over only
Teams: solo or any team size. We help people find teammates on the spot.
Seats: limited. The host approves registrations.
Register: every person registers separately on the MLH event page and checks in on the day: https://events.mlh.com/events/15529-hacktoberfest-hack-day-baku-x-tea-compile
Bring: a laptop, a charger and a GitHub account.

The day:

10:00 Check-in
10:20 Welcome
10:30 Quick start
10:45 Idea round and teams
About 11:05 Hacking starts
14:00 Wrap-up and project submission on the event's Challenges page
14:15 Demos, 2 minutes each
14:45 Vote and winners
15:00 End

What to expect: there are no cash prizes from the host. The participation certificate is included. Swag, Arduinos and winners' bags are not guaranteed, because the event pack had not arrived when we wrote this.

Before the day, connect your DEV account to My Hacktoberfest so you can receive the DEV badge. Follow us for updates: Telegram https://t.me/teacompile and Instagram https://www.instagram.com/teacompile.baku/

To prepare, read our hack day guide: https://dev.to/whaiman/zero-to-demo-in-5-hours-a-survival-guide-for-your-first-ai-hack-day-3h4d

Useful links

My Hacktoberfest and sign-in: https://hacktoberfest.com
Find a Fest: https://hacktoberfest.com/fests/
Sticker activities: https://hacktoberfest.com/activities/
Online livestreams: https://hacktoberfest.com/online/
Global Hack Week: https://ghw.mlh.com/events/open-source
DEV Challenges: https://dev.to/challenges
Open source for beginners: https://dev.to/opensauced/open-source-101-a-beginners-guide-to-getting-started-37fb
Hack Day Baku registration: https://events.mlh.com/events/15529-hacktoberfest-hack-day-baku-x-tea-compile
Hack day preparation guide: https://dev.to/whaiman/zero-to-demo-in-5-hours-a-survival-guide-for-your-first-ai-hack-day-3h4d
Tea && Compile on Instagram: https://www.instagram.com/teacompile.baku
Tea && Compile on Telegram: https://t.me/teacompile

Zero to demo in 5 hours: a survival guide for your first AI hack day

whaiman — Tue, 06 Oct 2026 21:35:54 +0000

It is 10:00 on Saturday morning. You open your laptop, look at a blank editor, and realize you have no idea what to build. Time is ticking down, and you feel tempted to plan a massive application that takes weeks to construct. You do not need a complex architecture or a full product to succeed today. This survival guide gives you a practical framework to scope an idea, set up tools, build a working prototype, and present it in five hours.

If you are near Baku, you can join us for Hacktoberfest Hack Day Baku x Tea && Compile. We gather on Saturday, 17 October 2026, to build small open-source AI projects together and practice our skills. Whether you are attending an event or hacking alone at home, these steps will keep you on track.

Shrink your idea until it fits in five hours

Before committing to an idea, search GitHub, Hugging Face, and the web for similar projects for 10 minutes. This 10-minute search is my most recommended habit. If you find an existing project, you have three clear options: use it as a base, copy its approach with your own twist, or build your own version. Building your own version is a valid choice and a great way to learn. It often results in a tool that is simpler or more convenient for your own needs. Searching first ensures you make this choice on purpose instead of accidentally duplicating effort without knowing it.

To keep your project manageable, write your goal in one simple sentence using this fill-in template: "[Who] pastes [input] and gets [output]."

Here are three right-sized example ideas that fit this template perfectly:

A student pastes error logs and gets a plain English explanation with two fixes.
A writer pastes a draft and gets three alternative title suggestions.
A developer pastes a shell script and gets a brief security review.

Now consider an idea that is too big: an automated AI agent that scans your entire repository, writes missing tests, creates pull requests, and updates your deployment scripts.

To shrink this oversized idea into a realistic five-hour project, drop the background workers, automated triggers, database connections, and pull request creation. Reduce it to a single script or web interface: a developer pastes one function and gets two unit tests. That smaller scope gives you a clear target you can finish and demo before time runs out. When you focus on a single input and output, you cut complexity and make a working feature much more likely.

Set up your toolbox in thirty minutes

If setup takes more than 30 minutes, switch to a simpler route.

Route	What it needs	Who it suits	Main catch
Local open-weight model (LM Studio)	Local memory and storage	Developers prioritizing privacy	Downloads large files before starting
Hosted open-weight model (Groq, OpenRouter)	Internet connection and API key	Anyone needing quick responses	Dependent on active network connection
AI coding assistant as pair programmer	Code editor extension	Developers seeking boilerplate code	Generates code that requires debugging

Hugging Face Spaces is a different kind of hosted route: a place to publish and share a demo of your project.

I am not sponsored by, paid by, or affiliated with any tool or company named in this article.

My laptop has integrated graphics, shown in Windows Task Manager as AMD Radeon 650 (TM). On this machine, I ran several models locally in LM Studio: google/gemma-4-12b-qat, google/gemma-4-e4b, qwen/qwen3.5-9b, mistralai/mistral-nemo-instruct-2407, and mistralai/mistral-7b-instruct-v0.3. The QAT in google/gemma-4-12b-qat stands for quantization-aware training, a method that makes a model smaller so it needs less memory.

These local models were slow. They were slow enough that you could leave, make another cup of tea, and come back to compile the code. Even so, they were usable for long work, and I could keep giving them tasks for a whole day. The real limit was the context window, which did not last a full day of continuous work. Slow local models suit patient tasks that run in the background, while a hosted route is usually the better choice when you need quick back-and-forth during a five-hour hack day.

For hosted options, I have used Hugging Face Spaces and Groq for my own projects. OpenRouter also offers free models as an option for readers.

Build your project in thin working slices

To finish a functional project in five hours, break your time into structured blocks and commit your code about every 30 minutes.

At our event, check-in, the opening and the demos use part of the day, so the build window is closer to three hours. Keep the same order and shrink each block: an end-to-end version in the first hour, and features frozen about 45 minutes before the wrap-up.

Spend the first 30 minutes on preliminary planning and setup: complete your 10-minute search, write your one-sentence idea, choose your toolbox route, and set up a public repository.

From 0:30 to 1:30, focus entirely on building the ugliest end-to-end version possible. This version only needs to take sample input, send it to a real model, and print the raw output on screen. Do not spend time styling buttons or polishing text.

From 1:30 to 3:30, refine the core logic so it works on real input. Fix basic execution errors, clean up output parsing, and ensure your core user flow completes reliably every time.

From 3:30 to 4:15, freeze all new features. Stop adding extra buttons or options, and focus on fixing the specific path you plan to show in your demonstration.

From 4:15 to 5:00, finish documentation and presentation details. Write your minimum README, push your final code, run through two full rehearsals to check your timing, and record a clear backup video.

Publish your code as open source

Create a public repository within your first 30 minutes, right after your idea check, rather than waiting until the end of the day. Publishing early encourages you to write clean code, keep secrets safe, and maintain a clear commit history throughout the event. Pick an open-source license early by reviewing choosealicense.com. An open-weight model shares its trained weights, while open-source software grants full rights to inspect and modify code. License terms vary across model providers, so always check the license before building.

Your README file needs four essential elements: a clear statement of what the project does, step-by-step instructions on how to run it locally, one screenshot showing the output, and the exact model identifier you used. Keeping a tidy README makes it easy for other participants to understand your work.

Never commit API keys or secret credentials to a public repository. Store secrets in a local environment file and block that file from git tracking with a .gitignore file. Create both before your first git add. This simple setup prevents secret leaks and ensures anyone can clone your project safely:

The .env file:

API_KEY=your_secret_key_here

The .gitignore file:

.env

First, create an empty repository on GitHub, with no README or license file on the GitHub side, so your first push is not rejected. Then run these commands in your project folder, using the HTTPS address that GitHub shows you:

git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/username/repository.git
git push -u origin main

After that, push small updates on a regular schedule.

Deliver a clean two-minute demo

A great project can fail if the presentation is messy. Structure your two-minute presentation using a strict timing script:

Problem (15 seconds): State the specific user pain point you set out to solve.
Live run (60 seconds): Show your application processing a single input and generating an output in real time.
How it was built (30 seconds): Explain your choice of model, interface, and framework.
What comes next (15 seconds): Share one logical next step for future development.

To protect yourself against live technical failures, prepare one specific input that you know works perfectly. Do not test a new query live on stage.

Shared venue Wi-Fi can be slow when many people use it at once. Record a screen video of your working demonstration before the final deadline. If the local Wi-Fi drops, you can play your backup recording and present your project without interruption.

Five ways a hack day goes wrong

Avoid these five common failure modes during your build day:

Scope too big: You attempt a complex multi-page web app. Fix: Stick to one user, one input, and one output.
Setup eats two hours: Drivers fail to configure properly. Fix: Switch to a hosted API if setup exceeds 30 minutes.
Rewriting instead of finishing: You change frameworks midway. Fix: Stick with your chosen stack until done.
Nobody commits until the end: Code progress gets lost or overwritten. Fix: Push small updates every 30 minutes.
Nobody rehearses: Your demo exceeds the strict time limit. Fix: Practice twice and save a backup video.

A checklist for your build day

Use this checklist to track your progress throughout the five hours:

☐ One-sentence idea checked against a 10-minute search
☐ Public repository created with a minimum README
☐ Working end-to-end version completed by the 1:30 mark
☐ API keys and private secrets excluded from the repository
☐ One reliable demo input tested and ready
☐ Backup screen recording saved locally

Join us in Baku on 17 October

If you are in Baku, come join us for Hacktoberfest Hack Day Baku x Tea && Compile. We are meeting on Saturday, 17 October 2026, from 10:00 to 15:00, at Coffee Moffie in Baku. The event is free to attend for ages 18 and over. Seats are limited, so register on the MLH event page first.

I host this event to promote open-source models and open-source ideas in Baku, and to let people try them by building something real.

If you cannot attend in Baku, follow these steps wherever you are. Share what you build in the comments below so we can see your work.

Why Next.js Feels Like Flask, Rewritten in TypeScript

whaiman — Sun, 30 Aug 2026 10:59:04 +0000

I spent over a year writing backend code in Flask. When I started a new project, I decided to try Next.js. The first thing I noticed was déjà vu. This felt like Flask, rewritten in TypeScript with a newer take on rendering.

React itself works well for me - a tidy component library, nothing more. Next.js is what I fell for, the App Router most of all. The deeper I dig, the more it looks like a classic server-side framework, with extras Flask would never build on its own.

My Flask experience isn't from tutorials. I built FileServer on it (the project is moving to FastAPI now, since the old code stopped scaling). That work is what showed me how much these two tools overlap in concept.

Templating and layouts

In Flask with Jinja, you build a base.html with a {% block content %} block, and users.html extends that template. Header, footer, navigation - written once, not copied on every page.

Next.js does the same job with layout.tsx. You set it at the folder level, and every page inside wraps in it, no extra code needed. App Router lets you nest layouts at any depth - /admin gets its own layout on top of the shared one. Flask can do this too, through several levels of {% extends %}, but by hand it feels less clean.

Server rendering by default

My first guess: TSX is Jinja with a different syntax. Close, but not exact.

A component in Next.js defaults to a Server Component. It renders on the server, and the browser gets finished HTML, the same way it does after Jinja.

A component turns client-side only when you add 'use client' at the top of the file. That's the real parallel with Flask. Flask never gives you the choice - everything runs on the server. Next.js gives you the choice, and you can mix server markup with interactive pieces in the browser.

Data fetching

In Flask, you write the data-fetching logic right in the route, then pass it to the template:

@app.route('/users')
def users():
    users = db.get_all_users()
    return render_template('users.html', users=users)

In Next.js, Server Components let you do the same thing inside the component itself, with no extra API endpoint to build:

// app/users/page.tsx
export default async function UsersPage() {
  const users = await db.user.findMany();
  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>;
}

It still feels like writing backend code.

Dynamic routes

Flask: @app.route('/user/<int:user_id>'), and user_id arrives in the function as an argument.

Next.js uses the same idea with square brackets in the folder name: app/user/[id]/page.tsx, and you pull it out as params.id. Different syntax, same idea - a piece of the URL becomes a variable.

Form handling

In Flask, you build a form, set method="POST", and catch the data on the backend through request.form.

Next.js added Server Actions. You write an async function on the server and attach it to the <form> tag with no extra wiring:

async function createUser(formData: FormData) {
  const name = formData.get('name');
  await db.user.create({ data: { name } });
}

<form action={createUser}>
  <input name="name" />
  <button type="submit">Create</button>
</form>

It's the same old POST request, packaged in newer syntax. You don't need a separate API route for simple mutations.

API and HTML in one app

A single Flask app holds /users, which renders HTML, next to /api/users, which runs jsonify(...) and returns plain JSON. One server, two kinds of response.

Next.js works the same way: app/users/page.tsx returns a JSX page, and the neighboring app/api/users/route.ts returns JSON. This is also how I plan to build the FastAPI backend for FileServer - API on one side, frontend on the other, an idea I picked up from the Flask version of the project.

Request lifecycle: middleware

Who sees a request before it reaches your code? In Flask, @app.before_request handles that - a function that runs before every route. Useful for checking auth or logging.

Next.js has middleware.ts at the project root for the same job. It catches the request before it reaches the page, and that's where you handle redirects or check a cookie. It matches before_request almost exactly.

Grouping routes

Next.js has Route Groups - a folder in parentheses like (auth) that groups routes logically without showing up in the URL.

Flask solves the same problem with Blueprints: move the auth routes into one blueprint, the admin routes into another, then register both on the main app. The mechanics differ, but the motivation matches - don't dump every route into one flat pile.

Caching and static files

In Flask, to keep from hitting the database on every request, you add a @cache.cached(timeout=50) decorator.

Next.js builds this into the core, under the name ISR (Incremental Static Regeneration). You export a config variable:

export const revalidate = 60;

Redirects and request context

In Flask, you use redirect(url_for('login')) to send a user elsewhere. For headers, you import the global request object.

In Next.js server code, you do the same thing through dedicated functions instead:

import { redirect } from 'next/navigation';
import { headers } from 'next/headers';

if (!session) redirect('/login');

const token = headers().get('Authorization');

The takeaway

People often file Next.js under "yet another SPA framework." Under the hood, App Router runs a solid server framework that does what Flask does, then lets you drop in client-side JavaScript exactly where you need it. If you know Flask well, Next.js won't take long to pick up. The concepts stay the same. Only the syntax changed.

Why the "AI" Badge Doesn't Matter and How to Restore Trust in Our Code

whaiman — Sun, 16 Aug 2026 12:01:43 +0000

Hello, DEV community! 👋

This is my first post here. I've been reading articles on this platform for a while, but a recent article by @pascal_cescato_692b7a8a20 - "The "AI" Badge Doesn't Measure What You Think It Does" - finally pushed me to join the conversation.

It touches on a topic that's been on my mind for a while: the "AI-generated" badge, which is being actively pushed across media platforms, doesn't actually tell us anything useful.

Whose thought is it anyway?

As Pascal brilliantly breaks down, we constantly conflate three fundamentally different ways of working:

Assisted. When the idea, structure, and artificial decisions belong entirely to the human. A model is used to rephrase, translate, fix regex, or pressure-test arguments.
Generated. A human gives a prompt, but the model produces the actual thought and text.
Produced. Automated pipelines generating content at an industrial scale without human oversight.

A binary badge (or statistical watermark) treats all three identically. An engineer who spends hours architecting a system, writing core logic, and using LLM to polish a comment or write boilerplate get shoved into the same bucket as an automated spam farm.
The real line of ownership isn't drawn by how much a model intervened, but by who kept their hand on the decisions. Who designed the solution? Who discarded the bad outputs? Who took responsibility for the final architecture?

Proof of work instead of broken labels

Detectors and badges look at the final shape of a file and guess its origin. But as Pascal proved by running his 2021 pre-LLM article through ZeroGPT (getting scores ranging from 97% to 8.6%), detectors merely chase stylistic neutrality, not actual origin.

We are seeing the exact same flaw happening in programming. Today, there are various code analyzers and enterprise tools designed to detect "AI-generated code". While writing software is fundamentally different from writing prose, the detection methodologies share the exact same underlying bias.

Just as text detectors flag well-structured, pedagogical paragraphs as "AI," code detectors often flag clean, canonical, and boilerplate code. If an engineer writes a textbook algorithm, strictly follows naming conventions, or implements standard design patterns, they risk being falsely flagged. The detector mistakes professional standardization for machine generation. It judges the final shape without knowing the process.

This exact problem led me to create dev-ledger - an open-source VS Code extension designed as a conceptual evolution of time-trackers like WakaTime.

But unlike traditional trackers that send your activity to a third-party server, dev-ledger is 100% local-first. All data collection and behavioral analysis happen directly on your machine - no APIs, no telemetry, no cloud. To guarantee the authenticity of your timeline, it secures your local event log with a cryptographic hash chain. It gives you a mathematically tamper-proof "Proof of Work" that you fully control, without sacrificing your privacy.

Instead of slapping a meaningless "100% Human" or "AI Generated" badge on a project, this approach shifts the focus back to transparency. By unobtrusively recording keystrokes, active editing time, and structural modifications, it documents the actual process - the iterations, the refactoring, and the human effort behind a codebase. It then converts this data into automated reports and visual SVGs for your README.md, backed by an integrity hash.

When someone looks at a repository equipped with this kind of timeline, they don't have to blindly trust a flawed detector or guess the code's origin based on its "final shape." They can actually see the chain of decisions and the problem-solving process that went into building it.
We probably can't stop platforms from implementing broken AI detectors or pushing binary badges. But as engineers, we can choose to shift the conversation back to what actually matters: the depth of our thought and the transparency of our work.

If you share this philosophy and want to secure the integrity of your own coding sessions, you can check out the source code and try the extension here:
👉 github.com/whaiman/dev-ledger

(Feedback, GitHub stars, and PRs are deeply appreciated!)

What Metrics Cannot Fix

Building a cryptographic ledger for development activity solves the technical problem of proving effort, but it doesn't fix the social one.
Having a verified hash chain won't stop a cynical reviewer on Reddit or Hacker News from glancing at a clean, well-structured repository and dismissing it as "LLM slop." Just as in writing, the technical demonstration and the social judgment are two completely different things. Often, the reflexive rejection of code as "AI-generated" has nothing to do with the code itself - it’s just a blunt reaction to the anxiety of our industry's current transition.

If badges can't measure origin, and enterprise code detectors can't measure thought, then the question in modern software engineering isn't "who typed this line?" but "who holds the steering wheel?"

Software architecture is fundamentally about making trade-offs, not just generating syntax. An LLM might help write a boilerplate function or figure out a tricky regex, but it doesn't conceptualize a local-first system. It doesn’t weigh the security implications of a cryptographic hash chain against a centralized database. The engineering intent - the real heavy lifting - remains entirely human.

When we reduce a developer's contribution to a binary label, we erase the unseen hours spent designing data models, debugging AI hallucinations, and rejecting bad abstractions. We erase the actual engineering.

Code analyzers and enterprise detectors will only ever scan the final repository. They parse the Abstract Syntax Tree (AST) looking for generic patterns, completely blind to the iterative struggle that brought that structure into existence. But true ownership of software isn't found in the finalized syntax. It lives in the problem-solving, the discarded ideas, and the chain of architectural choices that made that code necessary in the first place.