Besides being a talking head on LinkedIn, I lead software development teams, mentor developers and help career changers learn to write complex software.

At the core of all these efforts is a simple goal: empowering developers and magnifying their capabilities.

Sometimes that means changing processes to allow teams to move faster, deploy code with less friction and confidence. In my courses and programs, empowerment is making the abstract practical with lessons and challenges which mimic the experience of being a software developer.

If you actually read this, thanks. Always happy to connect and check out the links in about section 😉

Brian Jenney

Apparently, if you’re not using:

• Opus 4.5 (but only for certain tasks)
• A different model for planning vs coding vs refactoring
• Custom rule files
• Per-project AI configs
• MD spec / rules docs
• Spec-driven planning phases
• Git subtrees
• “Ralph loops”
• Spec kit
• Carefully segmented prompting workflows

…then you’re "not using AI correctly."

To be fair, some of this is spot on. 

𝗕𝘂𝘁 𝗮𝘁 𝘀𝗼𝗺𝗲 𝗽𝗼𝗶𝗻𝘁 𝘄𝗲 𝘀𝗵𝗼𝘂𝗹𝗱 𝗽𝗮𝘂𝘀𝗲 𝗮𝗻𝗱 𝗮𝘀𝗸:

If it takes this much infrastructure to get AI to help us write decent code…

𝗜𝘀 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗿𝗲𝗮𝗹𝗹𝘆 𝘁𝗵𝗲 𝘂𝘀𝗲𝗿?

Or is the tooling still not as intuitive as we pretend it is?

The biggest performance gains I’ve seen don’t come from elaborate toolchains. They come from:

• Understanding the problem
• Being able to describe the problem clearly
• Giving the model the right context (look at 𝚊𝚐𝚎𝚗𝚝𝚜.𝚝𝚜 as an example to scaffold the next agent)
• Reviewing and iterating

Yes, rules files help. 
Yes, better workflows help. 
Yes, model choice matters.

But if someone needs a 14-step AI ritual just to build a CRUD app, we may have crossed from "power tools" into magic spells.

𝗔𝗿𝗲 𝘄𝗲 𝗮𝘂𝗴𝗺𝗲𝗻𝘁𝗶𝗻𝗴 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗼𝗿 𝗷𝘂𝘀𝘁 𝗮𝗱𝗱𝗶𝗻𝗴 𝗮 𝘀𝗲𝗰𝗼𝗻𝗱 𝗷𝗼𝗯 𝗮𝘀 𝗮𝗻 𝗔𝗜 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝗼𝗽𝗲𝗿𝗮𝘁𝗼𝗿?

I'm not saying either is wrong... I'm just saying.

Learn AI by Building: A Practical RAG Project to Get You Started 👇

The same company telling you "𝘞𝘦 𝘮𝘪𝘨𝘩𝘵 𝘣𝘦 6–12 𝘮𝘰𝘯𝘵𝘩𝘴 𝘢𝘸𝘢𝘺 𝘧𝘳𝘰𝘮 𝘮𝘰𝘥𝘦𝘭𝘴 𝘥𝘰𝘪𝘯𝘨 𝘮𝘰𝘴𝘵, 𝘮𝘢𝘺𝘣𝘦 𝘢𝘭𝘭, 𝘰𝘧 𝘸𝘩𝘢𝘵 𝘴𝘰𝘧𝘵𝘸𝘢𝘳𝘦 𝘦𝘯𝘨𝘪𝘯𝘦𝘦𝘳𝘴 𝘥𝘰 𝘦𝘯𝘥-𝘵𝘰-𝘦𝘯𝘥" is also rapidly expanding.

I wonder what roles they will be hiring for? 🤔

2 things:

1. Are CEOs of large companies really begging their eng department for... anything? Let alone to build a prototype? Why?
2. If you ARE doing this... cool! Using app-gen tools like v0, Lovable or Replit are great ways to create a "cheap" proof of concept with basic functionality.

Oh and lastly, if you're one of those dudes who claims they built an app over the weekend that is now doing 10K MRR and you have no clue how it works... you can take a long walk off a short bridge.

During a live coding interview last year, I instinctively switched from Cursor to VS Code.

The CTO stopped me.

“No — leave Cursor on. We want to see how you solve this with AI.”

I thought the interview would be easier.

It wasn’t.

“Are you using any AI tools we should know about?” “No.” “Great, can you explain what that first line of code is doing?” “You still there?” We never s

Open article: The CTO Told Me to Leave Cursor On. The Interview Got Harder. by Brian Jenney • 4 min read

The CTO Told Me to Leave Cursor On. The Interview Got Harder.

Tech Layoffs Translated:

“𝘞𝘦’𝘳𝘦 𝘧𝘭𝘢𝘵𝘵𝘦𝘯𝘪𝘯𝘨 𝘵𝘩𝘦 𝘰𝘳𝘨.” 
𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻: We overhired, and now we’re cutting back.  

“𝘞𝘦’𝘳𝘦 𝘣𝘦𝘤𝘰𝘮𝘪𝘯𝘨 𝘮𝘰𝘳𝘦 𝘦𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘵 𝘸𝘪𝘵𝘩 𝘈𝘐.” 
𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻: We told investors our massive bet on AI would pay off. It didn’t. Now we need to cut you.  

“𝘋𝘰𝘪𝘯𝘨 𝘮𝘰𝘳𝘦 𝘸𝘪𝘵𝘩 𝘭𝘦𝘴𝘴.” 
𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻: Tariffs, the markets, or simply bad bets have eaten our lunch. AI 𝘮𝘪𝘨𝘩𝘵 save us, but we don’t actually know how.  

We’ve heard some version of this nonsense since the pandemic. It likely won’t stop any time soon.   

Tech hiring continues to rise overall, but companies still over-hired, over-invested, and made short-sighted moves that are now being paid for by workers getting laid off.  

I was laid off a couple years ago.   
It was brutal.   

I had just bought a business, I have three kids and a mortgage. My biggest regret is not taking more time to reflect before jumping back into the job market. 

But I get it: you need a paycheck and the guise of stability. I did too.  

I ended up becoming part of the great reshuffle: moving from management and web dev into working with LLMs, AI and product engineering.  

If you’re impacted by layoffs, I’m sorry and I can relate.   

But if there’s any silver lining, it’s this: the next era of tech is being built 𝘳𝘪𝘨𝘩𝘵 𝘯𝘰𝘸. And the skills you build next could shape your entire career.  

Good luck out there.



I made a project for full stack developers who want to learn AI practically:

Open article: RAG with Next.JS by parsity.io

Do not attend if:

1. You're studying for Google, Meta, Netflix or massive tech orgs
2. You want some magical prompts to "hack" the interview
3. You'd just use a cache 😉

We're going to cover 3.5 patterns to help you nail your next technical interview outside big tech.

Mohamed Ahmed, Sarmad Razaq and 64 other attendees

View event: Interview Prep for non-FAANG: 3 Patterns that will Save You

Interview Prep for non-FAANG: 3 Patterns that will Save You

Nearly 100% of my code is AI-generated.

That doesn’t mean I’m not building software - it just means I’m not the one writing the code.

It's a weird time to be a coder but there's also massive opportunity hiding behind the hype and fear mongering...

If you’re trying to become a developer in 2026 or just entered the field, it probably feels like you showed up to the party five minutes after it ende

Open article: You Must Learn to Code So You Can Never Write Code Ever Again by Brian Jenney • 5 min read

You Must Learn to Code So You Can Never Write Code Ever Again

If you're a Typescript developer and you want to get started with AI agents, just do this:

1. Put $5 into OpenAI's API platform (or use Gemini's free tier) https://lnkd.in/gPM8D2Pq
2. Install Vercel's AI SDK: https://lnkd.in/gh-sND6r
3. Read up on common patterns for agents (human in the loop, ReAct, orchestration): https://lnkd.in/g3ekb3xr
4. Create a simple agent using tool-calling to do an internet search and summarize the results. You can use this API: https://www.searchapi.io/
5. Re-build your agent with a popular framework like LangGraph: https://lnkd.in/g9yB-_ec
6. Add unit tests and/or evals for your agent
7. Add an observability layer with Helicone or Langsmith: https://www.helicone.ai/
8. Grab this project to build your first agent: https://lnkd.in/gMv3x3tS

𝗦𝘁𝗲𝗽 𝟴.𝟱 - spend less time online arguing about whether or not LLMs will replace developers with people who can't solve FizzBuzz.

So you can just write Python in your NextJS app now.

What will those maniacs at Vercel cook up next? 🙇‍♂️

"𝘞𝘢𝘳 𝘪𝘴 𝘱𝘦𝘢𝘤𝘦. 𝘍𝘳𝘦𝘦𝘥𝘰𝘮 𝘪𝘴 𝘴𝘭𝘢𝘷𝘦𝘳𝘺. 𝘐𝘨𝘯𝘰𝘳𝘢𝘯𝘤𝘦 𝘪𝘴 𝘴𝘵𝘳𝘦𝘯𝘨𝘵𝘩."

I can only dissociate through code and AI hot takes for so long. It feels like a dark time is upon us in the US. But I'm always optimistic.

You may not know me personally, but I hope you're doing alright and keeping sane in an increasingly chaotic world.

RIP Alex Pretti

We get it. AI wRiTeS thE COde!

While most devs are optimizing their prompts, I think the fun (and opportunity) is a couple layers below:

1. 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 using frameworks like LangChain, Vercel's AI SDK or rolling your own
2. Learning how to to 𝗶𝗺𝗽𝗿𝗼𝘃𝗲 𝘀𝗲𝗮𝗿𝗰𝗵 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗶𝗻 𝘃𝗲𝗰𝘁𝗼𝗿 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲𝘀 like Qdrant and Pinecone
3. 𝗦𝗰𝗿𝗮𝗽𝗶𝗻𝗴 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗜 𝗲𝗿𝗮 using tools like Firecrawl and 𝚌𝚛𝚊𝚠𝚕𝟺𝚊𝚒
4. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 - basically figuring out how to organize what an LLM needs to know at what stage to give you a good response
5. 𝗟𝗟𝗠-𝗼𝗽𝘀 𝗮𝗻𝗱 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆. Monitoring token costs and model drift to see what breaks and why.

While everyone is glazing Claude or arguing over replacement theories, you could build up these skills and be prepared for software 3.0

If you’re using AI to write your code, here’s something you should know.

If you are:

• using AI to generate production code
• using AI to generate the tests
• using AI to validate its own output
• and then shipping it

Then you are MORE likely than a human to ship bugs and vulnerabilities.

Specifically, you are more likely than a human to:

• Introduce security vulnerabilities (~20-25% higher likelihood)
• Ship critical or major bugs (≈1.5–1.7× more per PR)
• Miss edge cases and failure paths in tests
• Over-test happy paths and under-test bad inputs
• Have “clean” builds that hide production risks

AI-written tests are less likely to test edge cases and over-use mocks.

LGTM! 😅

This doesn’t mean “don’t use AI.”

It means 100% AI-generated systems should make you pause and consider the risks.

Output scales fast. Judgment and maintenance won't.

Side Effects of Vibe Coding:

• Sensitive API keys were embedded directly in client-side JavaScript bundles, making them publicly accessible.
• Row Level Security (RLS) was disabled, allowing unauthenticated users full administrative read and write access to the database.
• Approximately 1.5 million agent authentication tokens, 35,000 user email addresses, and over 4,𝟬𝟬𝟬 𝗽𝗿𝗶𝘃𝗮𝘁𝗲 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝘄𝗲𝗿𝗲 𝗲𝘅𝗽𝗼𝘀𝗲𝗱.
• Reported participation metrics were misleading — 𝟭.𝟱 𝗺𝗶𝗹𝗹𝗶𝗼𝗻 “𝗮𝗴𝗲𝗻𝘁𝘀” 𝘄𝗲𝗿𝗲 𝗼𝗽𝗲𝗿𝗮𝘁𝗲𝗱 𝗯𝘆 𝗷𝘂𝘀𝘁 𝟭𝟳,𝟬𝟬𝟬 𝗵𝘂𝗺𝗮𝗻 𝘂𝘀𝗲𝗿𝘀 (an 88:1 ratio).
• Unauthenticated users could modify any live post on the platform, enabling widespread defacement and manipulation of content.
• 𝗣𝗿𝗶𝘃𝗮𝘁𝗲 𝗱𝗶𝗿𝗲𝗰𝘁 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝘁𝗵𝗶𝗿𝗱-𝗽𝗮𝗿𝘁𝘆 𝗢𝗽𝗲𝗻𝗔𝗜 𝗔𝗣𝗜 𝗸𝗲𝘆𝘀 stored in plaintext, putting users’ external accounts at risk.
 
Maybe Moltbook is the warning we need.

"𝘚𝘩𝘪𝘱 𝘧𝘢𝘴𝘵 𝘢𝘧 𝘶𝘴𝘪𝘯𝘨 𝘈𝘐 𝘵𝘰𝘰𝘭𝘴!"

What could go wrong? 

A lot apparently.

Challenge accepted.

Last year I spent a lot of time rallying against AI hype.

I also said a lot of things that are now less true than they were 6 months ago.

The models have improved.
Our collective workflows have improved.

I'm honestly not sure where the limit is and I'm excited John Crickett is working to find it.

CTO / VP Engineering / Head of Software Engineering

Think AI can’t handle real programming challenges? I think you're wrong!

So, let’s test that, together.

I keep hearing the same claim. AI is fine for toy problems, but it falls apart when you need real software built. I’m skeptical of that. I’m also skeptical of the hype.

So here’s an open challenge.

If you believe AI can’t solve a specific programming problem, or can’t build a particular kind of software, share the problem with me. I’ll attempt it using AI and document the process end to end.

If it works, I’ll show you how.  If it doesn’t, we’ll learn where the limits actually are.

This isn’t about proving anyone wrong. It’s about collaborative learning and evidence over opinions.

The rules for challenges are simple:

1. Well-specified and bounded. "Build the next Facebook" won't cut it. Give me a concrete, defined problem with clear scope.
2. Time-bound. I can dedicate a few hours, (maybe days if it's one that interests me) to each project, not months. For small-to-medium projects, that can mean building from scratch. For large codebases, it means fixing a specific bug or adding a well-defined feature.
3. Clear acceptance criteria. You define what "done" looks like upfront, so we all agree when or if it's solved.
4. Demonstrable. The result needs to be something I can share publicly so others can reproduce and verify the results.
5. No proprietary barriers. We need to be able to share the work so others can reproduce and verify the results.
6. Legal and ethical. Nothing that violates TOS, copyright, or involves malicious code.
7. You're available for questions. Well-specified tasks often have ambiguities that surface during implementation. I or the AI may need clarification as I work through it. 
8. Realistic performance expectations. If speed or efficiency matters, state your thresholds upfront.

To submit a challenge, document it in a public GitHub repo or Google Doc, then raise a PR adding it to this repo:
https://lnkd.in/ean_C-aU

So far, I’ve reviewed three challenges. Two were rejected, not because AI failed, but because the briefs weren’t workable. They lacked scope, acceptance criteria, or basic constraints.

That’s been the most interesting signal so far. 

The biggest blocker to using AI for software engineering doesn’t seem to be the AI.  It’s weak problem definition and missing software engineering fundamentals.

If you think that’s unfair, great.

 Bring a solid challenge and let’s find out.

Junior developers are inherently risky (in every industry, not just tech btw).

𝘉𝘶𝘵... 𝘐 𝘢𝘮 𝘢 𝘫𝘶𝘯𝘪𝘰𝘳, you say.

Yeah, I get it, I get it, just bare with me here.

The word junior is subjective. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗯𝗮𝘀𝗶𝗰𝗮𝗹𝗹𝘆 𝗯𝗼𝗶𝗹𝘀 𝗱𝗼𝘄𝗻 𝘁𝗼 𝗶𝘀 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 𝘄𝗵𝗼 𝗵𝗮𝘀 𝘀𝗼 𝗹𝗶𝘁𝘁𝗹𝗲 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝘁𝗿𝘂𝘀𝘁𝗲𝗱 𝘁𝗼 𝗱𝗼 𝗺𝘂𝗰𝗵 𝗼𝗻 𝘁𝗵𝗲𝗶𝗿 𝗼𝘄𝗻.

• They need significant hand-holding for months on the job.
• They will take on the easy stuff and maybe break some things.
• They won't contribute much.

𝗛𝗲𝗿𝗲'𝘀 𝘁𝗵𝗲 𝘁𝗵𝗶𝗻𝗴: nearly every developer will be junior when they first join a company unless they are very senior.

You don't actually need to a be a mid level developer to be a safe hire. You just need to avoid the tell-tale signs that you are, in fact, a n00b.

Quite simply, stop down-playing yourself.

• 𝗥𝗲𝗺𝗼𝘃𝗲 𝗷𝘂𝗻𝗶𝗼𝗿, 𝗮𝘀𝗽𝗶𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 from your resume and LinkedIn.
• DON'T talk about the project from your school or bootcamp
• 𝗗𝗢 𝗧𝗮𝗹𝗸 𝗮𝗯𝗼𝘂𝘁 𝘁𝗵𝗲 𝗮𝗽𝗽 𝗼𝗿 𝘄𝗲𝗯𝘀𝗶𝘁𝗲 𝘆𝗼𝘂'𝗿𝗲 𝗹𝗮𝘂𝗻𝗰𝗵𝗶𝗻𝗴 - yes, you need to have a project to talk about.
• 𝗨𝘀𝗲 𝘀𝘁𝗿𝗼𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝘁𝗼 𝘁𝗮𝗹𝗸 𝗮𝗯𝗼𝘂𝘁 𝘆𝗼𝘂𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 and speak to the benefits of features you created. 
• Instead of created a full stack app with a laundry list of tech try migrated a JS app to Typescript to improve developer experience and velocity.

I break down why you need to be building a product instead of a portfolio in 2026 with some resources to help you get started:

Open article: #300 - Build a Product, Not a Portfolio by open.spotify.com

I helped design the interview process for an AI start up where I used to work.

The job listing was for an "AI Engineer".

What that meant, practically, was:

1. 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘄𝗶𝘁𝗵 𝗥𝗔𝗚: chunking && re-ranking and opinions on retrieval strategies
2. 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗴𝗲𝗻𝘁𝘀 𝗮𝗻𝗱 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀: tool-calling vs orchestration, evals and testing
3. 𝗔𝗴𝗲𝗻𝘁 𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀: LangGraph, Vercel's AI SDK, etc. and when it makes sense to use them... or not
4. 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆: how do you control token costs and see where agents fail or drift from their expected behavior?

These skills really aren't too difficult for most experienced devs to learn.

Yet, it's incredibly difficult to find people who already have practical experience, made the costly mistakes and know what to avoid.

If you're a developer looking to build these skills for fun or to launch a product or maybe you're an engineering manager who is looking for a more technical understanding of RAG and agents, 𝗜 𝗰𝗿𝗲𝗮𝘁𝗲𝗱 𝗮 𝗵𝗮𝗻𝗱𝘀-𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁 𝗳𝗼𝗿 𝘆𝗼𝘂 𝘁𝗼 𝗹𝗲𝗮𝗿𝗻 𝗯𝘆 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴: https://lnkd.in/d6Pzfcg6

Don't let anyone tell you that junior engineers are becoming irrelevant.

It's probably a rough time to be browsing LinkedIn as a junior engineer. Lots of folks are making the prediction that your role is dying. I call BS.

I won't deny that the job market is rough right now, driven in large part by the death of ZIRP. But extrapolating "things are hard now" to "things will be hard hereafter" is a sloppy conclusion that misunderstands why companies hire junior engineers.

The myth that junior engineers can be replaced by Claude assumes that the job of junior engineers is to write code. False. The foremost job of junior engineers has *always* been to grow. Junior engineers are costly! And the largest slice of that cost is not their salary, it's the time and energy that senior engineers and managers devote to training them.

Why do companies bother? Because junior engineers grow over time. When you grow your own senior engineers from scratch, they come with built-in knowledge of your company's business and technology, and at least a measure of loyalty to the company. It's a higher-quality hire coupled with a longer gestation time. Not every company wants to make that trade-off, but the trade-off itself is not dying.

In fact, one of the key variables defining the value of that trade is time-to-promotion: how long until your junior engineers stop being so junior? And that's something that's actively in flux.

It used to be that the only way we knew to advance junior engineers was by handing them coding tasks. "Learn our technology by touching our technology." Along the way, you'd wrestle with things and ask your mentor a lot of questions. But make no mistake, there was more value created by teaching the engineer than by closing the defect report.

Coding agents have upended this in a crucial way: you can ask technical questions of your agent instead of your mentor. This decreases the burden of onboarding a new hire, and can increase the rate of knowledge uptake. After all, the agent is available 24/7, can see more of the codebase than your mentor has in their head, and has infinite patience for questions that you might be too embarrassed to ask a person. "Someone mentioned 'redis' in the team meeting, what is that and how does it work?"

Furthermore, today's junior engineers have the opportunity to be the first wave of "natives" on the new development paradigms. They will adopt them more fully, because it's all they've ever known.

So long as we believe that senior engineers are still valuable, there will also be value in pipelines that create senior engineers. There are good reasons to believe that this new technology can decrease the investment cost to create experienced engineers. It will take time for all the corners of the economy to adapt to this reality, but I don't believe this road ends with the death of the junior engineer. Stay courageous and stay curious.

While my YouTube channel has gained a lot of traction, my podcast is steadily declining in listeners.

On the podcast, I feel like I've formed a deeper connection with listeners and can be a bit more nuanced in my advice.

I'm making some changes to hopefully increase listeners on Spotify by going all in on video episodes.

Tomorrow, the first video podcast drops and I'd love to hear from you if you're a listener of the show.

What are topics you really want to know about? What are you struggling with?

DM me or leave a comment and let me know if you want a shout out if I use your topic/question. 

THANK YOU FOR YOUR ATTENTION TO THIS MATTER 🫡

At Parsity, we’ve been against AI tool use while students are learning to code.

This was not an easy decision and I'd be lying if I said I was 100% sure that this was the right move.

Emerging research (and what we see in practice) supports our position:

• 𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗮𝗹 (𝗺𝗶𝘀)𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴: Students finish tasks without building real mental models
• 𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 𝗶𝗻𝗮𝗯𝗶𝗹𝗶𝘁𝘆: Fewer mistakes == fewer chances to learn how systems actually break
• 𝗟𝗮𝗰𝗸 𝗼𝗳 𝗰𝗼𝗱𝗲 𝗰𝗼𝗺𝗽𝗿𝗲𝗵𝗲𝗻𝘀𝗶𝗼𝗻: Reading AI output != knowing how to write or fix it yourself
• 𝗦𝗸𝗶𝗹𝗹 𝗿𝗲𝘀𝗶𝘀𝘁𝗮𝗻𝗰𝗲: Performance drops when the AI “exoskeleton” is removed

Yes, AI can boost short-term productivity.
But learning to code was never about speed. It’s about building the brain.

That’s why our students learn fundamentals first.

AI comes later. Once they can evaluate, debug, and supervise it.

We’re not anti-AI.
We’re pro-skill formation.

White board interviews are biased, archaic and don't reflect the kind of work we actually do as developers.

Ok.

Let's pretend you're correct.

What do you do now?

You can either:

a. Avoid DSA and all companies that ask these questions (𝘐 𝘵𝘳𝘪𝘦𝘥 𝘵𝘩𝘪𝘴 𝘧𝘰𝘳 𝘺𝘦𝘢𝘳𝘴 𝘸𝘪𝘵𝘩 𝘷𝘢𝘳𝘺𝘪𝘯𝘨 𝘳𝘦𝘴𝘶𝘭𝘵𝘴)
b: Learn some of the most common patterns and data structures that make up the majority of questions out there

You can still avoid whiteboard interviews, because you WANT to, not because you HAVE to.


PS 👇

I break down 3 patterns you WILL encounter on the interview circuit and a free guide for developers who want to learn through hands-on challenges: https://lnkd.in/gEYY9sF5

More active on substack.com/@xdemocle

𝗗𝗜𝗦𝗖𝗟𝗔𝗜𝗠𝗘𝗥: This isn't a CV. For long-term contract inquiries, email hello@rocco.me or send a connection request.

---

I write code. I build systems. I tell the truth about what works and what's bullshit.

𝗪𝗵𝗮𝘁 𝗜 𝗱𝗼:
• Web3/blockchain integration for companies that want real solutions, not hype
• AI agent development for practical automation
• Cybersecurity education (because the space is full of scams)
• Mentoring devs who want to stop guessing and start shipping

𝗪𝗵𝗮𝘁 𝗜'𝘃𝗲 𝗯𝘂𝗶𝗹𝘁:
• DeFi platforms managing $20M+ in liquidity
• Frontend systems serving 5M+ users (SHIBA INU, Ajna Labs, Games Global)
• Smart contract integrations that reduced gas fees and improved transaction speeds
• Browser extensions protecting people from crypto scams

𝗪𝗵𝗮𝘁 𝗜 𝗱𝗼𝗻'𝘁 𝗱𝗼:
• Fake connections
• Clout chasing
• Take-home assignments (years of shipped code and references speaks louder)
• Processes that treat humans like data rows

𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗺𝗲:
• Building: Eveo (event marketplace), CyberGrandpa (anti-fraud extension)
• Writing: Substack newsletters on Web3, AI, scams, and career reality
• Teaching: How to refactor "vibe code" and build maintainable systems

Based in South Italy. Work globally. Remote-first.

If you're serious about blockchain integration, code refactoring, or building something that actually works, let's talk.

Rocco R.

Night is always the best moment for programmers. 

whatever your age, at night when others sleep, you as a developer, you give the best. 

others come from the 5am team... 

I can code at 5am only in intercontinental trips. 

here I am at 5 o'clock somewhere in my private jet.

p.s. they said if you work in a private jet you get more visibility. so I rented a jet.

Rocco Russo

I used to snap too.... 
then I stopped applying 😁

I bloody lost it!!! 

yes, I once lost my confidence... and this time ain't about dating, of course. 

Last year, I lost the confidence in believing in myself.

This post is for who is still looking for a job and maybe, who is also looking to gain back his/her/it confidence.

It's a closed door post. Just for my connections.
The ones I followed and shared the same uncertainty in the last 12-14 months.

I managed to get a good position, again, but this time the wait felt really terrible.

Despite the efforts and the positive mindset, rejection over rejection, I simply lost it all.

So, something had to be done.

I completely shut down any social activity, and even more, my social relationships... unfortunately, including my partner.

Anyway... I knew the right cure was to build, build, build!!! 

Some others would have escaped to the gym or any other sort of hobby. Nothing wrong with it.

But as a provider, I just couldn't deal with investing my time and health on anything that wouldn't give me a short coming back and a boost in my projects portfolio, but most importantly focus again on what I like the most in my passion/job.

So, damn, it's useless torturing ourselves with bad thoughts.

Let's go back to what we really like!

I believe by now, that time heals pretty much everything. It won't pay the bills or our loan, but at least it would help us to give ourselves a break time by time.

Let's love ourselves more. Because after all, how can I even pretend to love somebody, if I barely care of myself!?

Anyway, Cheers people! Hold tight and keep it easy.

P.S. it's the first trimester of the year. All experts in the hiring industry saying it's the best period for the number of job opportunities. Hence, I wish you all good luck, please try another sprint more. Something good is on his way to you.

𝗠𝗢𝗦𝗧 𝗧𝗘𝗖𝗛𝗡𝗜𝗖𝗔𝗟 𝗜𝗡𝗧𝗘𝗥𝗩𝗜𝗘𝗪𝗦 𝗧𝗘𝗦𝗧 𝗔𝗡𝗫𝗜𝗘𝗧𝗬 𝗧𝗢𝗟𝗘𝗥𝗔𝗡𝗖𝗘, 𝗡𝗢𝗧 𝗖𝗢𝗗𝗜𝗡𝗚 𝗔𝗕𝗜𝗟𝗜𝗧𝗬. 𝗛𝗘𝗥𝗘'𝗦 𝗪𝗛𝗔𝗧 𝗜 𝗗𝗢 𝗜𝗡𝗦𝗧𝗘𝗔𝗗.

I stopped doing whiteboard coding interviews in 2024. Watching a senior developer freeze while writing FizzBuzz doesn't tell me if they can ship production code. It tells me they're nervous.

Here's what years taught me: the best engineers I've worked with would've failed most standard interviews. The worst ones aced them.

𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺

Live coding under pressure tests one thing: performing algorithms while someone watches. That's not the job.

The job is reading messy codebases. Debugging at 2am. Making decisions with incomplete information. Shipping features that don't break under load.

We make senior devs reverse binary trees because Google does it. You're not Google. Your product isn't a search algorithm.

𝗪𝗵𝗮𝘁 𝗜 𝗗𝗼

First, existing work. GitHub repos, production apps, code reviews. If you've been coding for 10 years, show me something.

Second, architecture discussion. 45 minutes on a real problem: "50,000 users hit this endpoint. Response times spiked to 8 seconds. How do you fix it?"

This reveals how they think through ambiguity. What questions they ask. Whether they understand tradeoffs. No whiteboard. No artificial pressure.

Third, paid trial project for intermediate roles. Tackle a real backlog issue. Work async, use any resources. Submit a PR. They appreciate not doing free work. We see real output.

𝗥𝗲𝘀𝘂𝗹𝘁𝘀

I've hired a dozen developers this way. Two didn't work out.

Before: hired LeetCode winners.

After: hired proven shippers. Ramp-up dropped from 3 months to 3 weeks.

For seniors, generally I prefer a time cutting like a tech interview with shared screen, eventually. Many were failed by myself, but they taught me a lot. Not just: I must write by memory a reverse binary or any of List of algorithms on Wikipedia.

If your interview makes experienced devs feel like high school math class, you're selecting the wrong traits.

You're hiring for jobs, not exams.

𝗪𝗵𝗮𝘁'𝘀 𝘁𝗵𝗲 𝘄𝗼𝗿𝘀𝘁 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝘆𝗼𝘂'𝘃𝗲 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲𝗱?

I shipped two websites in 48 hours using AI assistance. Here's what actually happened.

First: rocco.me, my personal brand site. Second: linkedin-roccorusso.work, an updated portfolio. Both started from Lovable.dev boilerplates. Both got rebuilt to match what I needed.

The process wasn't plug-and-play. I got decent scaffolding with React, TypeScript, and Tailwind. Then the real work started.

Ripped out generic sections. Rebuilt the navigation. Integrated RSS feeds from my four Substack newsletters. Connected Calendly for booking calls. Made everything purple and blue because that's my brand. Stripped placeholder content and added real project data.

**What worked:** Lovable gave me structure without the usual setup hell. No wasting time on folder architecture or build tool debates. The AI understood context when I said "make this compact" or "add a project card." Saved actual hours.

**What didn't:** AI can't figure out your positioning. It suggested a copy like "innovative solutions" until I told it to sound like me. You still need to know what you're building. The tool speeds up execution, not strategy.

Here's the thing most people miss about AI-assisted development. It doesn't replace you. It removes the boring parts so you can focus on decisions that matter. What story does your site tell? Which projects prove you know what you're doing? How do visitors become clients?

Those questions need your brain, not an algorithm. They require taste and understanding of your market.

If you're building something similar, use AI for structure but not strategy. Customize everything. Templates are starting points, not destinations. Ship fast and fix based on real feedback. Don't overthink your tech stack.

Both sites are live now. One positions me for consulting. The other shows my work history. Neither is perfect. Both are online.

That's what counts. #newproject

No alternative text description for this image

YOU WON'T IMAGINE, BUT THE WORST HAS BEEN: ChatGPT Codex 5.2, so far!!! (Yes, I couldn't believe myself)

So, this past Sunday I decided to test UI design/coding capabilities of several LLMs. I made a simple SportBook with lovable, no rocket science. (You can see first slide attached)

Prompt was the same for all of them: formal, detailed, and with all instructions for the new design and support for light/dark theming.

The slides attached are in sequence like this:
- Original web design;
- Proposed redesign;
- Gemini 3 Flash, design implementation;
- Claude Opus 4.5, design implementation;
- Gemini 3 Pro, design implementation;
- Claude Sonnet 4.5, design implementation;
- ChatGPT 5.2, design implementation;
- ChatGPT Codex 5.2, design implementation;

Will follow a poll to require your opinion! :)))

BetAfrica redesign LLM tests

To all my US contacts: 
Bru, another little bit and we are about to become enemies over a piece of ice. 🤣🤣🤣🤣

the scammer this time perfectioned his prompt. using even a more reliable hourly range more market aligned... 

but still he managed to ruin it. 😁

he changed subject of the project three times, copy and paste randomly and then this closing that would actually looks legit, if not all the rest. 

the hourly range sounds a bit off, and in all honesty, it's rare that somebody tells you such info during the first touch. 

what do you think? how could she/he improve next? 😁😁

Not me taking notes with my phone on my work laptop!!??

Now, dear Indian brothers and sisters, I do understand you. 🤣🤣🤣

𝗜 𝗝𝗨𝗦𝗧 𝗥𝗔𝗡 𝗔 𝗦𝗢𝗖𝗜𝗔𝗟 𝗘𝗡𝗚𝗜𝗡𝗘𝗘𝗥𝗜𝗡𝗚 𝗘𝗫𝗣𝗘𝗥𝗜𝗠𝗘𝗡𝗧 (𝗢𝗡 𝗠𝗬𝗦𝗘𝗟𝗙)

Last week I matched with someone on a dating app. Smart conversation, shared business interests, good energy. We talked for days about real estate, startups, future plans.

Day 4: "Could you send me 50k for salon? If you can't, it's okay."

I declined. She went cold. Next day she came back aggressive. "You're not making sense." "I'm confused about your intentions." When I joked about something unrelated, she snapped: "I'm not a beggar."

I blocked her.

Then I got curious.

I contacted her from a different number with an obvious callout. Her response was a pre-loaded script. Counter-accusations, personal attacks, empty legal threats. She mocked my business details and claimed she'd report me to embassies.

Here's what caught my attention: she didn't recognize me. Not the conversation style. Not the specific details I'd shared. Nothing.

She responded like this was routine. Another guy who caught her scam. She just ran her standard defense protocol and plugged in whatever details she remembered.

This wasn't desperation. This was infrastructure.

The operation had phases. Trust building for 3-4 days. Financial probe disguised as casual request. Emotional manipulation cycles based on compliance. She had backup narratives ready. Frozen accounts, theft, family emergencies. Multiple stories on deck.

Volume targeting was obvious. I was clearly one of many.

She even admitted it: "It's normal, especially when we never met."

Translation: I know this is wrong, but I'm doing it anyway.

Social engineering works because we want to be helpful. We want to trust. We fill in gaps with sympathetic narratives.

I wrote backstories for her that she never gave me. "Car problems," "bad day," "financially desperate." Classic cognitive bias. We make excuses for people we want to trust.

The fix is simple. Treat early connections like security testing. Verify before trusting. Watch for pattern deviations. When someone shows you who they are, believe them the first time.

The same patterns apply everywhere. Phishing attempts in business, investment scams, fake partnership proposals. The mechanics are identical: build trust, create urgency, extract value, disappear when challenged.

Good security isn't about being paranoid. It's about being systematic.

You don't need to suspect everyone. You need clear protocols. What information you share when. What red flags trigger verification. How quickly you move from virtual to verified. When you walk away without explanation.

I got lucky. I caught it before losing anything except time. But I learned something useful.

The best defense against social engineering is treating pattern recognition as a skill you actively practice. Not just in cybersecurity. Everywhere.

The woman who tried to scam me probably moved to the next target within an hour.

𝗛𝗮𝘃𝗲 𝘆𝗼𝘂 𝗲𝗻𝗰𝗼𝘂𝗻𝘁𝗲𝗿𝗲𝗱 𝘀𝗶𝗺𝗶𝗹𝗮𝗿 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀?

leggetelo. è a proposito dei nostri cari bambini.

☠️💥 LA MAPPA DEGLI ORRORI: OGNI SINGOLO PUNTO ROSSO E' UN COMPUTER CHE TRAFFICA IMMAGINI DI ABUSI SU MINORI ☠️💥

Sto avviando un'importante collaborazione con la #NAPC (National Association to Protect Child). E' fantastico ciò perché loro sono eccezionali e fanno veramente un ottimo lavoro. La loro #mission si fonda sulla convinzione che il nostro primo e più sacro obbligo come genitori, cittadini ed esseri umani sia la protezione dei bambini, mission che come sapete bene sposo perfettamente.

La mappa che vedete è stata generata dalla Task Force sui crimini informatici contro i minori (#ICAC) dell'ufficio del Procuratore Generale del #Wyoming, qualche anno fa. All'epoca, l'ICAC ospitava la rete informatica utilizzata da una rete nazionale di task force delle forze dell'ordine ed era in prima linea per mappare tutti gli accessi e i nodi malevoli che trafficavano tale materiale. 

Si possono vedere ben in evidenza cluster di oltre 300.000 computer univoci che si scambiano un sottoinsieme di immagini di minori su un'unica rete. Ad oggi la situazione è sempre molto grave, al netto degli sforzi dell'Amministrazione #Trump nel cercare di debellare il più possibile questo fenomeno criminoso.

Qui in #Italia su questo sto lavorando per:
🟢 Creare una comunità satellite all'NAPC.
🟢 Realizzare una rubrica ed un portale informativo e divulgativo. 
🟢 Promuovere delle giornate ed eventi formativi in collaborazione con le Istituzioni.

Apprezzo tantissimo anche solo una reazione, un commento ed una diffusione di questo post, ma se qualcuno volesse fare leggermente di più e supportarmi, non esiti a scrivermi. 

Grazie di ❤️
Claudio Lauretti

A Saudi prince/investor finally accepts your connection request....

How much are you going to wait before hitting his inbox? 

Considering my post about LLM Sportbook redesign, please shout your vote! :))

Here the post with slides:
https://lnkd.in/d9v-YNYy

So, based on the the slides attached in my redesign post, what's the best LLM you choose for this job?

taplio

The Battle

Brian Jenney

Rocco R.

Followers

Posts

Engagements

Likes

Performance ScoreBrian Jenney's LinkedIn Performance

Performance ScoreRocco R.'s LinkedIn Performance

Ready to grow your LinkedIn presence?

taplio

The Battle

Brian Jenney

Rocco R.

Followers

Posts

Engagements

Likes

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}Brian Jenney's LinkedIn Performance

Performance ScoreRocco R.'s LinkedIn Performance

Ready to grow your LinkedIn presence?

Performance ScoreBrian Jenney's LinkedIn Performance