DEV Community: thomaslanghorst

Should I Use AI or Give the Task to a Junior Developer?

thomaslanghorst — Sat, 08 Aug 2026 05:49:12 +0000

Introduction

Last week, I had a moment where GitHub Copilot felt like a more rational choice than delegating work to a junior developer. I am slightly embarrassed to admit it, yet I still feel like it was the right call. But why exactly is that?

My task was to refactor a fairly complex API endpoint. The difficult part wasn't the implementation itself, but rather understanding the interactions between all involved systems and breaking down the work into manageable steps. After a few hours of anlysis, I had created a farily straightforward step-by-step implementation plan.

Seconds later, I caught myself asking: "Do I give the implementation work to the junior developer, or do I give it to Copilot?" I chose Copilot. And while it felt like the more efficient choice, it kept bothering me afterwards.

A few years ago, many of these implementation tasks would have gone straight to junior developers:

Adding CRUD endpoints
Generating unit tests
Refactoring straightforward code
Debugging simple errors
Documenting APIs or services

Today, many senior engineers delegate these tasks to GitHub Copilot. And honestly, in many cases that actually IS the more efficient choice. But it raises a deeper question: If AI is increasingly becoming better at execution-heavy development tasks, what exactly are junior developers supposed to learn from?

Where AI Coding Tools Already Outperform Traditional Delegation

Before we dig into this particular question, let's first look at what AI currently excels at.

When it comes to software development, modern AI coding tools like GitHub Copilot are extremely good at certain types of work. In particular, they excel at:

Pattern recognition
Syntax generation
Boilerplate production
Code transformation

This is especially true if requirements are clear, ambiguity is low and correctness is easy to verify.

What all of those tasks have in common is that they primarily focus on execution and require relatively little organizational context or domain knowledge. When dealing with implementation responsibilities, AI tools like GitHub Copilot have several structural advantages over junior developers:

They are faster
Have zero onboarding cost
Work instantly
Scale cheaply
Handle repetitive work effectively
Reduce human errors to zero

For senior engineers, this immediately translates into less delegation overhead, fewer interruptions, shorter review cycles, and ultimately faster delivery. In other words: AI significantly increases developer productivity for certain categories of implementation tasks.

And that raises an uncomfortable question: If AI is already better at execution-heavy development tasks, why not give every task to AI? That's why many, especially junior developers, are afraid to get replaced by AI coding tools.

Why Task Purpose Matters More Than the AI vs. Junior Developer Decision

The problem with the "AI vs. junior developer" question is that it assumes all software development tasks are the same. In reality though, they are not.

Over the years, while working as a software engineer, mentoring junior developers, and leading whole projects, I’ve learned that most engineering tasks fall into three broad categories:

1. Tasks that require ownership

The first category of tasks is tasks that require someone to take long-term responsibility for the system and its architecture.

Examples are:

Designing system architecture
Making security-critical decisions
Handling production incidents
Evaluating technical tradeoffs
Maintaining long-term system consistency
Coordinating cross-team integrations

These tasks usually require a deep understanding of the system, architectural judgement, and a solid foundation of the business context.

People working on them often need to evaluate tradeoffs, make long-term technical decisions with impactful consequences and coordinate requirements and decisions across multiple systems and teams.

In other words, these tasks come with real ownership and responsibility. That is exactly why they cannot simply be delegated to an AI, or handled independently by junior developers.

2. Tasks that enable fast software delivery

We've already touched on these tasks earlier, but let's make the category more explicit.

First, let's go over the examples again:

Generating repetitive CRUD endpoints
Writing straightforward unit tests
Transforming data between APIs
Scaffolding new services/modules

In my experience, tasks that enable fast delivery of software usually involve clear requirements, repetitive implementation patterns, low ambiguity and are easy to verify.

People working on them typically need to follow well established patterns to translate well-understood requirements into working code effectively and quickly.

These are exactly the kind of tasks where AI coding assistants like GitHub Copilot already outperform developers writing code on their own in terms of speed and efficiency.

3. Tasks that help people grow

This brings us to the third category: tasks that are intentionally delegated as learning opportunities.

Examples are:

Implementing a small feature end-to-end
Debugging a non-critical bug
Refactoring legacy code to learn architecture
Writing tests for unfamiliar business logic
Participating in code reviews

These tasks usually involve low levels of complexity, rudimentary domain knowledge, touch only non-critical code, and leave room for exploration.

People working on these tasks typically need mentorship, fast feedback loops, and enough time to not only understand the problem, but also why the solution is built that.

In the age of AI, tasks that are not primarily focused on speed or efficiency become even more important. Future senior developers still need opportunities to grow through real-world experience and take on more responsibility.

Where Junior Developers Still Matter

Up until this point, we've looked at the problem from a productivity perspective, focusing on the task-level. But the problem becomes even more visible once we start thinking on an organizational-level, where software engineering teams must make strategic choices about AI adoption.

Growing Future Senior Engineers

In any engineering organization, junior developers should not be seen only as current contributors, but as future senior engineers. Therefore, it's the responsibility of software engineering teams to enable growth and help them learn.

To accomplish that, organizations need to create learning opportunities. From my personal experience working with many junior developers, I've found that they learn best and gradually become mid-level and senior developers by working on real-world problems and taking on increasing responsibility and accountability.

Teams therefore need to support them by allowing juniors to make mistakes and by providing constructive feedback in short feedback loops.

Without those opportunities, teams sacrifice long-term engineering capacity for short-term productivity.

System and Domain Knowledge Compounds

Another argument why organizations need to create learning opportunities for junior developers is that, over time, developers accumulate something that is difficult to document and impossible to generate instantly: system knowledge.

Developers learn why systems were designed a certain way, what tradeoffs were made, how systems behave under production-like conditions, which parts of the system are fragile, and where complexity exists in the codebase.

Besides a deeper technical understanding, developers also accumulate knowledge about the business domain itself.

They learn why certain features matter more than others, which edge cases are business-critical, how real-world users interact with the system, and where technical decisions directly affect business outcomes and vice versa.

This technical and domain expertise is built through years of working on real-world problems, participating in domain discussions, and solving real production incidents. Without gradually exposing junior developers to those experiences, organizations slowly but surely lose the capability to deeply understand their own systems.

Software Needs Long-Term Maintainers

But understanding a system is only one part of the equation. Somebody also needs to maintain it long-term. In practice, systems need to be maintained, debugged, extended, migrated, and sometimes even completely rewritten later.

That’s why I think organizations need more people who can just generate code fast, they also need people who continuously maintain the system.

Investing in Future Engineering Capability

The goal for every organization should therefore not be to replace junior developers with AI tools like GitHub Copilot, but rather to strategically use them alongside human developers. Sustainable software development still depends on continuously developing juniors into engineers who understand, maintain, and eventually take ownership of complex systems.

A Better Delegation Question

In software development teams, the rise of AI coding assistants like Copilot has made delegation decisions more complex. Tasks are often evaluated mostly based on delivery speed, but sometimes the biggest long-term benefit is not the finished feature—it's the knowledge the person gained while implementing it. A junior developer working on a feature may gain architectural understanding, domain knowledge, and practical experience that become valuable far beyond the task itself.

Every delegation decision also shapes the capabilities of the engineering team, and even the organization itself. Teams that only optimize for short-term efficiency may ship software faster today, but they sacrifice the ability to develop future maintainers, domain experts, and system owners.

I believe this ultimately changes the question that modern software engineering teams should be asking. Instead of rushing into deciding whether a task should go to AI or junior developers, engineering organizations should first ask what the task is actually meant to achieve.

Is the task about speed -> give it to AI
Is the task about teaching -> give it to a junior developer
Is the task about ownership -> give it to a senior and include a junior developer

Conclusion

So, should you give the task to AI or to a junior developer?

In my opinion, the answer depends less on the complexity of the task itself and more on what the task is actually meant to achieve.

The future of software engineering will not belong to teams that replace developers with AI, but to teams that understand how to combine speed, learning, and ownership effectively.

AI may change how software gets written, but organizations will still succeed or fail based on how well they develop people. The real competitive advantage in the age of AI will not be to generate code faster, but to build teams that continuously grow people who can understand, maintain and eventually own complex systems. And that is exactly why junior developers still matter.

For more articles like that visit my blog.

Should you learn Go in 2023?

thomaslanghorst — Mon, 26 Dec 2022 04:45:42 +0000

In this article, I will be answering the question: to Go, or not to Go, with Go, in 2023? (sorry for the pun). If you rather want to watch the YouTube video, you can find it here. Now without further ado, let’s find out!

A little History

For those of you who don’t know what Go or Golang is. Here a little history. Back in 2007, Go was first designed by three google employees. As Rob Pike, one of the three authors of Go, wrote in an article:

“The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable.”

Working with a huge backend codebase, mostly written in C++, Java and Python, the three engineers wanted to build a new language to help tackle the issues they had while working with the code at google, while also maintaining its effectiveness. Rob Pike said: “In short, development at Google is big, can be slow, and is often clumsy. But it is effective.”

So they wanted to take the speed of C++, the strict syntax of C and paired it with pythons simplicity and useful features of Java. And what came out was this new language called Go. The combination of these makes Go one of the most powerful and effective languages for large-scale codebases, while also being simple and easy to maintain. Later in 2009, Go was open-sourced and had its first major version 1.0 in march 2012.

Pros of Go

But what exactly is Go, and what are its main benefits? Go is an open-source, compiled, strongly and statically typed programming language. It was built to be readable, simple and efficient, while also being high-performing.

I will not go into all the pros and cons of Go in this article (you still have things to do today, right?). Instead, I will keep it short and focus on the three main benefits and drawbacks. If you want to see a full list, you can go ahead and watch my video on YouTube.

Concurrency
Go has an incredible concurrency support, which makes writing concurrent code as easy as it gets. The way how easy Go handles concurrency is probably one of the main reasons why people pick this language over others.

Toolchain
Go has a fantastic toolchain. Running, building, formatting, profiling, installing, testing, … all these, any many more commands are part of the integral Go toolchain. So there is no need for external tools.

Simplicity
One of the main reasons why people use Go is: Go is an extremely simple programming language. Without much syntactic sugar, Go forces explicit code. Which makes this language easy to read, easy to maintain and easy to learn.

Cons of Go

But it’s not all rainbows and unicorns in Go land. Go also has its drawbacks. For example:

Verbosity
Despite its simplicity, Go sometimes can be too verbose and too explicit. Functions ranging over several 100 lines of code are no exception. And don’t get me started on the gazillion if err != nil checks. Writing all this code can be time consuming and a drawback for teams rushing against strict deadlines.

No strict coding guidelines
Although there are some best practices and generally accepted rules, Go does not strictly tell you how it wants things to be coded. This lack of clear and strict structure leaves room for undisciplined coding and inconsistencies. Which can become an issue in larger projects.

Still feels young
Even though Go is more than 10 years old, it still is a seemingly young programming language. Sometimes, even big companies or projects are missing Go SDKs or clients for their products. So if you want to use them, you need to either rely on open-source projects or write them yourself.

These are the pros and cons of the Go programming language. But what is Go primarily used for?

Primary use-cases of Go

According to the latest Go developer survey conducted in 2021, Go is used in a variety of areas. Such as Technology, FinancialServices as well as Media/Gaming, to name the top three. Of those people who write Go code, almost 50% write backend API or RPC services. Leaving the rest far behind with data processing, web services and CLI tools with roughly 10% each. So if you work in one of these areas, knowing Go can be a huge benefit.

Job opportunities for Go developers

Now let’s have a look a the jobs for Go developers. The Go homepage gives us a list of many big tech companies, who are using Go. Among them google (obviously), but also PayPal, Meta, Netflix, Uber, and many many more. Go must be doing something right, if big tech companies are relying so heavily on it.

According to Hired, Go is the most in demand skill that companies are searching for in software engineers. The second year in a row by the way. So, the need for Go developers is definitely there. But how about the salaries?

Salaries for Go developers

If you have a look at the annual stack overflow survey from 2022, you can see that Go is among the top 10 of top paying programming languages. With a median of almost $90k USD, being a Go developer gets paid better compared to more popular languages like python ($71k), C++ ($68k) or Javascript ($66k).

If you have a look at the same tables from the surveys of years 2021, and 2020, you can see that salaries for Go developers have increased over the last few years. From $74k USD in 2020, to $76k in 2021, and now being at almost $90k USD in 2022, the average salary has increased tremendously. Which is also very positive for the Go language.

Conclusion

So, to answer the question: should you learn Go in 2023? If you are looking for a new programming language to pick up, or a new language to increase your chances on the job market, in my opinion, Go is a fantastic choice!