https://coddytech.net/blog/python-learning-roadmap

A clear, step-by-step Python learning path for beginners — syntax, libraries, projects, and how to stay consistent in 2026.

https://coddytech.net/blog/how-to-use-claude-ai-for-learning-programming

Lena was stuck learning Python until she discovered how to use Claude AI as a personal tutor. Learn the exact prompts and workflows to learn coding faster.

👋 I've been quiet for almost a year.

No excuse. I got busy with client work, told myself I'd post "next week," and next week turned into eleven months. If you unsubscribe today, I get it.
But here's what changed.

I stopped trying to make this a news channel. There are a hundred places to get news. What I actually have after 10 years of writing code - and what almost nobody gives beginners - is the small practical stuff. The snippet that saves an hour. The prompt that finally makes a concept click. The tool that's worth installing and the one that isn't.

So from today, this channel is one thing:
📌 One practical lesson, every weekday.
Mon - a code snippet you'll actually reuse
Tue - an AI prompt for learning and debugging
Wed - one concept, explained properly
Thu - a tool or repo worth your time
Fri - a poll or an open question (at least I'll try) :)

Same time every day. No 40-minute tutorials, no hype, no "10 AI tools that will replace developers."

Give me two weeks. If it's not useful by then, unsubscribe, and you've lost nothing.

React 🔥 if you're staying - I want to see who's still here.

📘 JavaScript or Python? Wrong question.
This is the #1 thing beginners ask me, and almost every answer online is bad - because it compares the languages instead of asking what you want.
Here's the honest version.

🔹 Pick JavaScript if you want to see things.
You want a website, a button that does something, an app people can open in a browser. JS is the only language that runs natively in the browser - that isn't an opinion, it's just how the web works. Feedback is instant, and for a beginner, instant feedback is worth more than clean syntax.

🔹 Pick Python if you want to process things.
Data, automation, scripts, AI, scraping, anything where the result is a number or a file rather than a screen. The syntax stays out of your way, which matters a lot in your first three months.

What actually decides it:
▪️ Want a job in web dev? → JavaScript. Non-negotiable.
▪️ Want data / AI / automation? → Python.
▪️ Want to automate boring parts of your current job? → Python.
▪️ Genuinely no idea? → JavaScript. You'll see results faster, and seeing results is what keeps beginners from quitting.

And the part nobody says out loud: after the first one, the second takes about three weeks. You're not choosing a career. You're choosing which syntax you'll be confused by first.

The real risk isn't picking wrong. It's spending four months picking. Full comparison, with the job-market side and where AI fits in 👇
https://coddytech.net/blog/javascript-vs-python-which-to-learn
#learn @codingforweb

🛠 5 VS Code extensions I still use after 10 years
Not "top 20 extensions." Twenty extensions make your editor slow and your brain tired. These five earn their place.
1️⃣ Error Lens
Shows the error inline, on the line, in red - instead of hiding it in the Problems panel. Sounds trivial. Cuts your debugging time more than anything else on this list. Install this one first.
2️⃣ GitLens
Hover any line and see who wrote it, when, and in which commit. When you join a real codebase, this is the difference between "why is this here?" and knowing the answer in two seconds.
3️⃣ Prettier + ESLint
Prettier formats, ESLint catches mistakes. Set "format on save" and never think about spacing again. Together they end 90% of the arguments a junior has with their own code.
4️⃣ Path Intellisense
Autocompletes file paths in imports. Small. You'll notice it every single day.
5️⃣ Quokka.js
Runs JavaScript as you type and shows the value of every variable next to it. For learning, this is the closest thing to seeing the code think.
❌ What I don't install anymore:
theme packs, icon packs, bracket colorizers (built into VS Code now), and any extension that adds a sidebar icon I'll never click. Every extension costs startup time and attention. Five good ones beat twenty.
What's the one extension you'd defend? 👇
#tools @codingforweb

📊 84% of developers use AI. 3% trust it.

Stack Overflow just published the 2026 Developer Survey - 49,000+ developers, 177 countries. The numbers are the strangest I've seen in years.
▪️ 84% use AI tools in their workflow
▪️ 29% trust the accuracy of what it produces - down from 40% in 2024
▪️ 46% actively distrust it
▪️ 3% say they "highly trust" AI-generated code
▪️ Among experienced developers: 2.6%

Read that again. Adoption went up. Trust went down. At the same time. That's not a contradiction - it's what expertise looks like. The more you use
a tool, the better you know where it breaks.
And here's the number that explains everything:
🔸 66% say their biggest frustration is code that is "almost right"
🔸 45% say debugging AI output takes longer than writing it themselves

Not wrong code. Almost right code. Wrong code fails loudly and you fix it in a minute. Almost-right code passes review, ships, and breaks in production three weeks later.
So the skill that matters in 2026 isn't prompting. It's the ability to look at working code and know it's wrong. That skill only comes from writing code yourself first. There's no shortcut, and the survey is 49,000 developers agreeing with that.

📎 Source: survey.stackoverflow.co
Forward this to someone who thinks learning the basics is optional now.
#learn @codingforweb

🤯 Developers felt 20% faster with AI. They were 19% slower.

This is my favourite study of the last two years, and almost nobody in my feed has seen it.

METR ran a proper randomized controlled trial. Not a survey - an actual RCT:
▪️ 16 experienced open-source developers
▪️ Real repos: 22,000+ stars, 1M+ lines of code
▪️ 246 real issues - bugs, features, refactors
▪️ Each task randomly assigned: AI allowed or AI not allowed
▪️ Tools: Cursor Pro with Claude Sonnet

Before starting, developers predicted AI would make them 24% faster.
After finishing, they believed AI had made them 20% faster.

Measured result: they took 19% longer.
A ~40-point gap between what they felt and what actually happened. The researchers called it "a substantial and persistent gap between perceived and actual performance."

Why it happens - and this is the useful part:
AI removes the feeling of effort, not the effort. You stop staring at a blank file, so the work feels lighter. But you replace writing with reading, reviewing, correcting, re-prompting. That's slower, and it doesn't feel slower, because reading feels easier than writing.

⚠️ This is not an anti-AI post.

The same study notes: these were experts in codebases they knew by heart - the exact scenario where AI helps least. Elsewhere, the picture flips: teams that use AI agents properly cut PR turnaround from 9.6 days to 2.4 days.

The lesson isn't "don't use AI." It's this:
👉 Your sense of your own speed is not evidence. Time yourself once. Do it this week on one real task. The result will surprise you in one direction or the other - and either way you'll know something about your workflow that 99% of developers only guess at.

📎 Source: metr.org - "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"

Forward this to the person on your team who's most sure AI made them faster.

#learn @codingforweb

🔓 45% of AI-generated code contains a security vulnerability.

Veracode tested this properly: 80 curated coding tasks, run across 100+ large language models. Not vibes — a benchmark.

Results:
▪️ 45% of generated code introduced an OWASP Top 10 vulnerability
▪️ Java: 70%+ failure rate - the worst by far
▪️ Python, C#, JavaScript: 38 - 45%
▪️ Cross-site scripting (CWE - 80): 86% failure rate
▪️ Log injection (CWE - 117): 88% failure rate

And the line that should worry you most:
"Despite advances in LLMs' ability to generate syntactically correct code, security performance has not kept up, remaining unchanged over time." Models got dramatically better at writing code that works. They did not get better at writing code that's safe. Those two things improved on completely different curves, and almost nobody noticed. Because here's the thing about a security bug: it passes your tests. It passes code review. It works perfectly - right up until it doesn't.

🔖 Save this. Six things to check in every piece of AI code you ship:

1️⃣ Any user input rendered to a page → is it escaped? (XSS)
2️⃣ Any user input reaching the database → parameterized query, never string concatenation (SQL injection)
3️⃣ Any user input written to logs → stripped of newlines (log injection)
4️⃣ Any file path built from user input → validated against traversal (../)
5️⃣ Any secret, key, or token → in env vars, never in the code it just wrote
6️⃣ Any dependency it imported → does that package actually exist? (AI invents package names, and attackers register them)

Number 6 is the one nobody checks. It has a name now: slopsquatting.

📎 Source: Veracode 2025 GenAI Code Security Report

Please send this to the person on your team who ships AI code the fastest.

#tools @codingforweb

⚡️ Only 31% of developers use AI agents. That gap is about to decide a lot.

Buried in the Stack Overflow 2026 survey is a split almost nobody is talking about - and it's much bigger than the "do you use AI" question. Autocomplete is universal now. 84% use it. It's table stakes.
Agents - tools that run tasks, edit multiple files, execute commands - are not:
▪️ 31% of developers use agents
▪️ 38% have no plans to start
▪️ 69% of agent users report increased productivity
▪️ PR turnaround among them: 9.6 days → 2.4 days

That last number is a 4x change in how fast work moves through a team. Not a tweak. A different operating speed.

Also from the same survey, on tooling:
▪️ VS Code: 75.9%
▪️ Cursor: 17.9% - the fastest first-year debut the survey has ever recorded
▪️ Claude Code: 9.7%

The pattern is clear: developers aren't replacing their editor. They're adding an agent next to it. Here's why this matters more than the productivity number. When 69% of one group ships four times faster, that group isn't just more productive. Within a year, it's the group that sets what "normal output" means - for teams, for hiring, for what a job posting expects you to know. The gap isn't between people who use AI and people who don't. That question is settled. It's between people who let AI complete a line and people who let it complete a task.

🎯 Do this week:
Take one boring task you've been avoiding - a test suite nobody wrote, a migration, a refactor across five files. Give it to an agent end-to-end. Don't help it. Watch where it fails.
You'll learn more in one afternoon than from fifty tutorials, and you'll know exactly which half of that 31/69 split you belong in.

📎 Source: Stack Overflow Developer Survey 2026

Forward to someone still using AI only for autocomplete.
#tools @codingforweb

🎯 After 13 years of writing code, here's the only skill I'd optimise for now...

Every week someone asks me the same question: what's the point of learning to code if AI writes it? I used to give a long answer. I'll share a short one, and the 2026 data supports every part of it.

Look at what we know:
▪️ 84% of developers use AI - but only 3% highly trust its output
▪️ 66% say their #1 frustration is code that's "almost right"
▪️ 45% say debugging AI output takes longer than writing it themselves
▪️ 45% of AI-generated code ships with a security vulnerability
▪️ In a controlled trial, experts felt 20% faster and were 19% slower

Every single one of those numbers points to the same place. The bottleneck is no longer writing code. It's judging code. Producing a function is now free. Knowing whether that function is correct, safe, maintainable, and actually solving the right problem - that is the entire job now. It's what 97% of developers don't trust AI to do, and it's what nobody can outsource. So if I were starting today, I'd optimise for one thing:

👉 Read more code than you write.

Concretely, and this costs nothing:
1️⃣ Open a repo you use and read one file properly. Not skim - read it until you could explain every line to someone else.
2️⃣ Every time AI gives you code that works, ask it: "what's wrong with this?"
Then verify its answer yourself. It will be wrong sometimes. Catching that is the skill.
3️⃣ Break working code on purpose. Change one thing, predict the failure, check if you were right. Being right consistently is what expertise actually is.
4️⃣ Review a pull request in an open-source project. Badly, at first. Do it twenty times.

None of that is glamorous, none of it makes a good screenshot, and all of it compounds. The developers who'll be valuable in 2030 aren't the ones who prompt best. They're the ones who can look at code that runs perfectly and say, "This is wrong, and here's why." That was always the job. AI just deleted everything else.

💬 What do you think - is judgement really the bottleneck, or am I wrong here?

Forward this to someone who's wondering if it's still worth learning.

#learn @codingforweb

🔓 45% of AI-generated code contains a security vulnerability.

Veracode tested this properly: 80 curated coding tasks, run across 100+ large language models. Not vibes — a benchmark.

Results:
▪️ 45% of generated code introduced an OWASP Top 10 vulnerability
▪️ Java: 70%+ failure rate - the worst by far
▪️ Python, C#, JavaScript: 38 - 45%
▪️ Cross-site scripting (CWE - 80): 86% failure rate
▪️ Log injection (CWE - 117): 88% failure rate

And the line that should worry you most:
"Despite advances in LLMs' ability to generate syntactically correct code, security performance has not kept up, remaining unchanged over time." Models got dramatically better at writing code that works. They did not get better at writing code that's safe. Those two things improved on completely different curves, and almost nobody noticed. Because here's the thing about a security bug: it passes your tests. It passes code review. It works perfectly - right up until it doesn't.

🔖 Save this. Six things to check in every piece of AI code you ship:

1️⃣ Any user input rendered to a page → is it escaped? (XSS)
2️⃣ Any user input reaching the database → parameterized query, never string concatenation (SQL injection)
3️⃣ Any user input written to logs → stripped of newlines (log injection)
4️⃣ Any file path built from user input → validated against traversal (../)
5️⃣ Any secret, key, or token → in env vars, never in the code it just wrote
6️⃣ Any dependency it imported → does that package actually exist? (AI invents package names, and attackers register them)

Number 6 is the one nobody checks. It has a name now: slopsquatting.

📎 Source: Veracode 2025 GenAI Code Security Report

Please send this to the person on your team who ships AI code the fastest.

#tools @codingforweb

🔬 30-second experiment. Ask AI for npm packages — then check if they exist.
Do this right now, before reading further:
Open your AI of choice and ask:
"Give me 5 npm packages for validating and sanitising user input in Express."
Now take each name and run:
npm view \<package-name>
Count how many don't exist.
——————
I'll tell you what the research says, but do it yourself first — the number means nothing until it's your number. A study across 16 models generated 576,000 code samples. Of every package name the models recommended:
▪️ 19.7% did not exist
▪️ Open-source models: 21.7% hallucinated
▪️ Commercial models: 5.2%
▪️ Total unique fake package names produced: over 205,000
And the models are consistent about it. Ask the same question twice and you often get the same invented name — which is precisely what makes this exploitable.

Here's the part that turns a curiosity into a threat. A researcher noticed models kept recommending a package called huggingface-cli. It didn't exist. So he registered it — empty, harmless, as a test. It got over 30,000 downloads in three months. Nobody attacked anyone. He just put a name where the hallucination pointed, and thousands of developers installed it because their AI told them to.
The attack has a name now: slopsquatting.
Register the package the AI invents, wait for people to install it.
🎯 Three seconds of defence:
Before you install anything an AI suggested, check the package page. Look at weekly downloads and the publish date. A real utility library with 40 downloads and a first release from last Tuesday is not a library. It's bait.

💬 Run the test and post your score in the comments. Which model, how many fake out of 5. I'm genuinely curious whether it's got better or worse.

📎 Source: "We Have a Package for You!" — USENIX Security

Forward this to someone who installs whatever the AI says.

#tools @codingforweb

💭 Tutorial hell is dead. Welcome to prompt hell 😵‍💫

You remember tutorial hell. You watch a 12-hour course, you follow along, everything works, you feel like you're learning. Then you open an empty file to build something yourself, and you have no idea what to type. That's mostly gone now. AI killed it. Nobody's stuck watching tutorials - you just describe what you want, and something appears.

So we invented a worse version 😈

Prompt hell is this: you ship things. Real things. A working app, a dashboard, an API that people use. From the outside, you look like a developer who's doing fine. And you cannot build anything without AI. Not "it's slower without it." Cannot 😣

The difference from tutorial hell is what makes it dangerous. In tutorial hell, you knew you were stuck - the blank file told you every day. In prompt hell, everything works, so there's no signal, no discomfort, nothing telling you something's wrong. You can stay there for two years.

Here's the test. Three questions, answer honestly:
1️⃣ Can you read a function you shipped last month and explain every line - not what it does, but why it's written that way?
2️⃣ When something breaks, is your first move to think, or to paste the error?
3️⃣ Could you build a small version of your last project with no AI at all - badly, slowly, but finish it? If it's no, no, no - that's prompt hell. It's not a character flaw. It's what happens when the tool removes the struggle, and the struggle was the part that taught you.

I'm not going to tell you to stop using AI. That advice is useless, and nobody follows it.

What actually works is narrower:
🔹 Write first, then ask. Attempt it yourself for ten minutes. Badly is fine. Then bring the AI in. The ten minutes is where the learning happens - everything after is editing.
🔹 Never accept code you can't explain. Not "I trust it." Explain it. If you can't, ask the AI to explain it, then check the explanation against the docs. It's wrong more often than you'd like.
🔹 Break things on purpose. Take working code, change one thing, predict what fails, check. Being right consistently is expertise. There's no other definition.
🔹 Once a week, build something small with nothing. No AI, no Stack Overflow. Thirty minutes. It'll be humbling the first few times. That humbling is the measurement you no longer get anywhere else. The developers who'll matter in five years aren't the ones who refused to use
AI, and they're not the ones who used it most. They're the ones who kept the struggle on purpose, after it stopped being mandatory.

Nobody's going to make you do that. That's the whole problem - and the whole opportunity.

💬 Honest answers only: how did you score on the three questions?

Forward this to someone who's shipping fast and quietly worried about it.

#learn @codingforweb

🙂 True Story

More interesting facts about the coding on my YT channel :)
https://www.youtube.com/@codingforweb-official
Videos are generated with AI, but I wrote the stories. This is my first time producing video content with AI, so don't judge me too harshly. Need your support, guys 🙏