As AI tools become increasingly integrated in many industries across all levels, there has been a quiet but undeniable shift. The tasks that used to be prevalent at the start of a developer’s journey are now disappearing because human performance is becoming increasingly unnecessary here.

AI systems now write HTML and CSS layouts practically in an instant. They can configure basic server infrastructure faster than any entry-level flesh-and-blood specialist. They generate boilerplate tests, documentation and repetitive scripts with perfect consistency.

What was once a six-month learning path for a junior engineer has now become something an AI assistant accomplishes in seconds. And it forces a difficult question to come into the spotlight: If the bottom rung of the ladder is gone, how are new developers supposed to climb at all?

The Work That Trained Juniors Is Now AI’s Domain

Looking at things in perspective, the arrival of Claude 4 Opus caused the conversation among engineering leads to change overnight. AI wasn’t just helping with tedious tasks anymore — it started assisting in architectural thinking and solution design.

Senior developers suddenly gained a partner capable of exploring trade-offs, generating alternative patterns and evaluating system behaviors. But juniors ended up losing the very tasks that once helped them get their footing.

Today, AI already confidently handles:

• HTML/CSS layout and basic frontend scaffolding
• Repetitive tasks like simple API handlers or routine refactoring
• Basic documentation and test generation
• Simple infrastructure configuration.

And it performs all these tasks quickly, consistently, without fuss or losing focus. The honest truth here is that AI’s ability to perform as a junior developer is actually quite impressive. But here’s the problem: If these tasks are no longer done by humans, how can humans learn and grow their own skills?

Learning To Code Feels Like Being Thrown in the Deep End

For a long time, the path into engineering was very hands-on. You just had to do things, plain and simple: Write enough code and eventually you’d build the intuition needed to think like an architect.

Today, with AI taking over a lion’s share of the work, beginners are pretty much asked to skip this part and go straight to senior-level thinking. This is a structural shift, and not at all an easy one.

The entry barrier into this field has suddenly jumped up because AI excels at exactly the kind of tasks juniors were traditionally supposed to struggle through and learn from. Struggle used to be part of the process, but now AI has removed the opportunity for this growth, making things a lot more challenging for newcomers.

And this is where I’d like to give my strongest advice to anyone learning right now: Don’t rely on AI assistants during your training. Yes, it’s tempting. Yes, it feels efficient. But it also prevents you from building the foundation and the instincts you will absolutely need later: understanding how systems behave and how errors emerge. Without personal practice, you won’t develop the thinking patterns that make a good engineer.

What Skills Will Actually Matter?

Looking more broadly, we can already see that the entire profession is shifting. In the future, developers won’t be valued for their coding skills; they’ll be valued for their ability to break down problems into tasks and then guide AI through those tasks and toward a functional solution.

Several qualities will become essential:

• Structural and architectural thinking: AI can generate implementations, but it still needs human thinking to define the boundaries, constraints and the overall purpose of what it’s supposed to be doing.
• Product sense: As I see it, future developers will increasingly look more like product managers with a technical background — someone who understands user needs, business value and how to translate that into precise instructions for an AI.
• Curiosity and resilience: If junior tasks vanish, it means that learning how to be a good developer will become mostly a self-driven process. It will require human specialists to push on entirely through their own determination.

These are the new criteria — or character traits, even — that I suspect will become the new baseline for hiring developers. In five to seven years, the word “developer” itself will likely mean something very different from today.

The role will likely hybridize: part engineer, part product thinker, part AI systems operator. The main responsibilities for these people will be guiding AI, validating its output and ensuring the end outcomes align with real-world business needs.

Coding will still matter, but mostly as a way to refine and debug what AI produces.

Not the End of Development, but the End of How We Start

It’s easy to look at this change and see it as a loss. But depending on how you view it, it could also be called a type of evolution. Junior coding isn’t vanishing because we no longer “need” developers. It’s vanishing because the definition of “developer” is transforming faster than our current education systems and job ladders can keep up.

The big challenge now is to rethink what an early career profile in this field should look like. Which skills truly matter for an up-and-coming professional in a world where AI already handles the code.

If we get this right, the next generation of engineers won’t be weaker. It will simply be different, shaped by new conditions to which they will have learned to adapt. The introduction of AI intro workflows doesn’t mean that issues will disappear entirely. New problems will require new solutions, and coming up with new solutions is, ultimately, still a human job.

The post How To Build a Developer Career When the First Rung Is Gone appeared first on The New Stack.

We're bringing you a special TechCrunch podcast crossover episode. Isabelle joins Equity Hosts Kirsten Korosec, Anthony Ha, and Rebecca Bellan to dissect the year's biggest tech developments, from mega AI funding rounds that defied expectations to the rise of "physical AI," and make their calls for 2026. 

The group tackled everything from why AI agents didn't live up to the hype in 2025 (but probably will in 2026), to how Hollywood will push back against AI-generated content, to why VCs are facing a serious liquidity crisis.  

Listen to the full episode to hear: 

• Why world models are the next big thing in AI and how they're different from large language models 
• The death of "stealth mode" for AI startups and the rise of alternative funding sources 
• Predictions on regulatory chaos around AI policy and what Trump's recent executive order means for startups 
• Hot takes on IPOs: Will OpenAI and Anthropic actually go public in 2026? 
• Rapid-fire predictions including Johnny Ive and Sam Altman's inevitable public breakup, the return of dumb phones, and why everyone will be calling themselves "AI native" 
• What's coming in Build Mode season 2: A deep dive into team building, hiring, and finding co-founders 

Chapters:

00:00 Intro - TechCrunch Build Mode & Equity Crossover Episode

00:27 Meet the Hosts - Predictions Episode Introduction

02:49 Reviewing 2024 Predictions - The Mega Funding Rounds

05:40 AI Startup Funding Challenges and Alternative Capital Sources

08:05 2026 AI Predictions - World Models and the Next Evolution

12:41 Physical AI - The Intersection of Robotics and Intelligence

14:07 AI in Media and Content Creation

18:48 Netflix-Warner Brothers Deal and FTC Predictions

21:09 The LP Direct Investment Trend

23:26 IPOs and Deep Tech Capital Challenges

25:49 Startup Battlefield Trends - Verticalized AI Across Industries

28:08 Rapid Fire Predictions - Fashion, Self-Driving Cars, and More

30:25 The Dumb Phone Comeback and Foldable iPhones

32:51 Build Mode Season 2 Preview - People and Team Building

New episodes of Build Mode drop every Thursday. Isabelle Johannessen is our host. Build Mode is produced and edited by Maggie Nye. Audience Development is led by Morgan Little. And a special thanks to the Foundry and Cheddar video teams. 

I am a huge fan of gistpreview.github.io, the site by Leon Huang that lets you append ?GIST_id to see a browser-rendered version of an HTML page that you have saved to a Gist. The last commit was ten years ago and I needed a couple of small changes so I've forked it and deployed an updated version at gisthost.github.io.

Some background on gistpreview

The genius thing about gistpreview.github.io is that it's a core piece of GitHub infrastructure, hosted and cost-covered entirely by GitHub, that wasn't built with any involvement from GitHub at all.

To understand how it works we need to first talk about Gists.

Any file hosted in a GitHub Gist can be accessed via a direct URL that looks like this:

https://gist.githubusercontent.com/simonw/d168778e8e62f65886000f3f314d63e3/raw/79e58f90821aeb8b538116066311e7ca30c870c9/index.html

That URL is served with a few key HTTP headers:

Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff

These ensure that every file is treated by browsers as plan text, so HTML file will not be rendered even by older browsers that attempt to guess the content type based on the content.

Via: 1.1 varnish
Cache-Control: max-age=300
X-Served-By: cache-sjc1000085-SJC

These confirm that the file is sever via GitHub's caching CDN, which means I don't feel guilty about linking to them for potentially high traffic scenarios.

Access-Control-Allow-Origin: *

This is my favorite HTTP header! It means I can hit these files with a fetch() call from any domain on the internet, which is fantastic for building HTML tools that do useful things with content hosted in a Gist.

The one big catch is that Content-Type header. It means you can't use a Gist to serve HTML files that people can view.

That's where gistpreview comes in. The gistpreview.github.io site belongs to the dedicated gistpreview GitHub organization, and is served out of the github.com/gistpreview/gistpreview.github.io repository by GitHub Pages.

It's not much code. The key functionality is this snippet of JavaScript from main.js:

fetch('https://api.github.com/gists/' + gistId)
.then(function (res) {
  return res.json().then(function (body) {
    if (res.status === 200) {
      return body;
    }
    console.log(res, body); // debug
    throw new Error('Gist <strong>' + gistId + '</strong>, ' + body.message.replace(/\(.*\)/, ''));
  });
})
.then(function (info) {
  if (fileName === '') {
    for (var file in info.files) {
      // index.html or the first file
      if (fileName === '' || file === 'index.html') {
        fileName = file;
      }
    }
  }
  if (info.files.hasOwnProperty(fileName) === false) {
    throw new Error('File <strong>' + fileName + '</strong> is not exist');
  }
  var content = info.files[fileName].content;
  document.write(content);
})

This chain of promises fetches the Gist content from the GitHub API, finds the section of that JSON corresponding to the requested file name and then outputs it to the page like this:

document.write(content);

This is smart. Injecting the content using document.body.innerHTML = content would fail to execute inline scripts. Using document.write() causes the browser to treat the HTML as if it was directly part of the parent page.

That's pretty much the whole trick! Read the Gist ID from the query string, fetch the content via the JSON API and document.write() it into the page.

Here's a demo:

https://gistpreview.github.io/?d168778e8e62f65886000f3f314d63e3

Fixes for gisthost.github.io

I forked gistpreview to add two new features:

1. A workaround for Substack mangling the URLs
2. The ability to serve larger files that get truncated in the JSON API

I also removed some dependencies (jQuery and Bootstrap and an old fetch() polyfill) and inlined the JavaScript into a single index.html file.

The Substack issue was small but frustrating. If you email out a link to a gistpreview page via Substack it modifies the URL to look like this:

https://gistpreview.github.io/?f40971b693024fbe984a68b73cc283d2=&utm_source=substack&utm_medium=email

This breaks gistpreview because it treats f40971b693024fbe984a68b73cc283d2=&utm_source... as the Gist ID.

The fix is to read everything up to that equals sign. I submitted a PR for that back in November.

The second issue around truncated files was reported against my claude-code-transcripts project a few days ago.

That project provides a CLI tool for exporting HTML rendered versions of Claude Code sessions. It includes a --gist option which uses the gh CLI tool to publish the resulting HTML to a Gist and returns a gistpreview URL that the user can share.

These exports can get pretty big, and some of the resulting HTML was past the size limit of what comes back from the Gist API.

As of claude-code-transcripts 0.5 the --gist option now publishes to gisthost.github.io instead, fixing both bugs.

Here's the Claude Code transcript that refactored Gist Host to remove those dependencies, which I published to Gist Host using the following command:

uvx claude-code-transcripts web --gist

Tags: github, http, javascript, projects, ai-assisted-programming, cors