DEV Community: Thierry Njike

When AI Becomes Expensive, Human Judgment Becomes Priceless

Thierry Njike — Fri, 01 May 2026 14:17:16 +0000

The headlines are loud and a little unsettling: AI is consuming staggering amounts of energy, companies are burning through cash to keep these systems running, and as a result, AI tool pricing is creeping steadily upward. For developers already anxious about being replaced by the very tools they're being asked to use, this feels like a particularly cruel plot twist.
But here's the uncomfortable truth most think-pieces miss: the situation is far more nuanced than "AI is coming for your job." And the rising cost of AI might, paradoxically, be one of the best things to happen to the developer profession in years.
Let's unpack it.

The Fear Is Real, But Only Part of the Story

It would be dishonest to pretend developers have nothing to worry about. The data tells a mixed story.
Entry-level roles are genuinely under pressure. Employment for software developers aged 22–25 has declined nearly 20% from its 2022 peak, and entry-level tech hiring dropped 25% year-over-year in 2024 (Stack Overflow, 2025). Tech internship postings have fallen 30% since 2023 according to Handshake. These are real numbers affecting real people, especially those just starting their careers.
Some executives have leaned in aggressively. Salesforce CEO Marc Benioff publicly stated the company stopped hiring engineers in 2025, pointing to AI productivity gains. Anthropic's own CEO Dario Amodei has speculated that AI could eventually eliminate up to 50% of entry-level jobs.
So yes, there is a real disruption happening at the junior end of the market.

But Look at the Bigger Picture

Zoom out, and the picture changes dramatically.
Job openings for software developers on Indeed are up 11% annually. A faster rate than job postings overall. A Bank of America survey found that companies are not just maintaining but expanding their software budgets and increasing engineer headcounts. The U.S. Bureau of Labor Statistics projects software developer employment to grow 17.9% between 2023 and 2033 (CNN Business, 2026). Nearly five times faster than the average for all occupations.
Companies don't just want less software. They want more of it. AI is enabling that expansion. The question isn't "will there be developer jobs?". It's "what will those jobs look like?"
IBM is a revealing case study here. Rather than cutting engineering staff, the company is tripling entry-level hiring in the United States. The role has simply evolved: instead of writing boilerplate code, developers now work directly with customers, specify features, and oversee AI-generated output. As IBM's General Manager of Automation and AI put it, the job shifted from "routine coding" to "being the person who directs the AI and understands the business well enough to catch its mistakes."

The Productivity Paradox: AI Isn't as Magic as We Thought

Here's where it gets genuinely fascinating, and where the cost conversation becomes critical.
In early 2025, a landmark study by METR (a non-profit AI safety organization) measured the real-world productivity impact of AI tools on experienced open-source developers. The result? Developers using AI tools actually took 19% longer to complete tasks than those working without AI. This directly contradicted what developers believed, they estimated AI was speeding them up by 20%.
This isn't an argument against AI tools. The study itself acknowledged that models have improved rapidly since, and that developers in follow-up studies were so dependent on AI that many refused to work without it. But it does expose a truth the industry has been reluctant to admit: AI assistance is not free productivity. It comes with context-switching costs, hallucination-checking overhead, and prompt engineering time that often goes unaccounted for.
Add to this the very real cost pressures companies are now facing. A 2026 survey of software engineers found that companies routinely spend $100 - $200 per engineer per month on AI coding tools. Around 30% of developers regularly hit usage limits. Budget managers are "increasingly nervous" that AI-related costs are "headed only one way: up."
The era of unlimited cheap AI is over. The tab is coming due.

The Proof Is Already Here: GitHub Copilot Just Changed the Rules

If you needed a concrete example of this cost shift in action, look no further than what happened on April 27, 2026.
GitHub announced that all Copilot plans will transition to usage-based billing on June 1, 2026. Instead of flat subscriptions with a fixed number of "premium requests," users will now consume monthly allotments of GitHub AI Credits, calculated based on actual token usage: input, output, and cached tokens, according to published API rates per model.
The reasoning GitHub itself gave is telling: "Copilot is not the same product it was a year ago." The tool has evolved to power far more complex, agentic workflows that consume dramatically more compute. Flat-rate pricing is simply no longer sustainable.
What does this mean in practice? Heavy users of agentic features, those running Copilot across pull request reviews, multi-step coding agents, and cloud-based workflows will almost certainly see their costs increase. Code completions and basic suggestions remain unlimited, but every advanced AI interaction now has a price tag attached. Fallback experiences (where exhausting your quota would drop you to a cheaper model) are being retired entirely.
This isn't a GitHub-specific quirk. It is a signal from the most widely-used AI coding tool in the world that the era of unlimited cheap AI assistance is definitively over.

Will Companies Abandon AI and Return to Manual Development?

Bluntly: No. That ship has sailed.

A return to pre-AI workflows is essentially unthinkable for any company that has integrated these tools into their pipelines. The 2025 Stack Overflow Developer Survey found 80% of developers now use AI in their workflows. In the follow-up study, some developers described working without AI as feeling like "trying to get across the city walking when you're used to taking an Uber." The dependency is structural now.
What will change is how companies approach AI costs. We're already seeing it: teams hitting limits switch tools, consolidate licenses, or move to API-based pricing for more control. The era of every developer having an unlimited premium AI subscription will give way to tiered access based on role and actual need.
This creates a natural stratification, and here is where experienced developers have a profound advantage.

The Developer Who Survives (and Thrives)

The pattern emerging across companies. From IBM to Intuit to mid-sized firms is consistent: the value of a senior developer is not decreasing. It is increasing.
Why? Because AI needs supervision. Code generated by AI tools accumulates what engineers are calling "AI slop". Plausible-looking code that introduces subtle bugs, technical debt, or security vulnerabilities that only an experienced developer can catch. Junior developers who don't yet have the pattern recognition to audit AI output can actually deliver worse results than they would working manually. A problem that compounds as more of their daily work becomes AI-assisted.
Companies covet what AI cannot replicate: deep domain understanding, architectural judgment, the ability to ask the right question before generating any code at all, and the wisdom to know when AI output shouldn't be trusted.
The Stack Overflow survey puts this in sharp relief: 64% of developers do not see AI as a threat to their jobs, though this is down from previous years. The developers feeling most secure aren't the ones ignoring AI. They're the ones who've made themselves indispensable because of how well they use it.

A Note for Junior Developers

The concern is legitimate, and it deserves to be acknowledged honestly. The pathway that once existed: learn to code, get a junior role, grow into a senior engineer over years of mentored practice has been disrupted. Entry-level roles are disappearing faster than they're being replaced by new AI-era equivalents.

The answer is not panic. It's a radical adaptation.

The developers positioned best for this market are the ones who understand AI tools not just as coding assistants but as systems to be architected, evaluated, and directed. Prompt engineering, understanding model limitations, building AI-native workflows, and contributing to AI integration projects. These are the differentiators that matter now. Senior engineers want junior collaborators who understand these tools well enough to save them time, not create more review overhead.

Conclusion

AI is expensive. It's getting more expensive. Companies are feeling the weight of that. But the answer to "should we keep paying for AI?" will almost always be yes because the alternative is falling behind competitors who do.
The developer profession isn't dying. It's under enormous pressure to evolve, and that evolution is happening faster than most people expected. Rising AI costs actually create a healthier market: they force companies to be deliberate about how AI is used, which elevates the value of developers who understand how to use it well.
The developer who should be afraid is the one who treats AI as either an existential threat to avoid or an infinite magic box to blindly trust. The developer who will thrive is the one who understands it as a powerful, expensive, imperfect tool, and has the skills to use it better than anyone else.
That has always been the job description. The tool has just changed.

What do you think? Are AI prices changing how your team approaches development? Share your experience in the comments.

References

Stack Overflow — 2025 Developer Survey (December 2025) Developers remain willing but reluctant to use AI: The 2025 Developer Survey results are here.

https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/
CNN Business (April 2026) The demise of software engineering jobs has been greatly exaggerated.

https://www.cnn.com/2026/04/08/tech/ai-software-developer-jobs
The Pragmatic Engineer (April 2026) The impact of AI on software engineers in 2026: key trends.

https://newsletter.pragmaticengineer.com/p/the-impact-of-ai-on-software-engineers-2026
METR (July 2025) Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
METR (February 2026) We are Changing our Developer Productivity Experiment Design.

https://metr.org/blog/2026-02-24-uplift-update/
Stack Overflow (December 2025) AI vs Gen Z: How AI has changed the career pathway for junior developers.

https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/
U.S. Bureau of Labor Statistics (March 2025) AI impacts in BLS employment projections — The Economics Daily.

https://www.bls.gov/opub/ted/2025/ai-impacts-in-bls-employment-projections.htm
Virtue Market Research (2025) AI Developer Tools Market — Size, Share, Growth | 2025–2030.

https://virtuemarketresearch.com/report/ai-developer-tools-market
GitHub Blog (April 27, 2026) GitHub Copilot is moving to usage-based billing.

https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
GitHub Docs (April 2026) Preparing for your move to usage-based billing.

https://docs.github.com/en/copilot/how-tos/manage-and-track-spending/prepare-for-your-move-to-usage-based-billing
GitHub Changelog (April 27, 2026) GitHub Copilot code review will start consuming GitHub Actions minutes on June 1, 2026.

https://github.blog/changelog/2026-04-27-github-copilot-code-review-will-start-consuming-github-actions-minutes-on-june-1-2026/

Cloud run jobs, your parallel tasks solution

Thierry Njike — Mon, 19 Jun 2023 10:26:32 +0000

Introduction

We usually need to accelerate our tasks without using a lot of resources. It's now possible on Cloud Run. Jobs is a serverless brand-new feature of Cloud Run that is GA since March 23rd 2023. In this article, I will first compare Cloud run and Cloud Functions (1st gen and 2nd gen), then I will explain how Cloud Run jobs works. Then, I will show some use cases where you could use Cloud Run jobs instead of other serverless options. Finally, there will be a basic demo to apply what is explained in the previous parts.

Comparison between serverless options

This is a diagram that shows which product is more suitable depending on the job to perform.

How does it work ?

Cloud Run jobs can execute a single task or a group of tasks as well. When you create a job, you set the number of tasks that contains your job. This number is saved as an environment variable that you can directly use in your code without defining it yourself. Each task is identified by its index, starting from 0 which is also saved as an environment variable directly useable in the code. So, after the creation of your job, Cloud Run creates 2 environment variables which are:

CLOUD_RUN_TASK_COUNT: which is the total number of tasks of the job
CLOUD_RUN_TASK_INDEX: which is the index of the current task

These environment variables are not visible on the job's configuration page. Theirs names are conventional.

When creating a job, you must select an image to use. This image could be stored on Artifact registry, or Docker. For other container registries, follow the steps described on this page. But Google recommends to use Artifact registry. If you face an issue about violated constraint (low carbon), follow the step described in my previous article.

A job can be split into up to 10,000 tasks. Each task creates a new instance of the image and run independently of the others. If a task fails, the job fails too, even if all the others ended successfully.

Use cases examples of Cloud Run jobs.

1- Large dataset

Let's suppose a situation where we have to process a large dataset of 1milion lines. Cloud Run jobs could help us to split the dataset into several smaller datasets and process them separately. Thereby, we can split the job into 100 tasks and process 10000 lines per task.

2- Replications

Imagine that we want to replicate data from 3 external databases to cloud storage. You can do it with a single cloud run job and assign a task per database. So, depending on the index of the task, the corresponding database credentials will be used, without duplicating code.

3- Unsupported language

Cloud functions supports only 7 languages (Node.js, Python, Go, Java, C#, Ruby and PHP). So, you won't be able to use cloud functions with a bash code. One of the advantages of Cloud run jobs is that the code language does not matter because it uses image's containers. Thereby, you just have to create your image and set an entry point.

We can imagine a lot of use cases of cloud run jobs. Now let's jump into an example to show you directly how to use it from the console.

Example

In this example, we will create a cloud run job with 5 tasks. The python code writes the result of a BigQuery query on cloud storage. The BigQuery dataframe result will be split in 5 parts and each part will be written in a separated file in csv format.

1- Let's write the code

If you use the same code to test, do not forget to set your environment variables when creating the job. The python code below:

# librairies imports

import os
import pandas as pd
import numpy as np
from google.cloud import bigquery, storage
from dotenv import load_dotenv


def run_query(project_id, dataset, table):

    # create a bigquery client
    client = bigquery.Client()

    query = f"""SELECT *
    FROM `{project_id}.{dataset}.{table}`
    LIMIT 1000
    """
    #Notes : 
    #avoid SELECT * in real problems. we use it here just to illustrate
    #LIMIT 1000 does not have impact on the cost, the same amount of data are retrieved but filtered in the result.

    # run the sql query
    query_job = client.query(query)

    # we convert the iterator object into pandas dataframe
    rows = []
    for row in query_job.result():
        rows.append(dict(row.items()))

    df = pd.DataFrame(rows)

    return df, len(df)


if __name__ == '__main__':

    # we load all the environment variables
    load_dotenv()

    # we get all the environment variables
    project_id = os.environ.get("PROJECT_ID")
    bucket_name = os.environ.get("BUCKET_NAME")
    dataset = os.environ.get("DATASET")
    table = os.environ.get("TABLE")
    index = int(os.environ.get("CLOUD_RUN_TASK_INDEX")) 
    nb_task = int(os.environ.get("CLOUD_RUN_TASK_COUNT"))


    # the filename root
    filename = "test-parallel-task"

    # we run the query and get the result as a dataframe and the length of the dataframe
    data, n = run_query(project_id, dataset, table)

    # the length of each task dataframe
    len_task_df = n//nb_task
    begin = index*len_task_df
    end = begin + len_task_df if index != nb_task-1 else n   #we write like this to avoid data loss in case of imperfect division

    # we write the corresponding file on cloud storage
    data[begin:end].to_csv(f'gs://{bucket_name}/{filename}_{index}.csv')

As you can see in the last line of the code, I'm writing directly on cloud storage using pandas. This is only possible if you add the gcsfs library in your requirements.txt. Your requirements.txt should look like below.

gcsfs==2023.6.0
google-cloud-bigquery==3.11.1
google-cloud-storage==2.9.0
numpy==1.24.3
pandas==2.0.2
python-dotenv==1.0.0

Note : you can use any other language you want to perform this. But for this case, you can only use supported languages for GCP client API.

2- Image creation

To create the image to use, let's write the Dockerfile first:

# we use the version 3.10 of the python image 
FROM python:3.10

# we define a work directory
WORKDIR /app

# we copy the code dir into the work directory
COPY requirements.txt /app

# we install the dependencies
RUN pip install --no-cache-dir -r requirements.txt

# we copy the code dir into the work directory
COPY . /app

# we execute the code with the following command
CMD [ "python", "main.py" ]

Then, build your image. If you use GCP Artifact registry, follow the part 1 and 2 of my previous article to build your image.

3- Job creation
From the GCP console, search Cloud Run, select the jobs tab and click on create job

Then, fill the first part of the form. If you use GCP Artifact registry, use the SELECT button to browse and find your image. In the number of tasks field, enter 5.

Now, click on the arrow to reveal the config part. Switch between tabs to configure your job as you want and click on create.

Once created, your job should appear in the job list when you select the JOBS tab on cloud run homepage.

Click on the job and switch between tabs to see job info. The tab History is empty because there is no execution yet. To set a trigger, click on the trigger tab and schedule your job.

Click on EXECUTE to start the job and return to the history tab to see the changes. You should see an execution in progress. If you click on the execution, you will see the progress of each task execution. To check the parallelism, you can click on each task to see the start time. You can also check the logs of each task separately for debug purposes.

Once the job is completed, we can check the result on cloud storage to verify if the files have been created as expected.

We can see that the suffix of the file names are the indexes of the tasks. In the other hand, we can also see the creation date of the files. We see that 3 of them have been created at the same time because of parallelism. Now, open the file and verify if the contents are what is expected, depending on the index of the task.

This example is just a basic one to help you understand how it works. We can perform more complex tasks with it, as described in the use cases part.

Hope this article will help 🚀

Fix Cloud run resource locations constraint error (Error 412)

Thierry Njike — Sun, 26 Feb 2023 17:58:50 +0000

You have a project that you would like to deploy on Google Cloud using Cloud run, but due to some organisation's restrictions, you get an error like below:

ERROR: (gcloud.run.deploy) HTTPError 412: '$region' violates constraint 'constraints/gcpresourceLocations'

This error could come from the fact that you should use a low carbon region, and not all Google Cloud regions satisfy this condition.
Even if you pass the region as an argument, you have some steps of the deployment process that you don't manage because they are automated. So, you have to do it another way.
In this article, I will explain step by step how to solve that problem.

1 - Create the repository yourself

If we use the default gcloud run command, It will create a repository in the artifact registry, and use it to create the image to deploy.
That image is by default multiregion and it includes prohibited regions. So, you have to build the image yourself manually and specify it as an argument in the command. To do so, you have to create a repository in the Artifact Registry as shown below:

When creating the repository, make sure to select a low carbon region. Once the repository is created, open it and copy its path.

2 - Let's build the image

At this step, you should have created a repository. Now, let's build the image. Paste the command below in your cloud shell at the same level with your Dockerfile:

gcloud builds submit --region=$region --gcs-source-staging-dir=$path_to_the_cloud_storage_bucket --tag $path_to_the_repo/image_name:version

The image was successfully built! Copy the image URL, you will need it at the next step.

3 - Deploy your image

**
Now your image is created, let's deploy it on Cloud Run. Paste the command below in your cloud shell

gcloud run deploy $service_name --image $image_url:tag

Now you should have your app link in your cloud shell!

Hope this article will help 🚀