← Back to Blogs & Events BLOG

The Future of Software Engineering in the Age of AI

May 1, 2025 Chandradeo Arya 18 min read
AISoftware EngineeringCareerFuture of WorkHugging FaceAWS

A candid, unscripted conversation between Rajat Arya — Tech Lead at Hugging Face and former co-founder of XetHub — and Chandradeo Arya, Solutions Architect & Instructor. What follows is the kind of career advice most people only get behind closed doors.

Interview with Rajat Arya — Tech Lead at Hugging Face · Ex-Co-founder, XetHub Conducted by Chandradeo Arya — Solutions Architect & Instructor


“I don’t think the industry is going back. Software engineering is going to shrink as an industry significantly. I believe it will go back to the 1990s in terms of number of software engineers.”

— Rajat Arya


In This Conversation

  1. How AI is changing how teams write software today
  2. Will training, certifications, and instructional content become obsolete?
  3. Will the Solutions Architect role survive?
  4. How Hugging Face is adapting to the shift
  5. Won’t Product Managers replace Software Engineers?
  6. The #1 piece of advice for tech professionals right now
  7. Can I just hire a mediocre developer who knows how to prompt?
  8. The emotional grief of experienced engineers
  9. What does “staying hands-on” really mean?
  10. Is AI consulting a good business model?
  11. Business problems vs. academic problems for AI products
  12. Anthropic vs. OpenAI: Enterprise vs. Consumer
  13. Will software engineering become a “normal” job again?
  14. The Hugging Face operating model as a preview of the future

Q01 · How is AI changing the way your team writes software today?

Rajat Arya

Since November, my entire team has been adjusting to coding with AI tools — and it’s been very foreign to us, having spent 20 years doing it another way. But I don’t think the industry is going back. We will move forward in this way until the economics work, and then we will continue.

I think software engineering is going to shrink as an industry significantly. I believe it will go back to the 1990s in terms of number of software engineers. We’re at the beginning of that process.

The Software Engineering Arc — Past, Present, Future

Full-Stack Generalists Hyper- Specialization Peak Inflation & AI Disruption Full-Stack AI Builders 1990s 2008+ 2024–25 2028+ "The last 20 years has been the anomaly, not the norm."

Q02 · Will AI make training, certifications, and instructional content obsolete?

Rajat Arya

Teaching engagements will continue but shrink. Just like search engines made paying for content aggregators irrelevant — you could just ask the search engine — in the same way, you can just ask the LLM to generate a curriculum for you. It won’t be quite as good as paying for one, but paying for video-based instruction will go down dramatically. Certifications will take a little longer to go away, but they will also shrink.

However, I want to add something important: all of this will be attributed to AI, which I don’t think is entirely true. The financial model for software has been inflated for 15 years, and that needs to be corrected. Software engineers have been paid too much for way too long. They’ll keep pinning it on AI, but that’s not really the root cause — it’s just the excuse.

One good thing about these AI tools is that any idea you have, you really have no excuse not to pursue it, because the tools make it so one person can do a team’s worth of work.

Key Insight

The salary correction in tech isn't caused by AI — it's a 15-year financial inflation correcting itself. AI is the excuse, not the root cause.


Q03 · Will the Solutions Architect role survive?

Chandradeo Arya

I’ve been hearing developers are going to be less relevant, but architects will be more needed because they design solutions and understand business needs. But why are even architects needed? A product person can just say “I want this developed” without caring about the architecture behind it.

Rajat Arya

I don’t think architects are safe. I think the opposite. Most business solutions can be mapped to cloud-based architectures by LLMs today. The LLMs can chat with you through the design landscape pretty effectively for places like AWS because their services are all easily discoverable.

The formalization of an architect role will shrink, just like architects rarely existed in the 1990s. Since 2008, there has been a hyper-specialization — DevOps, architects, testers — and I think these hyper-specializations will all disappear. The expectation will be that everyone is a software engineer, like it was in the ’90s: you built the system, designed the system, and operated the system.

The Great Role Consolidation

2008–2024 Solutions Architect DevOps Engineer Backend Developer Frontend Developer QA / Tester AI-Powered Consolidation → 2028+ Full-Stack AI-Augmented Engineer "The expectation will be everyone is a software engineer. Like it was in the '90s."

Q04 · How is Hugging Face adapting to this shift?

Rajat Arya

Being at Hugging Face is nice because they’re very supportive of us learning and building with AI tools. I think we’re ahead of even the bigger tech companies by a year or so.

My team has eight people. Our system is at 140 petabytes of storage — so keeping it running takes real effort. In the past, with a team of eight, we’d maybe take on one ambitious project and one medium-difficulty project.

Now, with AI, my team is actively working on five projects, three of which I’d consider ambitious. It’s much easier for each engineer to design a better solution upfront because the AI tools handle the parts that used to take weeks — writing, drawing, diagramming.

Same Team of 8 — Before & After AI Tools

BEFORE AI TOOLS System Maint. (140 PB) \~60% capacity 1 Ambitious Project 1 Medium Project AFTER AI TOOLS System Maint. \~30% capacity Ambitious #1 Ambitious #2 Ambitious #3 Med #1 Med #2 Team of 8 engineers · 140 PB storage system · Same headcount

Q05 · Won’t Product Managers just replace Software Engineers?

Rajat Arya

Some product managers will build solutions, but it’s all a matter of the life of the solution. If no one knows how the code works, you won’t know how difficult it will be to add capabilities, what architectural limitations exist, or how to evaluate the complexity of a new feature.

Product managers will go from mockups to working prototypes. When the prototype is validated, it gets handed to the engineering team — which is much smaller — and they build the permanent solution with proper scale and architectural constraints.

The roles have historically always existed because they have different focuses. Product managers care about the business and the customer; engineers care about the solution.

What you’ll see is a mix — product managers will ship products that are fragile, and engineers who try to do the product side will produce immature, incomplete solutions as well.

How Different Roles Prompt an LLM — Same Goal, Different Output

PRODUCT MANAGER PROMPT "I want this capability and I want it to operate this way and deliver this user experience." Focus: Business & Customer SOFTWARE ENGINEER PROMPT "Latency-sensitive app. Must run in K8s, be scalable, integrate with these 4 AWS services we already use." Focus: Solution & Scale LLM generates code LLM generates code Works, but fragile Quick prototype — not production-ready Robust & scalable Production-grade architecture "Product managers care about the business and the customer; engineers care about the solution."

Q06 · What is your #1 piece of advice for tech professionals right now?

Rajat Arya

You need to keep hands-on and become very comfortable building with AI tools. You can’t shy away from those tools. You can’t assume that your expertise cannot be done by the tool. You need to know how to leverage them to make you more productive.

Here’s a simple example: One of the big bottlenecks for my team was always code review. We would avoid sweeping changes because of how much code review time it demanded. That’s where a lot of technical debt was incurred — you didn’t want to refactor 60 files, so you’d just copy the object and adapt it.

With LLMs, you just go make all those mechanical changes because the LLM generates the unit tests that make the refactoring safe. Suddenly you can get more done without incurring technical debt because the LLM has built all the tooling for you — tons of simulation environments, tons of tests.

“My main advice right now is: build. Become really good at building with AI tools. Take the time to do it. If that means nights and weekends, it’s worth it.”

— Rajat Arya


Q07 · Can I just hire a mediocre developer who knows how to prompt?

Rajat Arya

A really good software engineer would be able to do more than that mediocre software engineer with the same AI tools. Here’s the math that matters:

10x engineers, given 10x power with an LLM, create a 100x gap over standard engineers. The only software engineers that will be left are the ones that are really high quality. The mediocre ones — the ones that just glue APIs together — you don’t need them anymore.

Many of the folks that got into the field for the money will go find something else. In the 1990s, the only people that studied computer science were the people that loved the computer. After 2008, people got in because it was a lucrative, stable job. Those folks will find another field. I don’t think there will be jobs for them.

The AI Multiplier Effect on Engineering Talent

Standard Engineer 1× × AI Tools 10× = 10× 10× Engineer 10× × AI Tools 10× = 100× 90× gap Mediocre engineers can't compete

Q08 · Your team went through a real emotional transition with AI. What did that look like?

Rajat Arya

I have some fantastic engineers — 15 to 20 years of experience. All of us went through what I would define as grief. We felt a loss starting in November, that this thing we were really good at, no one cared about anymore.

It took us three to five months. Here’s where big tech companies mess this up: they push AI onto their people, measure the number of lines generated, question why it’s not higher. That’s not how people become comfortable with tools. They become comfortable when given space to tinker and try, and when given the best-in-class tools.

The people I know at Microsoft are struggling because they’re forced to use Copilot. We’re encouraged to use everything at Hugging Face — Claude for most of our work, Codex for code reviews of Claude-generated code and vice versa.

One unexpected benefit: my French colleagues who always struggled writing design documents in English — that barrier has vanished entirely. What would take me a week to write — a complex software system design with diagrams — can now be done in an afternoon.

How Big Tech Gets AI Adoption Wrong

Forcing developers to use specific tools and measuring lines of AI-generated code creates resistance, not adoption. Give people space to tinker, access to the best-in-class tools (not just your own products), and time to process the emotional shift.


Q09 · What does “staying hands-on” really mean if I’m not coding day-to-day?

Rajat Arya

Take the business requirements you’re translating, feed them into an LLM, have it generate an architecture, then review it. Ask the LLM to do what you do. See how close it gets, then ask for the software solution, and compare it to what your dev team produces.

Being hands-on doesn’t mean writing the code — it means thinking like a builder. Don’t just do the job you’re doing; do the job next to it. Your role will expand to the adjacent roles. Start doing that today before someone asks you to.

And my specific advice: Don’t tell people you’re an architect. That’s like telling someone you’re an expert at repairing fax machines. It’s a real expertise, but how relevant is it going forward?

Instead, say you’re a builder: “I help teams build incredible applications powered by AWS Cloud. I start by taking business requirements and translating them to architecture, then partner with the development team to build out the solution.” Let the boundaries be fuzzy.

Reframing Your Professional Identity

❌ DON'T SAY "I'm an Architect" (like saying "I repair fax machines") → ✓ SAY THIS "I'm a Builder" (end-to-end, from business to production)

Q10 · Is building an AI consulting company a good idea?

Rajat Arya

It’s not a bad idea. I just don’t know how you can demonstrate Claude expertise. The models are moving very quickly — every three months there’s a new model, and the landscape is rapidly evolving.

This is why consulting should be solution-based, not technology-based.

You’re not an expert in Kafka — you’re an expert in building real-time systems. You’re not an expert in AWS — you’re an expert in serverless architectures. Low cost, high throughput — solution-based, not technology-based.

AI tooling only makes it harder to build a practice around a specific technology stack because everything changes so fast. Anchor your expertise in what you solve, not what tools you use.

Solution-Based vs. Technology-Based Expertise

TECHNOLOGY-BASED (FRAGILE) Kafka Expert AWS Pro Claude Expert Changes every 3 months ↻ SOLUTION-BASED (DURABLE) Real-Time Systems Serverless Architecture High-Throughput Pipelines Problems persist, tools change ✓ "Anchor your expertise in what you solve, not what tools you use."

Q11 · I had an idea to build an AI tool for educational institutes. Worth pursuing?

Rajat Arya

It’s not a bad idea, but use a business problem instead of an academic one. Schools rarely have money to pay for these products. Any AI product requires variable costs — you need GPUs or API calls per token, and the infrastructure cost is pretty high.

You want a business problem that connects to revenue. But many business problems use the same technology. Instead of a school AI tool, try a large coaching center that needs the same tool. It’s the same application you’re building, but with a customer that can actually pay for it.

AI Product Advice

Build the same technology, but point it at a customer who can pay. Same AI solution — apply it to large coaching centers or similar use cases in other industries instead of schools.


Q12 · How do you see the Anthropic vs. OpenAI battle playing out?

Rajat Arya

OpenAI went for the consumer and Anthropic went for the business. It’s not that one is going to fail — they’re just very different businesses. In the same way, Google went for the consumer and AWS went for the business.

Anthropic’s challenge: Big companies want to build in-house. Enterprise customers get new tools every few years, and internal teams will want to justify their own existence.

OpenAI’s advantage: Consumers never set up their own clusters. Once you’ve found Google, you don’t go looking for other search engines. If you can convince consumers to change behavior, they’re unlikely to change it again.

Still, I’m not convinced either company has figured out their unit economics. The only one really making money right now is Nvidia. Everyone else is moving money around. But in the next five years, the massive investment in bespoke hardware will bring costs down dramatically.


Q13 · Will software engineering become a “normal” job again? What happens to the Indian IT industry?

Rajat Arya

The amount you pay for engineers will go down. It’s a correction back to the 1990s. In the 1990s, software engineers didn’t make the same as doctors. Going forward, software engineering will be like civil engineering or chemical engineering — well-paid professionals, but not making the same as investment bankers and medical doctors.

Software engineering will stop being a sexy, financially lucrative job. It’ll go back to being a normal engineering job, and only the people that truly love it will stick with it. The last 20 years has been the anomaly, not the norm.

The Indian IT industry is built on two things: high cost of software labor globally, and the fact that educated people in India are taught English. That’s the whole reason China didn’t win and the Indian IT ecosystem could grow.

What I want to say that’s optimistic: the number of people employed will go way down in the next five years. But the people that remain will get to do way more interesting work.

“In India, there is almost no consideration of whether you actually care about that job. It is all about what it can give you. That’s why it’s going to have a big effect in places like India.”

— Rajat Arya


Q14 · You mentioned Hugging Face operates differently. How does its culture connect to the future of work?

Rajat Arya

When I first joined, I was confused. Hugging Face celebrates this async, remote culture with no meetings. I thought, “These guys just don’t know how to do complex things.” After almost two years, I still think Hugging Face isn’t as ambitious as it should be. But its general operating mode — smaller teams, smaller projects, take more swings at bat — is closer to how every company will operate in the future.

It is faster to try and fail with AI tools than to spend time analyzing everything and trying to achieve perfection.

In the past, getting something started would take so long, you’d be very careful to think about what to start. Now, you can just start.

The Future Operating Model

TRADITIONAL MODEL Big team → Analyze → Perfect → Ship 1 Slow to start, careful, high stakes → AI-ERA MODEL Try #1 Try #2 Try #3 Try #4 Winner! Try #5 Small teams, more swings, faster cycles "It is faster to try and fail with AI tools than to spend time analyzing everything."

Rajat's Parting Words

"Don't be afraid of the new things. Instead, get comfortable building using them. The more you feel that you can become a 10× everything as an AI builder, the more essential you will be through this transition."

— Rajat Arya, Tech Lead at Hugging Face


This conversation was recorded in May 2025. Rajat Arya is Tech Lead at Hugging Face and former co-founder of XetHub. Chandradeo Arya is a Solutions Architect and Instructor.