Edition 8

6 (Based) Predictions for Programming in 2025

Today Iā€™m going to share with you my hot takes for programming in 2025.

Iā€™ve been caught out before being ignorant to changes in the landscape and it set me back for a while.

The problem is most people will be caught out too either through denial, being too busy to notice or a lack of exposure to big changes previously.

The tech world is the fastest evolving field in the world. Fail to spot the changes and youā€™ll find yourself regretting it later.

In this newsletter weā€™ll go over:

1. Pushback on AI generated code

Recently Google reported that AI systems are now responsible for generating over 25% of new code for Googleā€™s products.

People have then become the overseers and reviewers of the code generated by AI.

I can see the pushback coming in a number of ways from a number of directions.

The first is potentially a very big problem with this that could really hurt smaller businesses.

Security.

As more and more engineers begin to adopt AI tools in order to keep up and look more productive and efficient thereā€™s going to be problems with security.

Any companies not offering subscriptions to tools like GitHub Copilot, Claude and Chat GPT for coding might find themselves with developers using their own personal accounts.

This could be a huge exploitation factor for companies who might not be aware developers are introducing generated code, not knowing where it came from.

Not only that but itā€™s only a matter of time before a big data breach occurs and companies will be pushing back on these tools if they see potential security threats.

Secondly I think weā€™ll also see pushback from engineers who love to code.

AI tools are getting better and better for smaller boilerplate tasks and simple app requirements.

Even multi-file, project wide changes are getting good.

But AIā€™s dystopian future of human as the PR reviewer and robot as the creator wonā€™t sit well for many.

A large percentage of the developer community love the process of programming and coding.

A lot of people wonā€™t give it up simply to be more efficient, especially if they feel that the quality isnā€™t there.

Thirdly, and managers should push back on this one.

Domain knowledge.

I think moving to a paradigm where engineers take more of a backseat could be a problem in the long term.

Domain knowledge is very important when writing software. Engineers build their cognitive domain as they build the product.

They know how it works, where the bottlenecks are, the issues the product has, where optimisations can be made, what to do in disaster recovery and much more.

Taking more of a backseat in the coding experience is going to reduce the understanding and context of those same applications.

2. Neovim will continue to rise

This follows on nicely from prediction number one.

I think a lot more people will start migrating to simpler IDEs like Neovim where the experience of writing code is more streamlined.

Engineers who want to be more efficient, but without having autocomplete everything they write, will opt for AI-less editors where the efficiency comes from the speed and accuracy of typing and mastering their basic tools.

Some people will opt for honing their skills and perfecting their craftsmanship over handing the reigns to AI.

3. AI IDEs like Cursor and Bolt will fade away

Weā€™ve seen the potential for this already with GitHub revealing the updates to Copilot.

VSCode from Microsoft has a massive market share, the resources and integrations to keep VSCode on top.

Smaller competition had the element of surprise when they first came out but now theyā€™re in the open.

Microsoft can see what features theyā€™re developing and what people are migrating over for and feed those into VSCode.

I donā€™t think these editors will die out but I do see their significant advantage has no been lost.

4. Coding interviews will change dramatically

Iā€™ve done one interview already where the candidate asked if they could use Copilot for the pairing exercise.

It took me by surprise but at this point, should it?

Coding interviews are going to have to change.

Technical interviews are not great even at the best of times but now the usual front end/back end coding questions and scenarios will not be adequate.

There will be engineers that code through an AI led workflow. And there will more be as time goes on.

What will be a sufficient yard stick to measure engineers against?

Should we deny people the use of AI tools for interviews?

Or will AI remove the point of technical interviews altogether?

Managers, engineers and companies will have to revisit what the interviewing process looks like and how they measure the capabilities of engineers.

5. Startups and SASS will continue to boom

Weā€™ve seen huge layoffs over the years at the big tech companies of the US.

Thereā€™s been a huge influx of highly qualified talent entering the market due to these layoffs as engineers of all levels are affected.

A lot of these engineers have become disenfranchised with the big tech treatment. Seeing that even working at the biggest companies in the world does not offer job security.

Some have chosen to:

Theyā€™re free from the bureaucracy of big tech companies and are free to pursuit technology and innovation on their own front.

Others have joined smaller companies where they can take a position with more responsibility and opportunity.

These smaller businesses and startups will benefit from getting access to levels of talent they probably struggled to recruit for before.

And with AI tools being accessible to most these same developers and their existing staff can become much more effective, efficient and challenge the bigger companies in the technical arena.

6. Simplified stacks

Tech stack complexity has been a huge problem for years. Especially in the JavaScript world.

When developers are already struggling with the stack they have now, dependencies and trying to keep things up-to-date weā€™re going to see more and more reduction of the stack.

Teams will be more careful about what dependencies they bring in.

One of the best attributes any engineering team can have, is speed.

In a world rapidly changing a teams ability to deliver quickly and being able to adapt and pivot is vital. Simpler tech stacks make refactoring much easier when the team knows what itā€™s handling.

I also see more teams and engineers switching over to offerings like Deno and Bun. Which promise the more complete build and runtime elements of something like Rust.

Potentially Void Zero could make some impact. Iā€™m cautiously optimistic about this one.

What can you do to adapt?

Simply put I would say that experimentation is the name of the game.

If youā€™re an engineer I would encourage you to try new tools. See what the offer and how it compares to how you work now.

Build apps and projects with a reduced stack or no stack at all. See whatā€™s possible with less.

If youā€™re a manager I would encourage you to look at how you review people for interviews and roles. Donā€™t continue on blind to the fact that programming is changing.

Experiment.

Donā€™t leave it up to others to decide which way things will go.

Experiment, document, share and create and reap the rewards of open mindedness and a broad set of experiences.

Thanks for reading

These are just one mans predictions amongst a sea of many others. Iā€™ve been around a while but my experience is still narrow when compared to the scope of problems in software engineering.

Get out there and tinker. Play with things. Have fun and donā€™t feel the need to stick to the same thing throughout the years.

Thanks again šŸ™

Knowledge for the healthier, wealthier, long term developers

Sign up to my weekly newsletter for software engineers/developers that want to grow. I share my past successes and failures so you can get a head of the rest.