The "Coding is Dead" Myth: Why Prompting is Still Developing

zzDanDanzz — Mon, 15 Jun 2026 11:23:33 +0000

There is an ongoing debate about agentic AI and using generative AI to write code or autonomously edit files. It usually boils down to one anxiety-inducing question: Has coding been solved?

What that question is really asking—and what is stressing out so many people in the tech industry—is: Do we even need developers anymore?

Here is my take.

Prompting vs. Purism: You're Still a Developer

Whether a developer has memorized the exact syntax and APIs required for their environment (like the browser API for JavaScript) or they just write a plain prompt in English, Spanish, or Persian—they are still developers.

They are developing a solution. They are producing an outcome. If the project goals are reached, they are being productive.

It doesn't matter if you open up a terminal and restrict yourself to coding in Vim without any plugins, auto-completion, or syntax highlighting, pressing every single key to specify the exact characters in a file. And it doesn't matter if you say "yuck" to traditional code and only use natural human language to instruct an AI to do the dirty work.

In both scenarios, you are building software. In both scenarios, you can create amazing things—and in both scenarios, you can completely mess things up.

The Big Picture and the "AI Dead End"

Even if we reach a point where we never need to memorize syntax again, we still need to understand the big picture. We need to grasp the system architecture and how different components are interconnected.

Why? Because you have to be able to judge the AI's output.

When the AI hallucinates or breaks something, the human in the loop has to help it clean up and fix its mistakes. AI frequently reaches "dead ends"—complex logic traps that, no matter how many agents you throw at the problem, simply cannot be resolved without human intervention.

At the end of the day, we still live in a world that requires human supervision. Even if a human decides not to write a single line of traditional code, they still have to use their non-artificial intelligence. They have to form thoughts, evaluate the system, and transfer those thoughts to the AI—whether through a voice-to-text prompt or by typing out instructions. The medium doesn't matter; the human cognitive effort does.

The Trivial vs. The Complex

It is true that AI excels at straightforward tasks. If a project manager says, "Hey, change the background color on the landing page," you can just hand the codebase to your agentic AI. It will find the right CSS element, make the change, and you can move your Jira ticket to 'Done'. You get paid, you're happy, and your PM is happy.

But not all problems are that straightforward.

Most real-world engineering requires you to actually talk to the AI, iterate on the logic, and think deeply about the problem. You have to be intimately involved in the problem-solving process. As long as software requires navigating complex, ambiguous business logic where a human must remain in the loop, we have by no means gotten rid of the developer.

A Meta-Example: Writing This Article

In fact, this very article is a perfect example of this dynamic. I used AI to help structure, format, and refine the wording of the post you are reading right now. But the actual raw thinking, the core opinions, and the initial draft that served as the input to clean up this article? That came entirely from non-artificial, real human involvement. The AI didn't invent my perspective; it just helped me compile it. Just like in modern coding, the AI handled the boilerplate, but the human drove the logic.

The Job Evolves, The Human Remains

Maybe the job title will change. Maybe our daily workflow will look completely different in five years.

But thinking—specifically, non-artificial intelligent thinking—is still strictly required to solve real problems. Humans still exist in the loop, and we aren't going anywhere anytime soon.

Deploying Next.js to Github Pages

zzDanDanzz — Tue, 02 Aug 2022 16:53:00 +0000

important: this will use next export so the Next.js server won't be running and you won't have things like API routes or catch-all routes in your regular pages (for more details see the docs)

(by the way, I learned all of this by looking at the official Next.js example for usage with github pages)

Ready? Let's go.

Update `next.config.js`

const nextConfig = {

  // ... you might have other stuff above here!
  // just add this basePath property
  basePath: 'REPOSITORY_NAME'
}

module.exports = nextConfig

Why?

By default when running next export, Next.js expects the root of your site to be <some_domain_name>.com/ but that's not (always) what happens with Github Pages. If you create a Project Site (which means you just have a random project on a random repo and you wanna enable github pages for it) then your URL will be: https://<your_github_username>.github.io/<name_of_repository>/ and we need to take into account that extra <name_of_repository>/ at the end by modifying basePath in the Next config.

HOWEVER, now when you run a dev server at http://localhost:3000/ you need to append that basePath there too! so if your repo is called 'awesome-app' and you change your basePath to be '/awesome-app' now you can access your app at http://localhost:3000/awesome-app

Though you have to skip this step in some cases:

for user and organization sites it will be https://<your_github_username>.github.io. and from what I understand (haven’t tried it) for both the project site and user/organization site you can set up custom domains but in any case you can skip this part because the root of your site is in accordance with the default basePath.

build and export

Run the following commands in order:

npx next build - build your app
npx next export - create static export of your app

if all goes well, you should see an ‘out’ folder inside of which are the files github is going to serve

add .nojekyll file to the out/ directory

to opt out of using jekyll (since you’re using next.js) with github pages you have to add a .nojekyll file to out/

command: touch out/.nojekyll

commit changes

run git add out/ -f then git commit -m "Deploy"
you need to add the -f option because git will complain about the out/ dir being in .gitignore

and one last (awesome) command

git subtree push --prefix out origin gh-pages
this will make a new branch called gh-pages on the remote repository origin (which is on github) and in this new branch it will have all the content inside of the out/ directory but they will all be in the root so that the files can easily be served by github from that branch.

make the workflow easy

you can add this "deploy" script to your package.json

  "scripts": {

    // ... you might have other scripts above and around!

    "deploy": "next build && next export && touch out/.nojekyll && git add out/ -f && git commit -m \"Deploy\" && git subtree push --prefix out origin gh-pages"

  },

and run it with the command npm run deploy or yarn deploy

DEV Community: zzDanDanzz