is ai replacing software developers?

what the job actually consists of

Typing code was never the bottleneck. A rough split of a working engineer's week:

Automating the 20% is a genuine productivity change and it is not a replacement. It also moves work into the review row, which was already the row nobody had enough time for.

what has actually changed

Output per engineer is up, particularly on greenfield code, tests, and refactors with coverage. Measured gains vary wildly by task and familiarity, from large speed-ups on isolated work to measured slowdowns on complex changes in codebases the engineer knows well. Anyone quoting a single flat figure is averaging incompatible experiments.

Junior hiring is down. This is the real effect and it is not subtle. The tasks juniors were given, small tickets, tests, straightforward features, are the tasks agents do best. Firms hiring no juniors this year have a senior shortage in seven, and almost nobody is planning for that.

Review has become the bottleneck. The constraint on how much agent output a team can absorb is not the agents. It is how fast a competent person can check the work, and that capacity has not grown.

the part that argues against replacement

Software demand has never been satisfied. Every previous productivity jump in this industry, compilers, garbage collection, high-level languages, frameworks, cloud, produced more software and more engineers rather than fewer. The backlog at almost every company is longer than the roadmap.

If that holds, cheaper software means more of it gets built. If it does not hold this time, the argument changes. I would not bet confidently either way, and anyone who does is guessing with more conviction than evidence.

what to do about it

Move toward the things that got scarcer: understanding a system deeply enough to specify work correctly, reviewing generated output fast and accurately, and taking responsibility for what ships. Those are the growing parts of the job.

For hiring managers, the honest move is to keep taking juniors and change what they do, because the alternative is a gap you cannot close later.

how this works in aldena

Aldena is built around the review bottleneck rather than around raw output. Work runs as a team: a project manager splits it, engineer agents implement, and a separate reviewer reads the diff first, arranged in an org chart.

That means what reaches a human has already been read by something that was not its author. Nothing merges or deploys until you sign off, because approval is on by default, and each agent keeps memory of your conventions between runs so the same review comment is not needed twice.