DEV Community: VH Costa

Do Not Be the Courier

VH Costa — Sat, 09 May 2026 18:36:08 +0000

LLMs can help you write code faster. Semantic ownership is what keeps the answer from becoming something you merely carried from one box to another.

The unsettling part of the Chinese Room is not that the person inside gives bad answers.

It is that the answers can be good.

John Searle's thought experiment asks us to imagine a person locked in a room who does not understand Chinese. Sheets of Chinese text arrive under the door. The person has a rulebook, written in a language they do understand, which tells them how to match incoming symbols with outgoing symbols. They follow the instructions, send replies back out, and from the outside it can look as if the room understands Chinese.

Inside the room, nobody does.

That is the useful part of the metaphor for programming with AI. Not the entire philosophy-of-mind argument. We do not need to settle whether machines understand anything before breakfast. That way lies tweed, office hours, and a whiteboard with the word "intentionality" written on it like a threat.

The practical warning is smaller.

Convincing output can pass through a system without anyone in the loop understanding what it means.

Sometimes that system is an AI assistant.

Sometimes it is the person using one.

The room is comfortable

AI-assisted programming can feel miraculous when you are learning.

You paste in an error. It explains the error. You paste in a function. It rewrites the function. You ask what the compiler wants. It gives you something that makes the compiler stop complaining.

This is useful. There is no virtue in staring at a cryptic error message until character has been built. Character is overrated. Documentation is nicer.

A good assistant can help you map unfamiliar code, explain vocabulary, suggest test cases, and show you the next thing to inspect. Used well, it compresses the distance between confusion and the first useful question.

The trouble starts when it also lets you skip the question.

You do not need to know what the error means if the patch works. You do not need to know why the type changed if the warning disappeared. You do not need to know what the command does if the build finally passes. You can keep sliding paper under the door.

Input. Output. Input. Output.

After a while, the workflow has momentum. The code changes. The terminal turns green. The page loads. The assistant sounds confident. The room is warm.

And you still do not know what happened.

That is the risk: not confusion, but productive-looking confusion. The kind that moves quickly enough to avoid being inspected.

Syntax is not ownership

Programming has always had a syntax trap.

A beginner learns where semicolons go, how braces nest, how to copy a loop, how to call a function, how to satisfy the compiler for one more minute. That is normal. Everyone starts by moving symbols around before the symbols fully mean anything.

There is nothing shameful about that stage.

The shame would be building a home there and naming it senior engineering.

Syntax matters. The machine is not impressed by your intentions. If the language expects a semicolon, a semicolon-shaped absence will become your afternoon.

But syntax is the visible skin of the work. Meaning lives underneath it.

When you write:

int count = 0;

the important part is not that the line is valid C. The important part is what you believe about count.

What does it count? Can it be negative? How large can it get? Who changes it? What happens if it overflows? Is int large enough on the platform you care about? Is zero a real value or a sentinel? Does the name match the role it plays in the program?

The compiler can accept the line without caring about most of that.

Your program cannot.

This is where semantic ownership begins.

Semantic ownership means you can explain what the code means in the context where it runs.

It is the difference between recognising the shape of an answer and understanding the job that answer is doing.

You know what the code is supposed to represent, what assumptions it makes, what it changes, and what would count as being wrong.

That is the difference between carrying an answer and owning one.

The code can run while the idea is broken

A passing program is nice.

It is not a confession of truth from the universe.

Programs run for many reasons. Some of those reasons are embarrassing.

A cast can silence a warning while hiding the bug. A larger integer type can postpone overflow without fixing the assumption. A null check can avoid a crash while making the caller's contract meaningless. A copied malloc example can produce the right output once while leaking memory every time after that. A test can pass because it checks the shape of the answer rather than the promise the code was meant to keep.

The machine will let you be accidentally correct.

It has no professional obligation to stop you.

This gets worse when the first answer arrives with explanations attached. The prose has gravity. It feels like reasoning. Sometimes it is reasoning. Sometimes it is a very elegant path to the wrong house.

"The code runs" is too weak as a standard.

A better question is:

Can I explain why this code should be right?

That question does not require you to become a compiler engineer before lunch. It does require you to connect the syntax to the meaning.

If the answer changed a type, what range problem did it solve?

If the answer added a condition, what state did it protect against?

If the answer moved validation earlier, what invalid value used to travel too far?

If the answer changed a build command, what part of the build was missing before?

If the answer added memory allocation, who owns that memory, and where does ownership end?

These are not ceremonial questions. They are the work.

A working patch is only the start of the trail. Understanding is being able to follow the footprints back without needing the assistant to hold the torch.

Your hunch changes the answer

There is another trap hiding inside the conversation.

The assistant absorbs your framing.

Ask a chatbot about a health problem and suggest blood pressure, and it may start arranging the symptoms around blood pressure. Start a different chat with the same symptoms and suggest diet, and it may start arranging the symptoms around diet instead. The prose can sound careful in both cases. It can justify both paths. It can make each hunch feel like the responsible one to investigate.

That does not make either answer useless.

It means your suggestion was not neutral.

The same thing happens in code.

Ask:

Is this a memory leak?

and the assistant may go hunting for ownership problems.

Ask:

Is this an off-by-one error?

and it may start measuring loop bounds with great seriousness.

Ask:

Is this because of async?

and suddenly the callback has motive, opportunity, and a suspicious alibi.

Sometimes your hunch is right. Hunches are part of debugging. But a suggestible tool can turn a hunch into a tunnel.

The answer usually arrives with reasons attached. Not just a verdict. A story.

And stories are sticky.

Once the assistant has explained why your suspected cause makes sense, you may stop looking for causes that make more sense. The tool did not only give you information. It helped your first guess put on a lab coat.

This is one reason semantic ownership matters.

A plausible answer is not enough if your question quietly dragged it into place.

A better debugging prompt gives the assistant room to disagree with you:

Here is the symptom, the relevant code, and what I have already checked. Give me three plausible causes, what evidence would support each one, and what test would separate them.

That prompt asks for a map instead of a blessing.

You can still include your hunch. Just label it as a hunch.

My suspicion is a memory leak, but I do not want to anchor on that. What else could explain this behaviour?

That sentence is small, but it changes the shape of the exchange. It reminds both you and the machine that the goal is diagnosis, not agreement.

Keep some salt nearby.

Fluent agreement tastes better than it should.

Semantic ownership is allowed to be partial

There is a bad version of this argument that turns into macho nonsense.

Real programmers know every instruction. Real programmers never need help. Real programmers write their own linker in a cave using a magnetised needle and spite.

No.

Nobody understands every layer all the time. Modern software is a stack of abstractions balanced on older abstractions, vendor promises, historical accidents, and one shell script nobody wants to touch because it has been load-bearing since 2017.

Using tools is normal. Looking things up is normal. Asking AI for an explanation is normal. Copying a small pattern while you are learning is normal.

Semantic ownership does not require you to hold the entire machine in your head.

It means you know which part you are trusting and which part you have checked.

A developer who says "I do not fully understand the allocator yet, but I know this function returns owned memory and the caller frees it here" is in a better position than one who says "the assistant added free() and the tests pass".

The first developer has a boundary.

The second has a vibe.

Vibes are lovely in music. They are less lovely in resource management.

Semantic ownership is often partial. The useful habit is making the boundary explicit.

I understand this part.

I am trusting this library contract.

I have not checked this edge case.

I need to verify this behaviour on Windows.

I know this compiles, but I do not yet know why this flag fixes the link step.

That is not weakness. That is a map.

The dangerous beginner is not the one who does not know.

The dangerous beginner is the one who cannot tell where their knowledge ends.

Use AI to leave the room

Use AI against the room.

Ask questions that build your model instead of only repairing the current symptom.

When you hit an error, do not stop at:

Fix this error.

Push for the idea underneath it:

Explain what this error means in terms of the type system.

When a function looks wrong, avoid treating the rewrite as the finish line:

What assumptions does this function make about its inputs?

When the build fails, ask what promise you broke:

What was the compiler protecting me from here?

When you add a test, ask what it proves:

What behaviour should this test protect, and what bug would still slip through?

When an answer looks correct, make the tool attack it:

Give me three ways this could still be wrong.

That shift changes your role.

You stop matching inputs to outputs and start using the tool to build the meaning that lets you judge the output.

The assistant can still be wrong. It can explain beautifully and still hallucinate a function, invent a flag, or describe a version of the library that exists only in the same dimension as perfect project estimates.

Fine.

The useful outcome is not obedience to the tool. It is becoming harder to fool.

A useful AI session should leave residue in your head.

You should come away with a better name for the problem, a clearer model of the system, one new thing to check, or a sharper reason for the change.

If the only thing you leave with is a patch, you may still be inside the room.

The meaning test

Before you keep an AI-generated change, try the meaning test.

Move away from the chat transcript and explain the change in boring words.

What was broken?

What changed?

Why should that change fix the problem?

What did you test?

What might still be wrong?

Where would you look if it failed again?

If you cannot answer those questions, you may not own the change yet.

The change may still be good. It just arrived before the understanding did.

So slow down.

Ask the assistant to explain the missing concept. Read the surrounding code. Check the documentation. Make a tiny experiment. Delete the patch and recreate it from memory. Change the test and see what breaks. Add a print statement. Use the debugger. Do the unglamorous thing that turns a working answer into your answer.

This is especially important in C, because C is generous in the way a cliff edge is generous. It gives you freedom, then lets you discover gravity at runtime.

But the rule is not limited to C.

Every language has a version of this problem. JavaScript will let you misunderstand truthiness. Python will let you misunderstand mutability. SQL will let you misunderstand joins and quietly ruin your afternoon with duplicates. Shell scripts will let you misunderstand quoting, which is less a topic than a haunted forest.

The details change.

The ownership problem does not.

Learning is the part where meaning catches up

There is a kind of productivity that is really just deferred confusion.

You move faster today by refusing to understand the thing you will need tomorrow. The debt does not disappear. It waits. Then it charges interest during a bug, a review, an interview, an outage, or one of those evenings where the code you copied becomes the code you have to explain.

AI can accelerate that debt.

It can also accelerate the repayment.

That is the fork.

Used badly, it gives you answers that outrun your understanding.

Used well, it gives you handles. A term to search. A mental model. A smaller experiment. A comparison between two approaches. A translation from compiler anger into human language.

This is why fundamentals still matter.

Not as tribute to tradition. Not as an initiation ritual where beginners must suffer before they are allowed to build anything fun.

Fundamentals matter because they give meaning somewhere to land.

A pointer carries claims about addresses, indirection, lifetime, and ownership. The little * has a lot of nerve for something that small.

A compiler error often tells you which promise you failed to make precise. Annoying, yes. Also annoyingly useful.

A type constrains a value, signals intent, and occasionally acts as a warning label next to a name.

A test states behaviour you expect to remain true. The green checkmark is only the receipt.

Once those ideas start connecting, AI becomes more useful. You ask better questions. You reject bad answers faster. You notice when the explanation skips the hard part. You can tell the difference between a fix, a workaround, and a ceremonial pile of tokens arranged to appease the build gods.

The tool becomes less like the book in the room and more like a way out of it.

Do not be the courier

The person in the Chinese Room is not stupid.

They are doing exactly what the system asks them to do. Symbols come in. Rules get applied. Symbols go out.

That is why the metaphor is uncomfortable.

It is possible to be diligent, fast, and still detached from meaning.

AI-assisted programming can put you in that position quietly. Prompt goes in. Patch comes out. Error goes in. Fix comes out. The loop feels like progress because something is always moving.

But movement is not understanding.

At some point, the question has to change from:

What should I paste next?

to:

What do I now understand that I did not understand before?

That is the difference between using the tool and disappearing into it.

Do not be the courier for code you cannot read.

Make the answer pass through your own model of the problem. Give names to the moving parts. Check the assumption the assistant smoothed over. Ask what would prove the fix wrong. Notice when your first hunch is being flattered instead of tested.

Programming has always required help. Documentation, colleagues, debuggers, search engines, forum threads, weird comments from 2014. The issue is not needing help. The issue is treating fluency as a substitute for meaning.

Semantic ownership begins when the code is no longer something the room handed back to you.

It begins when you can point at the answer and say what it means.

Everything before that is just paper under the door.

Code Is Cheap. Review Isn't.

VH Costa — Wed, 29 Apr 2026 22:13:19 +0000

AI made it easier to produce code-shaped output. Good contribution still means making your work easy to understand, review, and trust.

You can now produce a pull request in the time it takes to make a coffee.

Often less.

This depends on the coffee, obviously. If you grind the beans, heat the water properly, and have opinions about extraction, the pull request may win by a comfortable margin.

That should make us pause.

Fast tools are useful. A coding assistant can help you read unfamiliar code, sketch an approach, write a test, or spot an edge case you would have missed. There is no virtue in doing everything the slow way just because it gives the work a faint smell of candle wax and suffering.

The problem starts when the diff becomes almost free.

A pull request has never been only a diff. It asks someone else to spend attention, apply judgment, take responsibility, and decide whether this change belongs in a project other people depend on.

That cost still lands on a human.

Ashley Wolf on the GitHub Blog recently described open source as entering its own “Eternal September”: contribution friction has dropped, volume is rising, and maintainers are having to respond with better trust signals, triage systems, and project-level controls. The key sentence is brutally simple: “The cost to create has dropped but the cost to review has not.” (Source: GitHub Blog)

Abigail Mayes, also on the GitHub Blog, made the same point in their writing on mentorship in the AI era, noting that developers merged nearly 45 million pull requests per month in 2025, up 23% year over year. More pull requests. Same maintainer hours. (Source: GitHub Blog)

That is the bridge from “Don’t Open a Pull Request Yet”. In that piece, the point was: learn the project before asking it to absorb your change.

This is the next step: once your work reaches a maintainer, make the review cheaper than the diff was to create.

A pull request is a question

A pull request looks like a contribution because GitHub gives it a nice interface.

It has a title. It has a diff. It has a button. It may even have a green checkmark, which is the software equivalent of a tiny approving priest.

But to a maintainer, a pull request starts as a series of questions:

Is this needed?
Is this correct?
Does this fit the project?
What behaviour changes?
What did the author test?
What happens if we merge it and they disappear?

The code matters. Broken code is rarely rescued by a charming personality. But the diff alone does not answer enough.

A one-line change can still be expensive if it arrives without context. Someone has to work out why it exists, whether the issue is real, whether the change is too narrow or too broad, whether it matches the project’s direction, and whether the contributor can respond to review.

That is why “small PR” and “easy PR” are different things.

A small PR changes few lines.

An easy PR reduces guesswork.

Aim for the second one.

The new problem is polished uncertainty

Polished uncertainty is work that looks credible before anyone knows whether it is correct.

That is the new burden.

Weak contributions used to look weak faster. Not always. People have been confidently wrong for longer than we have had package managers. But there were usually signs. The issue description was vague. The patch ignored the contribution guide. The author had not read the surrounding code. The proposed fix had that special “I changed the thing that looked closest to the error message” aroma.

AI changes the packaging.

A shallow contribution can now arrive with a polite description, a reasonable structure, a test plan, and the emotional posture of a senior engineer in a calm meeting room.

Lovely.

Now someone has to find out whether any of it is real.

The Register recently reported on this shift in curl. Daniel Stenberg, curl’s founder and lead developer, said the project had largely stopped receiving obvious AI-slop security reports. Instead, it was receiving more good-looking, AI-assisted reports, faster than before, which still created a growing workload because maintainers had to verify them. (Source: The Register)

Obvious nonsense is annoying. Plausible uncertainty is expensive.

When something looks credible, you cannot dismiss it quickly. You have to inspect it, reproduce it, and compare it against the project’s actual behaviour rather than the story around it.

Developers already know this feeling from their own AI-assisted work. Stack Overflow’s 2025 Developer Survey found that 84% of developers use or plan to use AI tools, while 46% said they do not trust the accuracy of AI output. The most common frustration was AI answers that are “almost right, but not quite”, cited by 66% of developers. (Source: Stack Overflow)

“Almost right” sounds harmless until you have lived inside it.

It means the import exists, but not in this version. The API call is real, but the arguments are wrong. The algorithm works for the example, then quietly eats the edge case. The explanation sounds confident until you realise it skipped the one constraint the whole project cares about.

Clean code can still be the wrong code. A passing test can still test the wrong promise. A tidy refactor can still erase a weird-looking behaviour that was there because three users, one browser, and a printer from 2011 formed a pact with the underworld.

Maintainers know this because they have seen the ghosts.

A contributor who wants to help should respect that. The goal is not to perform confidence. The goal is to make verification cheaper.

Make verification cheaper

This is the contributor standard I would use now:

A good contribution reduces the amount of guessing required to review it.

That applies whether you used AI or not.

Before you open a pull request, make sure the reviewer can see the path from problem to change. Do not make them reverse-engineer your reasoning from the diff like a crime scene investigator with worse lighting.

A useful pull request explains:

what problem you are solving
where that problem was discussed or observed
why this change is the right size
what alternatives you considered
what you tested
what could still be wrong

That last part matters.

A contributor who says “I am least sure about this branch because I could not find an existing test for this behaviour” is easier to review than one who arrives with a polished paragraph of total certainty.

Total certainty is cheap now. You can generate it in seconds.

Specific uncertainty is more useful. It tells the maintainer where to look. It shows that you understand the edge of your own understanding. It turns review into collaboration instead of excavation.

A good pull request does not need a novel attached.

Please do not write a novel. Maintainers have families, hobbies, pets, and in some tragic cases, other repositories.

But the PR should contain enough context to be reviewable without guesswork. For many projects, that means five small things.

First, link the reason. If there is an issue, discussion, bug report, failing test, or documented confusion, point to it. If there is no prior discussion, explain why you are opening code first.

Second, explain the change in project terms. “Refactored logic” is vague. “Moves validation before normalisation so invalid input fails before it reaches the parser” is useful.

Third, describe the test. Name the command you ran. Mention the case you added. If you did not test something, say so. Silence does not create confidence. It creates homework.

Fourth, keep the diff aligned with the claim. If the PR says it fixes one bug, it should not also rename files, reformat half a module, and introduce a new helper because the old one offended your sense of symmetry.

Fifth, stay available. A pull request is a conversation until it is merged or closed. If you disappear after opening it, the maintainer has to decide whether they are reviewing a contribution or adopting an orphan.

That is the minimum. Not perfection. Reviewable shape.

Use AI before you ask for attention

There is a good way to use AI in open-source contribution.

Use it before the public part.

Ask it to explain unfamiliar code. Ask it to compare two possible fixes. Ask it to list edge cases. Ask it to help you turn messy notes into a clearer issue comment. Ask it what assumptions your approach might be making.

Then do the work a contributor has always had to do:

Read the relevant files. Run the tests. Check the project’s conventions. Compare your change with past pull requests. Remove the parts that are too broad. Write the explanation yourself.

The public artefact should show your understanding, not the tool’s fluency.

A useful rule:

Do not submit anything you cannot explain with the tab closed.

This is responsibility, not purity.

The maintainer is not merging your chat transcript. They are merging a change into a living project.

Your name is on the work. Your judgment has to be in it.

That also gives us a practical rule for disclosure: disclose when AI materially shaped the code, test, security claim, or design choice.

GitHub’s recent writing on mentorship in the AI era uses three filters for deciding where maintainers should invest attention: comprehension, context, and continuity. Does the contributor understand the problem? Have they given enough information to review the work? Do they keep engaging after the first interaction? (Source: GitHub Blog)

AI use can affect all three. The point is not to force ritual humiliation. Nobody needs a little badge that says “assisted by robot, spiritually complicated”.

The point is to help the reviewer calibrate.

A simple note is enough:

I used an AI tool to help trace the call path and draft the initial test case. I reviewed the final change manually and can explain the touched code.

That tells the maintainer where the tool helped, and where your judgment entered the process.

The dangerous version is unowned work. If the tool wrote something you do not understand, you are handing the project an IOU made of fog.

Do not do that.

Boundaries protect useful attention

When projects tighten contribution rules, it is easy to read that as hostility.

Sometimes it is. Some communities do become opaque, defensive, or needlessly sharp. “Quality standards” can be a real principle, or it can be a decorative shield for bad manners.

But many boundaries are less dramatic than that.

They are attention budgets.

GitHub has shipped repository settings that let maintainers disable pull requests entirely or restrict them to collaborators. It describes these controls as useful for read-only projects, mirrors, or projects that want to share code publicly without managing outside contributions. (Source: GitHub Changelog)

That sounds severe until you remember the imbalance.

A contributor may spend ten minutes generating a patch. A maintainer may spend forty minutes proving it does not belong. Repeat that across a popular project, and the “open” in open source starts to feel less like generosity and more like an inbox with a roof leak.

Clearer rules are not automatically a rejection of newcomers. Done well, they protect the conditions that let good newcomers receive real attention.

If every drive-by patch gets a careful mentorship session, nobody gets mentored for long.

The boring skills got more important

There is a comforting fantasy that better tools make fundamentals optional.

I would love this to be true. I have many fundamentals I would like to place gently in a lake.

But better generation makes review skill more important.

When code appears quickly, you need a stronger model for deciding whether it deserves to stay. That means reading code carefully. Understanding tests. Knowing how data moves. Noticing ownership, boundaries, side effects, and failure modes.

This is where the C Systems Lab bias enters the room wearing steel-toed boots.

Low-level programming is not useful because everyone needs to write C every day. Most people do not. The world has suffered enough segmentation faults for several lifetimes.

It is useful because it makes certain review questions harder to avoid.

Where does this memory live? Who owns this resource? What happens at the boundary? What does the caller assume? What fails if the input is weird? Which part of the system now has to carry the cost?

Those questions still matter when the code is written in a friendlier language. They matter even more when the first draft came from a machine that can produce plausible code without understanding the project’s ghosts.

Machines remain machines, even when the assistant explains them in a soothing voice.

So yes, learn the boring things. Not because boredom is noble. Boredom is often just bad documentation wearing a tie.

Learn them because they make you harder to fool.

Trust is the contribution

The first post ended with a simple idea: good contribution starts before the pull request.

This one adds the pressure of 2026: the pull request itself is easier to produce than ever, so the work around it matters more.

Do not let the tool’s fluency become your public judgment. Do not make maintainers guess why your change exists. Do not send code you cannot explain once the tab is closed.

The diff is the visible part.

The contribution is the trust you build around it.

Everything else is just another notification.

Don't Open a Pull Request Yet

VH Costa — Tue, 28 Apr 2026 23:51:18 +0000

How to become a genuinely useful open-source contributor before you write a line of code.

You want to contribute to open source, but you do not want to be that person.

Not the one who opens a pointless pull request just to add their name to a README.md. Not the one who pastes in AI-generated code, wraps it in a polished PR description, and assumes “looks right” means “is right”. And not the one who leaves a maintainer with more work than before they saw your name in the notifications.

That fear is healthy.

Because the uncomfortable truth is this: a lot of visible contribution is not useful contribution. A maintainer is rarely asking, “Did this person submit something?” They are asking three quieter questions:

Is this needed?

Is this correct?

Is this easy to trust?

Most weak contributions fail on one of those three points before the code itself matters.

That is why good open-source contribution starts earlier than most people think. It does not start with a pull request. It starts with context.

Context comes first

People love to say, “Just find an issue and start.”

That is fine advice if your goal is activity. It is bad advice if your goal is usefulness.

A repository is not a bucket of chores waiting for strangers. It is a living system with trade-offs, history, backlog pressure, and people trying to keep it moving. If you open a pull request before you understand any of that, you are not really helping yet. You are asking someone else to assess your judgment.

That is why tiny, visible changes can still be poor contributions. A one-line diff is not automatically a one-minute ask. Someone still has to read it, place it in context, decide whether it belongs, and often explain why it does not.

The “add your name to the README” wave made that painfully clear. In February 2024, Express contributors were openly discussing how to curb spammy README.md pull requests from new contributors because they were creating noise and extra moderation work rather than meaningful progress.

That gives you a better test than “Can I open a PR?”

Ask instead:

Does this change solve a real problem the project actually has?
Can I explain why this approach makes sense here?
Have I made it easy for someone else to trust what I’m proposing?

If the answer is not yet “yes”, you probably need more context, not more code.

Read the project’s social architecture

Open-source projects do not just have technical architecture. They have social architecture too.

There is usually a pattern to how decisions get made, how questions get answered, what gets prioritised, and what gets pushed back on. If you miss that layer, you can write a technically decent patch and still make a poor contribution.

Start with the obvious documents, but treat them as operating instructions rather than admin clutter. Read the README, contribution guide, issue templates, pull request template, code of conduct, and governance notes. Those pages tell you what kind of help the project wants, where different kinds of discussion belong, and what behaviour creates friction.

Then look past the documents and study the project in motion.

Read a few open issues from start to finish. Read a few recently merged pull requests. Then read a few that were closed without merging. That comparison is often more useful than any generic open-source advice because it shows you how this project behaves in practice.

You will start to notice patterns.

Maybe small, scoped changes land faster than broad clean-ups.

Maybe maintainers care a lot about tests.

Maybe they want discussion before implementation on larger changes.

Maybe support questions belong somewhere else entirely.

Maybe the project values consistency more than cleverness.

That is the social architecture. It tells you what “helpful” means here, not in theory.

It also changes how you ask questions.

A weak question hands your confusion to someone else.

A strong question shows the thinking you have already done.

“Can someone explain this whole module?” is a weak question.

“I traced this behaviour to this file, and I think this branch is why the bug appears, but I’m not sure whether that behaviour is intentional” is a strong one.

The second question gives someone something concrete to respond to. It narrows uncertainty instead of exporting it.

That is the habit you want.

Find the project’s pressure points

If the social architecture tells you how the project behaves, the pressure points tell you why.

From the outside, an open-source project can look like a simple list of issues and pull requests. From the inside, it is usually a bundle of maintenance costs competing for limited attention. Bugs need reproducing. Pull requests need review. Regressions need testing. Releases need preparing. Duplicate reports need closing. Docs need updating.

That is why project behaviour can look harsher than it really is.

A slow reply is not always dismissive.

A short reply is not always rude.

A closed issue is not always a judgment on you.

Sometimes it just means the project has learned to protect scarce attention.

If you want to be useful, figure out where the pressure actually is.

If the issue tracker is full of vague reports, a careful reproduction is useful.

If pull requests keep stalling on tests, test work is useful.

If the same confusion keeps appearing in issues, a precise docs fix is useful.

If maintainers keep redirecting people to the same answer, someone who reads first is already easier to work with.

This is where many contributors go wrong. They choose work that looks like contribution instead of work that relieves pressure.

Maintainers do not need more contribution-shaped activity. They need fewer unknowns, fewer unnecessary reviews, and fewer loose ends.

That is the day-to-day reality you need to acquaint yourself with before you try to change anything.

Read the codebase like an investigator

A lot of new contributors open a repository and try to understand the whole thing.

That is usually wasted effort.

You do not need total understanding. You need enough local understanding to make a trustworthy change.

The best way to do that is to read the codebase like an investigator, not a tourist. Start from a concrete question and follow the path that question takes through the system.

If you are looking at a bug, start where the bug appears and trace inward.

If you are looking at a feature, start where the user encounters it and follow the flow.

If you are looking at an error message, search for the exact text and find where it originates.

This is much more effective than browsing files until something feels familiar.

Look for landmarks. Where is the setup logic? Where are the tests? Which modules appear repeatedly in recent pull requests? Are there architecture notes? Are there directories whose names keep coming up in issue discussions?

Those clues tell you where the important paths are.

Tests are especially valuable here. They tell you what the project thinks “correct” means. They also show you how contributors are expected to express changes. If you want to understand how a piece of behaviour is meant to work, the test suite often explains it more clearly than the implementation.

Past pull requests help too. Find a recent change in the same part of the codebase. Read the diff, then read the review comments. You will often learn more from what had to be clarified, shrunk, or reworked than from the final code alone.

The goal is not to read widely. It is to become specific.

When you can say, “The bug starts here, seems to flow through these two modules, and is probably covered by this test,” you are in a much better position to contribute.

Not because you know the whole codebase, but because you know the part you are touching well enough to make your reasoning visible.

Use AI to compress learning, not responsibility

AI is now part of open-source contribution whether people like it or not. The real question is not whether you use it. The question is whether you use it in a way that makes your contribution better or just faster-looking.

A simple rule cuts through most of the noise:

Use AI to compress learning. Do not use it to compress responsibility.

That means AI can help you understand a pattern, compare approaches, summarise documentation, suggest cases you might want to test, or help you phrase a question more clearly before you post it. CPython’s contributor guide allows this kind of use, while making clear that contributors remain responsible for the usefulness and quality of what they submit. It also says maintainers may close issues and pull requests that are not useful or productive, including ones that are fully generated by AI.

What AI should not do is become your proxy.

NumPy’s AI policy is unusually clear: contributors are responsible for any code they submit, whether written manually or generated by AI; they must understand it and be able to explain it. NumPy also says it will reject pull requests it deems “AI slop” and tells contributors not to use AI to automatically generate normal project communication such as issue descriptions, pull request descriptions, or comments.

That is the right standard because maintainers are not reviewing for local plausibility. They are reviewing for fit.

Does this solve the real problem?

Does it match the project’s conventions?

Does it introduce churn for little benefit?

Can the author explain why this approach makes sense here?

AI is often decent at producing plausible-looking code. Plausible-looking code is not the same thing as a good contribution.

So use AI privately if it helps you think. But do not let it speak for you in public, and do not submit work you cannot defend line by line.

If you would struggle to answer “Why this change?” in a review, AI has not saved you time. It has just delayed the cost until someone else has to pay it.

Choose work that removes ambiguity

Once you have context, understand the project’s pressure points, and know your way around the relevant code, you still do not need to start with a grand fix.

Start with the kind of contribution that removes ambiguity.

That is the sweet spot for first contributions because ambiguity is what drains maintainers. They are constantly trying to work out whether a report is reproducible, whether a bug is current, whether a change is safe, whether a proposed fix matches the project’s direction, and whether a contributor understands what they are touching.

The best early contributions make those answers easier.

A strong first contribution might be:

a bug report with exact reproduction steps
a focused test that proves a failure clearly
a docs fix that removes a common point of confusion
a small patch in an area you have already traced properly and can explain with confidence
a careful confirmation that an issue still exists in a current version

What matters is not whether the change is glamorous. It is whether the thinking is legible.

That is a better filter than “good first issue”, which can be useful but often hides the real question. The real question is not “Is this easy?” It is “Can I understand this fully enough to make a change that is needed, correct, and easy to trust?”

That is how you choose a first contribution that actually helps.

Make it easier to trust you

Good open-source contribution starts earlier than code.

It starts when you learn how a project makes decisions, where it is under pressure, and what kind of work reduces uncertainty rather than adding more of it. It starts when you read the codebase with a concrete question in mind. And it starts when you use AI, if you use it at all, as a tool for understanding rather than a way to outsource judgment.

That is the standard worth aiming for.

Not “I opened a pull request.”

Not “I got something merged.”

But: I made this project easier to work on.

That is what maintainers notice. That is what builds trust. And that is what turns you from someone showing up in the notifications into someone the project is genuinely glad to see.