DEV Community: MLH Team

Prompt Pad: What Are Tokens?

MLH Team — Thu, 12 Nov 2026 20:34:29 +0000

Your AI doesn't read your prompt word for word. It reads tokens.

In this episode of Prompt Pad, @rosendo_pili explains tokens, the atomic units of text that an AI actually reads and calculates.

The tip in a nutshell

Before an AI reads your prompt, your text is converted into numbers using a process called tokenization. Each token becomes a number, and those numbers are what the model actually calculates with to generate a response.

Everything we've covered in Prompt Pad so far, from framing a persona to few-shot examples, reaches the model as tokens. Understanding them gives you a clearer picture of what happens between hitting enter and getting an answer.

Try it yourself

Take a prompt you use often and think about how it might be split into tokens. Share your guesses (or any surprises) in the comments 👇

📣 Help us spread the word

Know someone curious about how AI really works? Send them this video. And subscribe so you don't miss the next Prompt Pad tip:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

Can you merge at agent speed?

MLH Team — Thu, 12 Nov 2026 17:40:59 +0000

Major League Hacking and Entire are teaming up for a year of hackathons, DEV Challenges, and a new prize that puts the first Git forge for agent-human collaboration in hackers’ hands

Picture this: you’re 14 hours into a hackathon. You’ve got multiple agents running, you’ve tried three different approaches, and somewhere between your fifth coffee and your tenth prompt, you finally crack it. You’re ready to ship something you’re proud of and you hit your Git platform.

Your code goes through pull requests designed for humans reviewing human-generated code. And when your session ends, everything your agent learned about the project ends with it. The next prompt starts from scratch. Today’s Git forges were built for a human-paced loop, not for developers collaborating with agents.

That's why we're partnering with Entire, the Git forge for agent-human collaboration, founded by former GitHub CEO Thomas Dohmke. Our partnership will help developers across the MLH and DEV community to merge changes as fast as their coding agents create them, and to capture, share, and learn from how they build with AI.

Where AI habits get formed

There's no shortage of predictions about how AI will change software development. We don't pretend to have all the answers, but we have a pretty good idea of where some of them will come from.

Every weekend at hackathons around the world, hackers show up with technologies they've never used and ideas they're not sure how to execute. They try things, break things, learn from each other, and sometimes find approaches that surprise the people who built the tools.

Developers are still figuring out how to work effectively with AI agents. The habits they develop today, the tools they adopt, and the lessons they share will influence how software gets built in the years ahead. We want our community to have a hand in shaping that future, not just adapting to it.

Meet Entire

On October 26, Entire launched the first Git forge built specifically for agent-human collaboration. Here are the highlights:

Trails. Unlike the classic pull request model of reviewing code changes with a diff, Trails offers developers a heads-up display similar to an airline pilot, with automated customizable evals that are scored by agents on every code push.
Distributed Git hosting. Entire is built on a new source control server compatible with Git, which pushes up to 89x faster than GitHub and 6x faster than Cursor Origin. You can host your repo and replicate it in multiple regions around the world, offering data residency and scale for agentic traffic.
Continuous Memory, a new approach for agents and developer teams that sync sessions and prompts into the Git repository, and makes that data constantly available and searchable to coding agents. It includes Graph, which maps how your codebase fits together, and Brain, which turns past sessions into memories your agents can query.

And then there’s Sessions: the open-source Entire CLI saves your agent sessions as checkpoints linked to your commits, so your team can see the prompts and reasoning behind each change. Put together, it’s a Git forge built for the way developers collaborate with agents today.

For a hackathon team racing the clock, that means the ability to reason over the code your agents create so you can merge as fast as they write it, less time re-explaining context to your agents, fewer burned tokens, and a way to show something that’s always been hard to demo: the thinking behind the project.

What MLH and Entire are doing together

Over the next 12 months, Entire will show up across MLH and DEV through hackathon prizes, DEV Challenges, and direct feedback.

A new prize: Best Use of Entire. At 150 MLH hackathons across North America, Europe, and Asia, teams can compete for a prize that rewards smarter AI workflows. Use as much of Entire as you can: Sessions to hand off context to teammates and agents, Graph to map your codebase and cut token usage, Brain so your agents remember past decisions, and Trails to assign and review agent work. Judges are looking for seamless human-AI collaboration, clean code history, and measurable token efficiency. Winners take home a mini portable projector, and MLH staff on-site will help you get set up.

Two DEV Challenges. Not every idea fits in a 36-hour weekend. Entire will sponsor two DEV Challenges where you can explore its tooling at your own pace, build something, and write about what you learned. And unlike a weekend demo, those posts stick around for the next developer to learn from. Themes, dates, and prizes coming soon.

A direct line to the team building the tools. Hackathons are a great stress test. When you've got a weekend to build, you find out fast whether a tool is helping or getting in your way. MLH will work with community members to test Entire's tools and docs, flag friction, and bring that feedback straight to Entire's team. If a tool is supposed to make developers' lives better, developers should have a say in how it works.

None of this starts from scratch. Thomas kicked things off with a keynote at HackGT in September, and Entire joined us for Hacktoberfest 2026, where their team went live on DEV with the community and hackers took home Entire prizes in our Hacktoberfest Open-Source AI DEV Challenges. Now we’re taking it on the road.

Mike Swift, CEO & Co-Founder, Major League Hacking

“When Thomas started Entire, we knew it was a natural fit for our community. At a hackathon you have one weekend to turn an idea into something real, and your agents have to keep up with you. Entire is built for that kind of speed, and it keeps the reasoning behind the code instead of losing it. Hackers are already building on top of it: Abdul Wasih built Viva, a mock interview tool that reads your Entire sessions to find the code an AI wrote, then quizzes you on it. That’s what happens when you put new tools in front of this community. This is a dream partnership for us, and we think capturing how software gets built, not just what ships, will be table stakes for AI coding.”

“Many developers make their start at hackathons, and MLH is among the very best, giving them a third space beyond the classroom or office where they can find community, get hands-on with the latest technologies, and build at the pace of the industry,” said Thomas Dohmke, Entire CEO. “We’re proud to partner with the MLH team to bring our Git forge to the next generation of developers. Many are already agent natives with a new kind of technical leverage. They’ll set the standard for how humans and agents create software together. We built Entire for this new world, and we can’t wait to see what they ship.”

We can’t wait to see what you build. And this time, we might get to see a little more of how you got there.

Prompt Pad: Show Your AI How to Respond with Few-Shot Examples

MLH Team — Fri, 06 Nov 2026 16:00:00 +0000

Want AI to answer in a specific way? Don't just tell it. Show it.

In this episode of Prompt Pad, @rosendo_pili explores few-shot prompting: giving your model a few examples so it knows exactly how you want it to respond.

The tip in a nutshell

Describing the output you want only goes so far. When you include a handful of example inputs and responses in your prompt, the model picks up on the pattern and follows it, whether that's a specific format, tone, or style. Instead of guessing what "good" looks like, it has a model answer to work from.

Try it yourself

Pick a task where the AI's responses keep missing the mark. Add two or three examples of what a great answer looks like, then run your prompt again and compare. Share your before-and-after in the comments 👇

📣 Help us spread the word

Know someone who's tired of explaining what they want to AI over and over? Send them this video. And subscribe so you don't miss the next Prompt Pad tip:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

Prompt Pad: What Are Open-Weight Models?

MLH Team — Thu, 05 Nov 2026 21:00:19 +0000

When people call an AI model "open," they don't always mean the same thing.

On this week's Prompt Pad, @rosendo_pili breaks down open-weight models using Google's Gemma as an example.

The difference

An open-weight model gives you the trained model itself. You can download it, run it on your own machine, and fine-tune it for your project.

Open-source asks for more. It means the full recipe is available to study, change, and share: the code, and for AI, details like the training data and process.

Your Turn

What would you build with a model that never has to leave your laptop? 👇

📣 Help us spread the word

Know someone who thinks "open" always means open source? Send them this video. And subscribe so you don't miss the next Prompt Pad episode:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

Prompt Pad: What Is Open Source?

MLH Team — Wed, 04 Nov 2026 14:00:00 +0000

Chances are you're already using open-source software without realizing it.

In this episode of Prompt Pad, @rosendo_pili steps back from prompting to explain what open source is and why you should care.

Why it matters

Open source runs much of the world's software, including many of the AI tools and models people use every day. Anyone can read the code, learn from it, and help make it better. That includes you, whether you write code or not.

Your Turn

Tell us in the comments: what's an open-source project you rely on without thinking about it? 👇

📣 Help us spread the word

Know someone who's curious about open source? Send them this video. And subscribe so you don't miss the next Prompt Pad episode:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

Prompt Pad: Lock Your AI's Output Schema in Google AI Studio

MLH Team — Tue, 03 Nov 2026 14:00:00 +0000

If you've ever tried to parse an LLM response in code, you know the pain: the format changes slightly from one run to the next and your parser breaks.

In this episode of Prompt Pad, @rosendo_pili shows how to lock your model's output schema in Google AI Studio so that every response follows the format you define. 🔒

Why it matters

Asking for JSON in your prompt is a request. A structured output schema is a guarantee. Once the schema is locked, your app gets clean, predictable responses it can rely on, and you no longer need regex workarounds to clean them up.

Try it yourself

Open Google AI Studio, define a schema for something you're building, and see how much simpler the code that consumes the output becomes. Let us know what you build in the comments 👇

📣 Help us spread the word

Know someone fighting with messy AI output? Send them this video. And subscribe so you don't miss the next Prompt Pad tip:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

Prompt Pad: Frame Your Persona for Better AI Answers

MLH Team — Mon, 02 Nov 2026 20:09:37 +0000

Want better answers from AI? Start by telling it who to be.

In this episode of Prompt Pad, @rosendo_pili shows how setting your model's persona in the system prompt immediately improves the quality of its answers.

The tip in a nutshell

Before you ask the question, give the model a role. "You are a senior backend engineer reviewing a pull request" gets you a very different answer than a bare "review this code." A persona tells the model what expertise to draw on, what tone to use, and what a good answer looks like.

Try it yourself

Pick a prompt you use often and add a one-line persona to the top. Compare the two answers side by side. Then share your best persona in the comments 👇

📣 Help us spread the word

Know someone whose AI answers could use an upgrade? Send them this video. And subscribe so you don't miss the next Prompt Pad tip:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

Welcome to the Prompt Pad: AI Tips & Tricks with Rosendo Pili

MLH Team — Thu, 29 Oct 2026 19:07:55 +0000

Keeping up with AI is a full-time job. Prompt Pad is here to help you keep up a little at a time.

Prompt Pad is a new short-form video series, hosted by @rosendo_pili. Each episode covers one practical tip you can use right away. It doesn't matter whether you're brand new to AI or have been shipping LLM features for years.

What to expect

Short and to-the-point. Every episode is under a minute.
Practical. One technique per episode, shown in a real tool.
For everyone. No PhD or prior coding experience needed.

We'll post every episode here on DEV as part of this series, so follow along and drop your questions in the comments. Ro might answer them in a future episode.

📣 Help us spread the word

If you know someone who's trying to get better at AI, send them this video. And subscribe so you don't miss an episode:

▶️ YouTube: @MajorLeagueHacking
📸 Instagram: @mlhacks
🐦 X: @mlhacks
💼 LinkedIn: Major League Hacking
💬 Discord: Join the MLH community

How to Get Your First Tool Online

MLH Team — Wed, 24 Jun 2026 20:58:21 +0000

TL;DR -
A finished app that only runs on one laptop is a private demo. Getting it online means connecting three things: a place to store the code (version control), a place to run it (a host), and an address people can type (a domain). The same AI tool that helped build the app can walk a beginner through all three, often without ever opening a terminal. An important step you don’t want to skip is the security check before going live, because the fastest way to ruin a launch is to ship with the database wide open.

So you’ve done it. You built your first tool. And it works. The button does the thing. Now’s the moment. It’s time to get your tool online, but how? A project running on a laptop is real, but it lives in exactly one place, the machine it was built on. Nobody else can open it.

Getting that project online is its own small skill, separate from building, and it trips up more beginners than the building did. A new coder can finish a working photo booth app in an afternoon and still have no idea how to hand it to a friend short of pulling up the GitHub link while sitting together over coffee. The good news is that the part that used to eat a whole weekend now takes a conversation.

Three Things Every App Needs to Go Live

Almost every deployment, whatever the tool, comes down to three things working together.

Version control: This is a place to store the code and track every change made to it. For most people that means GitHub, which we’ve talked about before. The same way Google Docs keeps a version history, GitHub keeps one for a project. This piece does not re-explain it; the GitHub walkthrough covers the whole thing.
A host: A host is really just a computer that stays powered on and connected to the internet with a public address of its own. When a visitor types in the app's address, their browser sends a request across the internet to that machine, the machine runs the code, and it sends the finished page back. A laptop was quietly doing both jobs during the build, the server and the only visitor allowed in; a host is that same server moved onto an always-on machine the whole world can reach. Services in this category include Cloudflare Pages, Render, Vercel, Netlify, and they often have a free tier that is plenty for a first project. But do your research on what restrictions come with that tier and think about whether they hold you back more than you want.
An address: The domain people type to find the app. A host hands over a working web address on day one. A custom domain is an optional upgrade that swaps something generic for a name the builder owns, which can give you more control over how people perceive your tool (aka branding). Custom domains typically cost a few dollars a year and can be purchased on services like Hover, Netlify, Vercel, Cloudflare, Dreamhost, Porkbun, and GoDaddy.

Going live is mostly the act of connecting these three. The code lives in version control, the host reads from it, and the domain points at the host. Three things to check off a to-do list and you’re live!

The Path of Least Resistance When You’re Building Your First Tool

The simplest way to get started just requires a chat window. You describe what you want, the AI writes the code, and a back-and-forth shapes it into something that works. That is exactly how the photo booth project came together. Getting it online publicly is the same move, continued. The builder asks how to put the project on the internet, and Claude would have handed back a short list of steps: download the code to your own machine, create a GitHub account and push the project to it, then connect that repository to a host. Each step is something the builder runs themselves, with the AI explaining the unfamiliar parts as they come up.

On this path, the person is the courier. The code travels from the chat, to their computer, to GitHub, to the host, and the software creator carries it across each gap by hand. It sounds like more work than it is. Another example from one of DEV’s co-founders described a friend with no technical background who got a full website live exactly this way, using nothing but a consumer AI chat. He described what he wanted, followed the numbered instructions, and it worked. The courier path is the whole job for plenty of first projects, and it asks for no new software beyond a browser and an account.

The step up from there is an editor with a built-in agent like Cursor, Google Antigravity, Windsurf, or VS Code with a coding extension. These are code editors with an AI agent living inside them, and the difference is the responsible party for getting things from place to place. Instead of the software creator shuttling code between windows, the AI agent edits the project files directly and runs the GitHub and deploy steps independently. The flow looks like this: start in a conversational build tool like Google AI Studio, describe the thing in plain language, tweak it until it looks right, then open the code in the editor. From there it is a conversation. Connect to GitHub. Pick a host. When it is time for a custom domain, tell the agent where the domain was purchased and ask which fields to update.

That last detail is the real shift, and it holds on either path.

What makes deployment to life intimidating is rarely the concepts. It’s a dozen tiny configuration fields with names a beginner had never seen…and in their mind, each one is a chance to get something wrong. Now those fields come with a guide that explains each one on request, whether that guide lives in a chat window or inside the editor.

AI Editor or Terminal?

A common fork shows up here. You can do this through a visual editor, or through the terminal, the black command-line window many beginners dread simply because they haven’t used it before, and it looks like you could do real damage if you mess up. For a first deploy, the editor usually wins, and the reason is as much psychological as technical.

In an editor, a beginner can see the files and watch the changes happen. The terminal gives back only text, and when something goes wrong it can feel like a black box. Seeing the project is more grounding, and grounding is what keeps a first-time developer in the chair instead of closing the laptop.

Don’t fear the terminal. It’s worth learning eventually. It does not have to be day one. For more on how this conversational, agent-led way of working took hold, the vibe coding explainer sets the stage.

Don’t Hit Deploy With the Door Open

The moment an app goes live, it stops being private. So this is a valuable moment to stop, review, and check all your work.

Anyone can reach a live thing, including people looking for an unlocked database to exploit. There are real news stories, more than one in the past year, about apps that shipped with their data wide open and leaked every user’s information within hours of launch.

Senior builders run a pre-flight checklist before every launch for exactly this reason. A beginner does not need a hundred items, but they do need the habit. Some AI coding tools now run a basic security pass on their own and will flag an exposed database before it ships. The rest is asking the right questions. What did this skip? What would a real product lock down? Is anything sensitive sitting somewhere public? That is the same build-then-audit move covered in the auditing guide, applied at the exact moment it matters most.

Where to Build This With Other People

Getting a first thing online is a milestone worth not reaching alone. A MLH hackathon is the perfect place to try: build, break, and deploy alongside other people over a weekend. And DEV is always here for the other parts, open all the time, where a new coder can post the project, ask for feedback, and read how someone else cleared the same hurdle.

(The thing that goes live is better for having an audience that was rooting for it.)

FAQ

Do I need to know how to code to deploy an app?
No. A non-technical person can get a site live using a consumer AI chat that hands over step-by-step instructions. Knowing the underlying concepts helps later, especially for security, but it is not a barrier to a first deploy.

What is the difference between GitHub and a host?
GitHub stores the code and tracks its changes. A host runs the code and serves it to visitors. They are two different jobs, and a typical setup connects them so the host reads the latest code from GitHub. More on version control in the GitHub walkthrough.

Do I have to buy a domain?
No. A host provides a working web address as soon as the app is live. A custom domain is an optional upgrade for a name the builder owns for a few bucks a year.

Do I have to use the terminal?
Not for a first deploy. An editor with a built-in AI agent is friendlier and easier to follow, because the files and changes stay visible the whole way through.

What is the most common first-launch mistake?
Going live without checking security, especially leaving a database open to the public. A quick audit before deploying prevents the worst of it. See the auditing guide.

Your Vibe-Coded App Works. Is It Any Good?

MLH Team — Thu, 11 Jun 2026 19:00:35 +0000

TL;DR -
Getting an app to run is now the easy part. AI is very good at producing something that works on the first try and is indifferent to whether it should ship. The skill that separates a software experimenter from shipping and sharing their creation with the public is the work that starts after the demo: checking whether the thing does what it was meant to, whether anyone’s data is exposed, and whether the person who built it can explain how it works. The move is build first, then audit. The fastest way to learn how and what to audit is to turn the same AI that built the app into the thing that interrogates it, and to start keeping a running list of everything that has ever broken.

The app runs. The demo works. It’s deployed to a real URL that a person can send to a friend. For most people building with AI for the first time, that is the finish line. In reality it is closer to the halfway point.

“Works” and “good” are two different questions, and they tend to get answered by two different things. A modern AI agent is remarkably good at the first one. Describe what is wanted, and it will produce something that runs, often on the first try. Whether that something is any good – whether it is secure, whether it does what was actually intended rather than what was demonstrated, whether it will hold up when someone other than its creator uses it – is a separate question that AI agents are much less reliable about. That question is where the real work, and the real learning, lives.

This is the natural next step after a first vibe-coded project. The building is done. Here is what to do with the thing that got built.

AI Generates the Bricks. Someone Still Builds the House.

There is a useful way to frame what AI does and does not do in this process: it produces the raw material, not the finished structure. An agent can generate working code in seconds. Whether that code belongs in a thing real people will use is a judgment call, and that judgment has to stay with a person, not the model.

This is the same problem the broader industry keeps circling. The distance between an absolute beginner, a software creator, and a productive developer has never been smaller. But the layer of expertise that used to sit in the middle – the years a developer spent wrestling with real problems on a team, slowly learning what “good” actually looks like – is harder to come by when AI compresses the early part of the journey. The good news for a software creator is that this gap is not just something to worry about. It is something to act on. The act is auditing what gets built, and it can start on the very first project.

A Part Of Software Creation That Nobody Warns You About

Fast can mean exposed. An app that took an afternoon to build can go live and, within hours, leak every piece of data its users handed it.

This is not a hypothetical.

Beginner-built apps have shipped to production with databases left wide open by default, with no authentication on endpoints that should have required it, with secret keys committed straight into public code. The build felt finished because it ran. The part that was missing was invisible until it wasn’t.

The reason this happens so often is structural. When AI handles the setup and the boilerplate, it also quietly handles a hundred small decisions that a person building the slow way would have at least seen go by. Some of those decisions are about security. Most defaults are designed to make the thing work, not to make it safe, and “working” and “safe” are not the same default. A software creator who never learned the underlying concepts may not know what went wrong, may not know where to look, and may not know what to ask next time. But if they treat the audit as part of the job, they have a real shot at catching it before anyone else does.

The Move: Build First, Then Audit

“Audit” sounds like a senior-engineer word, something that happens in a conference room with a checklist and a compliance officer. For a first project it is much smaller and much more useful than that. It is a short set of questions to ask of a thing that already exists. The questions are the whole skill.

Does it do what it was meant to do, or only what it was demoed to do? A demo runs the happy path: the right input, the expected click, the one flow that was rehearsed. Real use is messier.
What happens with an empty field, a wrong file type, a button pressed twice?
Is anyone’s data sitting out in the open? If the app stores anything — an email address, a login, a single uploaded photo — the question is who can reach it. Can a stranger read the database?
Is anything sensitive printed into the code itself?
Could the build be explained to someone else? Not line by line, but in plain terms: what are the moving parts, and what does each one do? An honest “no” here is not a failure. It is the single most useful flag a new builder can find, because it points exactly at what to learn next.
What did the AI quietly skip? Every agent makes trade-offs to get to “it runs.” Error handling, validation, security practices that would slow down a first draft — these are the things most likely to be left out, and the most worth asking about directly.
What happens when it is not just one person using it? An app built and tested by an audience of one behaves differently when ten people, or ten thousand, show up at once. Even imagining that shift surfaces problems the solo demo never could.

None of these require knowing the answer in advance. They require knowing to ask. And the most efficient way to get the answers is to ask the same tool that wrote the code in the first place.

Using AI to Audit AI

The most common mistake with an AI agent is using it as a grunt worker or telling it what to type and accepting whatever comes back. Used as a coach instead, the same tool becomes one of the best ways to learn ever invented. That coaching move applies just as well to evaluation as it does to building. The trick is to point the agent back at its own output and ask it to be critical.

A handful of prompts do most of the work:

“Walk me through this code line by line and explain what each part does.”
“What security practices did you skip to get this working?”
“What would you change about this before real people used it?”
“Where is user data stored, and who can access it right now?”
“What would a senior engineer flag in this code?”

The answers do two things at once. They surface concrete problems to fix, and they teach the concepts behind those problems in the exact context where they matter. A new builder who reads the explanation of why a database connection was insecure learns more about security in five minutes than a week of abstract tutorials would deliver, because the lesson is attached to something they made and care about.

This is the difference between a coach and a crutch. Asking AI to explain why code works the way it does, to unpack what it skipped, to walk through its own reasoning, is learning. Letting it write the project while nodding along, then letting it declare the project finished, is the same trap as following tutorials forever…just with a chatbot instead of a video.

Start Your Own Pre-Flight Checklist

Experienced developers often build a personal checklist they run before launching anything, sometimes dozens of items long, built over years of successful and unsuccessful launches. Each line on it represents a specific thing that broke once, badly enough to be worth never repeating. The checklist is not something they were handed. It is the compressed record of everything that has ever gone wrong.

A software creator can start one immediately, and it will be one of the highest-return habits in the whole process. The first version might have a single item on it. Every time something breaks, or an audit turns up a problem, or the AI points out something that was skipped, it gets one more line. Over months, that growing list becomes the thing the missing middle layer used to provide: a hard-won sense of what to check, what tends to go wrong, and what “done” actually means.

This is also where the accumulated questioning pays off. Each audit adds to your list. The list makes the next audit faster and sharper. Over time the questions that once had to be looked up become the questions a builder asks automatically, which is a working definition of expertise.

The Work Turns A Casual Enthusiast Into A Software Creator

You don’t get taste or judgement from a tutorial. You get it from building real things, breaking them, examining what broke, and comparing notes with other people doing the same. AI has made the building fast. But it can’t look hard at what they made and decide whether it is actually good.

That is the part worth getting good at, and it is best learned alongside other people.

An MLH hackathon is a place to ship something and break it in a weekend with others a few steps ahead.

DEV is where the audit becomes a post: what was built, what went wrong, what the code review turned up, what got fixed.

Build your creation in one, write down what it taught you in the other, and the next person who ships their first app gets to start a little further along than you did.

FAQ

Do I really need to audit a small personal project nobody else will use?
If the project truly never touches anyone else’s data and never goes online, the security stakes are low and the audit can be light. But the habit is worth building even on throwaway projects, because the questions are how the underlying concepts get learned. The cost of asking them on a small project is a few minutes. The cost of not knowing how to ask them on a real one is much higher.
I don’t know enough to judge the AI’s answers. Isn’t that the whole problem?
It is the honest starting point for almost everyone, and it is not a dead end. The point of the audit is not to already know the answers. It is to ask questions that pull the concepts into view, then learn them one at a time, in context. The first audit will surface things that are not fully understood. Those things are the curriculum.
Won’t the AI just tell me everything is fine?
Only if asked in a way that invites it to. “Is this good?” tends to get a reassuring answer. “What did you skip, and what would a senior engineer flag?” tends to get a useful one. Prompts that assume there is something to find generally find it.
How is this different from learning to code the traditional way?
The traditional path front-loaded the foundations: months of syntax and setup before building anything real. This path inverts the order. Build first to catch the momentum, then go back and learn the foundations through the specific thing that was built. Both routes end up needing the same underlying judgment. This one just arrives at it by a road that is easier to stay on.

GitHub, Demystified

MLH Team — Fri, 05 Jun 2026 19:32:48 +0000

TL;DR -
GitHub is a place to store code and keep track of every change made to it. That is the core of it. Because so much open source software lives there, it is also where a builder can find and reuse other people's tools, including a lot of the AI ecosystem. Its reputation as an intimidating community space is real, but that layer sits on top of a tool that does something fairly simple. A newcomer does not need to earn their way in. They need a project and an account.

GitHub has a way of making new developers, and now software creators or anyone who is creating code, feel like they walked into a party everyone else was invited to years ago. The profile photos, the rows of green contribution squares, the open source projects with thousands of stars. It reads like a club, and the entrance exam feels both invisible and already failed.

Plenty of people first hear about GitHub in its community form. They’re told it’s a place where strangers read your code and form opinions about it, long before anyone explains what it actually does. As a result, they may think GitHub is just a place where developers collaborate. In reality, it’s so much more. The collaboration is real. It is just not the only way in.

Consider this reframe: GitHub is a tool first. The community is something that grew on top of the tool, and a beginner can get real value out of the tool for months without touching the community at all.

What GitHub Actually Is

Strip away the reputation and GitHub does one job. It stores code and remembers every version of it.

That second half matters more than it sounds. The technical name is version control, like your history in Google docs. When anyone changes their code, GitHub keeps a record of what it looked like before. When you save a new version, the old one is still sitting there as a reference for the future. Break something badly at midnight, and there is a working version from that afternoon you can restore in the morning. Nothing a person saves to GitHub is ever truly lost, which is a quietly enormous relief for anyone who has overwritten a file and felt their stomach drop.

That same change-tracking is what makes building with other people possible. When two developers edit the same project, GitHub keeps both sets of changes straight and flags the spots where they collide, so the work can be combined instead of one person accidentally erasing the other. The collaborative nature of GitHub – the reputation it has built up over the years – is really just this one feature, pointed at more than one person.

The Mental Model: Google Docs for Code

Anyone who has opened the version history on a Google Doc already understands the heart of it. Every edit is recorded. Earlier drafts are recoverable. More than one person can work in the same place without chaos…there’s even color coded changes to keep things clear. GitHub does that for code instead of documents, with a few more tools for combining everyone’s changes cleanly. A learner who keeps that picture in mind has most of what they need to get started.

Getting Your First Project onto GitHub

Three things get a first project up, and none of them require permission from anyone.

First, an account. It is free at github.com, and that is the entire barrier to entry. No invitation, no wait time, no portfolio, no minimum experience.

Then a repository, repo for short. A repository is just the home for one project: its files, and the full history of how they got that way. Most new developers make one repo per thing they build.

Then commits. A commit is a saved snapshot of the project at a moment in time, with a short note describing what changed (added contact form, fixed the broken link). Committing often is the habit that turns GitHub from a backup into a timeline a person can actually read later.

The part that scares a lot of beginners, the black terminal window, is increasingly optional. Modern code editors and AI agents connect to GitHub directly, so someone who built a project by talking to an AI tool can often push it up through a few buttons without ever typing a command. The terminal is one door in. It is no longer the only one.

The Community Layer

This might be where GitHub’s reputation comes from, and it is worth understanding so it stops being intimidating. Because so many projects already live on GitHub, it has become the default place for open source: software whose code is public, so anyone can read it, learn from it, and suggest improvements.

When a project is public and popular, it attracts a lot of eyes. Someone spots a bug and offers a fix. Someone else improves the documentation. The original developer reviews the suggestion and decides whether to fold it in. That back-and-forth is genuinely powerful, and it is the thing people picture when they think GitHub is only for experts.

A useful way to think about it: GitHub is community-driven in the way Wikipedia is community-driven. Wikipedia is, at its core, a place to store information, and a community gathered around that core idea because the information was worth gathering around. GitHub is a place to store code, and a community gathered around it for the same reason. The storage comes first. The community is what has grown on top over many projects and many years. A beginner can use the storage for a long time before the community is ever relevant, and there is nothing wrong with that.

Using GitHub to Find and Reuse AI Tools

The community layer does something else worth knowing about. It turns GitHub into a place to get tools, not only a place to keep them. For a vibe coder, or anyone building without a traditional background, the most valuable thing on GitHub is often someone else’s work, sitting in the open and free to build on.

A large share of the AI ecosystem is developed and shared as open source. Agent setups, prompt libraries, automation workflows, and starter projects that already connect to a model or an API are all out there, posted by people who solved a problem once and left the solution where others could find it. A learner who wants to add image generation to a project, wire up a chatbot, or automate a repetitive task can often find a working starting point instead of beginning from a blank file if they know where to look.

Finding one can be as simple as searching GitHub for what the project needs to do and reading a few signals.

The star count is a rough measure of how many people have found a project useful.
The README, the page that greets a visitor on the repository, is the front door, and it usually explains what the tool does and how to set it up.
The date of the most recent activity says whether the project is still alive or was abandoned two years ago. A tool with recent updates and a clear README is a safer bet than one with neither.

A non-traditional developer does not have to read every line to put a tool to work, especially if they are vibe coding with the help of an AI agent. They can point their agent at the repository, ask it to read the README and the code, and have it explain in plain language what the tool does. From there the same conversation can cover how to bring the tool into the current project, what needs to be installed, and where the learner’s own details, an API key or a file path, have to go. Bringing a copy into their own workspace (forking or cloning, in GitHub’s terms) is usually a step the agent can walk through as well. The skill here is less about understanding the code on sight and more about knowing what to ask.

An important note on security: Code written by a stranger runs on the learner’s machine and sometimes reaches into their files, their accounts, or the keys that pay for an API. Before running something unfamiliar, it is worth knowing what it actually does, and an AI agent is good at exactly this kind of review. Asking your vibe coding partner what a tool accesses, what it sends out, and whether anything looks unusual takes a minute and catches the rare project that does more than it advertises. This is the same build-then-audit instinct to cultivate.

It is also worth a glance at the project’s license, usually linked on the repository’s main page, since that is what spells out how the code is allowed to be reused. Most widely used tools carry permissive licenses that allow this kind of borrowing, but a quick look avoids surprises later.

Git, GitHub, and the Alternatives

One last source of confusion worth clearing up.
Git is the version control system itself, the underlying technology that does the change-tracking.
GitHub is one popular place to host projects that use Git, and it is not the only one.
GitLab and Bitbucket do much the same job.
A beginner does not need to evaluate all three. Picking the one a tutorial or a friend already uses is a fine way to start because the core ideas carry over to the others.

The tool is far simpler than its reputation suggests. Accounts are free, your first repository takes a few minutes, and the community is there whenever you are ready for it. Until then, it can be pretty invisible. The only thing standing between a beginner and the version of GitHub that actually helps them is a project worth saving.

FAQ

Do I need to know how to code before using GitHub?
No. GitHub does not care how the code got written, whether by hand, in a bootcamp, or through a conversation with an AI tool. If a person has a project and an account, they can use it.

Is my code public by default?
Not unless a developer chooses to make it so. Repositories can be private, visible only to their owner and anyone explicitly invited. Public repositories are how open source works, but going public is always a choice.

What is the difference between Git and GitHub?
Git is the version control technology that tracks changes to code. GitHub is a service for hosting projects that use Git, with extra tools layered on for collaboration. People often say one when they mean the other, and for a beginner the distinction rarely gets in the way.

Do I have to use the terminal?
No longer. The terminal is one way to work with GitHub, and many developers like it, but code editors and AI agents now connect to GitHub through a visual interface. A new developer can put a project up without typing a single command.

Can I just upload my files directly instead of using Git?
Yes. GitHub lets a person drag files straight into a repository through the website, which is a perfectly reasonable way to start. Doing it through Git is considered best practice because it captures the full history of changes, but nobody has to begin there.

Is it okay to use someone else’s code in my own project?
Usually yes, when the project is open source, though the specifics depend on its license. Open source means the code is public and meant to be built on, and the license attached to a project spells out the terms, including whether credit is required. Most popular tools use permissive licenses that allow free reuse. The license is normally linked on the repository’s main page, and an AI agent can read it and summarize what it permits.

How do I know if a tool I find on GitHub is safe to use?
A few signals help. Recent activity, a clear README, and a healthy star count point to a project that real people rely on. Beyond that, code from a stranger runs on the learner’s own machine, so it is worth understanding what a tool does before running it. Asking an AI agent to read through the project and flag anything that touches files, accounts, or API keys is a quick way to check, and it catches the rare project that does more than it claims.

Do I have to pay to use tools I find on GitHub?
The open source code itself is almost always free to use. Costs usually come from somewhere else, such as a tool that connects to an AI model or another paid service, where the usage is billed by that provider rather than by GitHub. Reading the README, or asking an AI agent to, will usually surface whether a project depends on anything that costs money to run.

DevRelCon NYC 2026: Where Developer Relations, DevX, & Developer Marketing Come Together

MLH Team — Fri, 29 May 2026 17:34:01 +0000

TL;DR -DevRelCon NYC returns to Industry City in Brooklyn on July 22–23, 2026. It's the flagship conference for developer relations, DevX, and developer marketing professionals — about 300 people, intentionally tight-knit, with a DIY indie feel that sets it apart from larger corporate events. This year's programming focuses heavily on what AI is changing about DevRel: how to write docs for human and agent users alike, what developer experience means when AI handles the boilerplate, and how to measure and scale adoption in a shifting landscape. The week starts Tuesday night with a mini hackathon. Tickets are at nyc.devrelcon.dev, scholarships are available, and there's a "Convince Your Boss" script if you need it.

There's a conference that's been running for more than a decade, quietly becoming the place where the people who build for developers go to figure things out together. No keynote theater (but plenty of excellent speakers). No lanyard maze (but good happy hours and the occasional magic show). Just a few hundred practitioners in a converted Brooklyn warehouse, having the conversations that actually move the work of developer relations forward.

That's DevRelCon. And this year, it's coming home to Industry City on July 22 & 23, 2026. We’ve been active partners in the DevRelCon space since the beginning and now head up the flagship conference here in New York. Here’s a look at what we have planned this year.

What DevRelCon Actually Is

DevRelCon isn't a general tech conference. It's built specifically for people who work to grow developer adoption: developer relations professionals, developer experience teams, product marketers, platform PMs, and anyone whose job involves getting developers more deeply engaged with their work.

The community is intentionally tight-knit. Each year we have about 300 attendees. People who've been coming for years show up knowing they'll run into the colleagues, collaborators, and honest sounding boards they only see once a year. At the same time, each year we get new people who show up and find out immediately that the community is one of the friendlier ones in tech.

What This Year Is Focused On

The developer relations world is navigating something genuinely new right now: the increasing adoption and sophistication of AI models across an industry that sees opportunity in the tech.

When the end user of your API might be a person or an AI agent, how do you write documentation? When everyone is using AI to generate boilerplate, what does "developer experience" even mean anymore? These are the questions DevRelCon 2026 is designed to dig into.

Sessions this year are organized around the challenges that matter most to the community right now:

AI Developer Tooling And Platform Strategy
Developer-First Go-To-Market Methods
Measuring Developer Adoption And Activation
Documentation As Product
Building And Scaling Developer Ecosystems
Content Strategy And Career Paths

Our format stays true to the conference's DNA: 25-minute talks, 50-minute hands-on workshops (real ones where attendees leave with something tangible…not just slides and handouts), and lightning talk sessions for the short-form ideas that still deserve airtime.

DevRelCon Is More Than It’s Daily Sessions

The conference runs Wednesday and Thursday, but the experience starts Tuesday night with a mini hackathon for early arrivals. Consider it a low-stakes place to build something, get dinner, and shake off the travel before the main event.

Industry City itself is part of what makes this work. The converted warehouse complex in Sunset Park, Brooklyn is surrounded by art studios, coffee shops, and the kind of industrial-creative energy that makes a conference feel like an adventure rather than an obligation. MLH rents out the co-working space for an un-conference track that runs parallel to the main programming: attendees vote on topics, self-organize, and lead peer discussions without a deck in sight. Some of the best conversations at DevRelCon happen there.

And yes, of course, there's a happy hour at the end of day one. And after that? There's usually karaoke.

Who Should Come to DevRelCon?

The honest answer is that, if your work touches developers in any way, there's something here for you. That includes people at large platforms, startups, open source projects, and companies that aren't developer-focused but work alongside a lot of developers internally. DevRelCon has always been better at including people across that full spectrum than most conferences in its category.

Scholarships are available for students and people currently in career transition.

Apply for a Scholarship

If you need to make the case to your organization for attending, there's a ready-made script at the "Convince Your Boss" page on the DevRelCon site.

The Part That's New This Year

MLH has been running the New York edition of DevRelCon for several years. This year, with DEV now part of the MLH organization, the conference has a more direct connection to one of the largest developer communities on the internet. That means more paths to find your people before you arrive, more ways to keep the conversation going after you leave, and more infrastructure to make DevRelCon the year-round presence it's always had the potential to be.

The lab and the library, finally in the same building.

Tickets are available at nyc.devrelcon.dev. See you at Industry City in just a few weeks!

FAQ

When and where is DevRelCon NYC 2026?

July 22–23, 2026, at Industry City, 220 36th St, Brooklyn, NY. The full experience kicks off Tuesday night, July 21, with a mini hackathon.

Who is this conference for?

Anyone whose work involves developers: DevRel professionals, developer experience teams, product marketers, platform PMs, and go-to-market strategists. It's also a strong fit for people at companies that aren't developer-first but work alongside a lot of developers internally.

What does the programming look like?

Multi-track sessions across two full days, including 25-minute talks, 50-minute hands-on workshops, and lightning talks. An un-conference track runs in parallel in the co-working space at Industry City, where attendees self-organize and lead peer discussions on topics they vote on the day of.

What's the vibe?

Casual and intentionally indie. About 300 attendees, a community that's been building for 10+ years, and a venue that leans into that energy. Expect good conversations in the hallway as much as in the sessions, a happy hour at the end of day one, and, historically, karaoke.
Are there scholarships available? Yes — for students and people currently in career transition. Applications are open on the DevRelCon site.

What if I need help getting my company to cover attendance?

There's a ready-made "Convince Your Boss" script on the DevRelCon site.

What's new this year?

With DEV now part of MLH, DevRelCon has a direct connection to one of the largest developer communities on the internet — more ways to connect with attendees before and after the event, and more infrastructure to make the community year-round.