How AI Is Changing the Role of Software Engineers (and What Skills Matter Most Now)

As AI tools like ChatGPT and GitHub Copilot become embedded in the software development workflow, what does that mean for aspiring engineers? Yuriy Ivanov has a front-row seat to this shift. A full stack developer who has worked at companies like Chegg and WeWork, Yuriy now mentors students in Springboard’s Software Engineering Career Track, helping them build job-ready skills while adapting to an AI-powered industry.

So how is AI changing the role of software engineers? Yuriy shares how AI has changed his day-to-day work as an engineer, why he encourages students to “trust but verify” when using generative AI, and the core problem-solving skills that matter more than ever in today’s tech job market.

Tell us about your background. How did you become a software engineer?

I double-majored in computer science and international economics at San Francisco State University, graduating in 2009. This was after the first dot-com boom, but before the mass adoption of high-speed internet and the iPhone.

Initially, I worked in marketing at Eataly. However, with the rise of the iPhone 3GS and high-speed internet, software and mobile applications became much more interesting. Since I was six or seven years removed from my degree and unprepared for the new technologies, I decided to pivot. I attended a bootcamp focused on Ruby on Rails and mobile development to get back into software development. I joke that I was tired of long office hours and evenings, so I jumped into a job where I now work long hours and weekends – but I love it.

How do you support and work with Springboard students?

I'm working toward a PhD in computer science, and I saw this as a way to test my interest in teaching, a necessary component of a PhD. I liked it; it's a nice change of pace from the daily grind with my team – a chance to have a one-on-one with a student and pass on what I've learned, both the successes and the things to avoid.

You've been a part of these major shifts in technology since the late 2000s. How has AI changed what you do on a daily basis?

Honestly, I would call myself a late adopter. I was used to reading the documentation. I was very skeptical. I still tell my team that my GitHub Copilot in VS Code is my best friend and my worst enemy. I push back on it a lot, but it is becoming a great tool.

It's a very good autocorrect, which can quickly deliver information to keep us moving. Product managers right now want to ship quickly. It's a rat race. What I've noticed is that it's not always about having a new revolutionary product. If you ship sooner than your competition and your version is liked better by your users, then you're already ahead. To do that, your engineers need to be highly efficient.

I could sit and sift through documentation and write a lot of boilerplate code over and over for tests, or I could embrace the change and let it handle a lot of the boilerplate that takes me a long time. Yes, I will push back. You have to be very careful because the prompt might give you an outdated version of Jest, PyTest, or whatever you're using. So you have to be very careful and know what you're doing. But at the same time, it really does speed up your workflow. And when upper management cares about efficiency, that's really, really important.

With your initial skepticism, how do you think AI will move forward?

Actual, real AI might eventually replace many roles. However, we currently have LLMs. The evolution of the cockpit crew is a useful analogy. Early 747s had three people: two pilots and a flight engineer. Modern aircraft are highly automated, capable of near-autonomous take-offs and landings, and the flight engineer role has been eliminated, or rather, evolved.

Automation in the cockpit didn't replace the pilots; it reduced the crew to two, moving pilots toward more automated systems. The pilot still needs to understand everything happening around them, just with new instruments.

Pivoting back to software, modern applications are much more involved than early HTML, and what was once technical knowledge becomes basic knowledge over time. These LLM tools help us, for example, when debugging a service like Redis. But just like the pilot, you need to deeply understand the output you're getting back. This is where the human engineer remains essential – understanding the 'why' behind the code and the AI's suggestions. The relationship is moving toward heavy AI usage, but comprehension remains paramount.

What skills do you believe matter most for software engineers today that may not have been as critical five or 10 years ago?

I'd ideally push for 30-40 hours of C fundamentals, but students, often learning in their spare time, don't have months to spend on C language semantics. You need to focus on job-ready concepts that are constantly changing. I started with Ruby on Rails, but haven't touched it in six years, as the ecosystem moved to other frameworks.

The essential skills I advocate for are problem-solving and thinking outside the box. The underlying concepts in Python, Ruby, JavaScript, and C# are similar. The key is to apply what you learn and understand the code you're writing. This foundation will help new engineers work with AI tools and understand the output, moving beyond just "monkey see, monkey do."

Instead of simply completing assignments, I encourage students to pause and ask: What is actually happening conceptually? Can I apply this to a different project? Can I improve it? It's about constant evolution. You look at your five-year-old code and cringe – that's normal growth. I push this forward in the curriculum: let's deconstruct, break it down, fix it, and improve it.

The Springboard software engineering program has a dedicated unit on collaborating with generative AI. How does Springboard teach students to work with AI rather than competing against it or depending on it too heavily?

It's something that evolves with each iteration, and I'm helping to advise on it. My general approach is 'trust but verify.'

Students ask, "Why do I need to do this myself? I can just punch this into ChatGPT, and it will spit out answers. I can glue this together and be done." That works as long as you don't breathe on it or shake it, and hopefully, all the versions match up. 

My approach is, OK, let's do this, but let's see what happens. I insert examples into lessons, showing where basic, boilerplate code from ChatGPT is very good. For example, "let's use Node.js and Prisma to generate this model."

It's good. Now take a closer look. What's wrong with it? Oh, wait, the version of Prisma you're using is legacy. The tools are there; they will help you be more efficient, but you have to check the tools, push back – trust, but verify.

Is the information correct and up to date? A lot of successful companies don't have a revolutionary product; they have a product that's easier to use, more approachable, and already has a user base.

If you just go and accept anything and glue it together, it's gonna be a mess. It's gonna be completely unmaintainable. Your coworkers will hate you. Nobody else will be able to work with you. That's just not going to work.

Why is the MERN stack still a strong foundation for engineers entering this new tech market?

It's always evolving. While the current focus is on the MERN stack, no single stack is inherently better. You can build a solid stack with Python, Java, C#, or even Ruby on Rails (which is still widely used). Ideally, I'd start everyone with 50 hours of C, but students are part-time, balancing work, study, and life. You have to focus.

I start with JavaScript across the board, despite the Python purists. I love and use Python daily, but JavaScript is the focus because we are limited by time. The challenge is balancing exposure to as many concepts as possible within a certain timeframe.

This is where the MERN stack shines: you start and finish with JavaScript, reinforcing concepts like asynchronicity on both the client and server sides. This focused approach is better than scattering attention across too many technologies. 

I advocate the MERN stack because, once you grasp these core concepts, you can apply them to other stacks. My CS degree was C-focused with some Python and Fortran. My 2010/2011 bootcamp was Ruby on Rails, but I later jumped to Node.js and React. The programming language changes, but the principles and concepts remain the same. You're just using a different toolbox with similar power tools to reach the end result.

You've also mentioned the evolving nature of Springboard's program. How did these hands-on projects help students prove real-world readiness to employers in today's hiring environment?

It depends on where you apply. For a long time, especially in corporate or big tech, interviews often involved LeetCode-style algorithmic problems to thin out candidates. What I've noticed lately, especially for junior devs, is a trend toward conceptual understanding (e.g., explaining database indexes) combined with practical, take-home problem-solving. For example, a healthcare company might ask you to implement a new feature (such as an urgent appointment type) in a sample application, followed by a discussion. This hands-on approach reflects how we shape our projects at Springboard: real-world problem-solving. We start small, build complexity, and encourage broader capstone projects.

Instead of strictly defined requirements, we allow students flexibility. If a student wants a RESTful API project for data work, great. If another wants to explore React Native for a mobile app outside the core curriculum, that's also encouraged because it shows the application of concepts and more. They take what they learned and apply it elsewhere, perhaps even to a popular application plugin. What I've seen, especially with startups, is a high interest in candidates who can come in and solve current business problems, not just theoretical algorithms. It's about being able to dive in, communicate what you learn, and work with a team, even if you don't know everything. That's the focus – encouraging them to think and evolve beyond strict curriculum points.

How does Springboard's human-centric support system – the mentors, career coaches, instructors, and community – help students stay accountable and navigate the changing tech landscape?

Well, I can only speak from my experience as a mentor.

Then there is the student-mentor relationship. I'm a very hands-on mentor. For some students, it's not just "Good job, on to the next assignment." We sit down and deconstruct the work so they can understand it. However, some students prefer a different approach.

I’ve had students switch to me because they wanted a mentor who would challenge them, not just offer praise. I've also had students move away, saying, "No offense, but I just want to go through this program; I don't have the energy to deconstruct everything for an hour." In that case, they are matched with someone who provides more straightforward guidance on the next steps.

It's a back-and-forth. They try to listen and match students to the best fit. If they want a challenge, they'll get a mentor who will provide it.

For someone considering software engineering but worried about the disruption from LLMs and new technologies potentially threatening careers, what advice do you give about building a future-proof career?

Two things are key. First, you have to want it. You can't just coast through and expect success. You have to genuinely learn and understand the concepts, not just 'monkey see, monkey do.' You need to spend time learning, have your mentor and program challenge you, and ensure you grasp the fundamentals.

Second, once you finish the program, you are not done learning. This field is not static like law; you have to keep learning. Languages and frameworks will rise and fall in popularity. While the core concepts remain, new technologies constantly emerge. I still use concepts from my early programs, applying them across different frameworks and languages. You must be ready for continuous learning.

This constant evolution keeps the field from being boring. However, you must embrace a continuous-learning mindset, knowing that it won't always make sense at first. Learning often follows a "step ladder" pattern – you hit a wall, feel stuck, then suddenly overcome the hump, only to encounter a new wall.

If you are learning and advancing, all the surrounding technologies, including LLMs, are simply tools. This industry has always become more automated, evolving from writing code on paper to using sophisticated modern editors. The current generation of AI is just the next step. You must know how to use these tools and be ready to learn new ones.

Thank you so much for the insights, experience, and tips you have shared during this conversation.

Find out more and read Springboard reviews on Course Report. This interview was produced by the Course Report team in partnership with Springboard.