Software Engineering in the Age of AI: What’s Changing, What Still Matters, and How Engineers Are Adapting

"Honestly, it was when ChatGPT launched. Not because of the technology itself — but because of what happened in every meeting afterward. Leadership suddenly saw AI differently. The conversation shifted from “this is interesting” to “how fast can we move on this?” For me personally, a big chunk of my work at the time was data labeling — building the annotated datasets we needed to train and augment our models. It was slow, careful work. And it was also one of the first things we identified as a clear automation target. So we automated our labeling pipelines, and what used to take us weeks started happening much faster. It was exciting, but it also made something obvious: anything that could be systematized would be. That pushed me to think harder about what I couldn’t."

Andrea Coifman, Director of Software Engineering, GenAI Platform at Nasdaq

"The moment I could no longer ignore AI was when I realized I could build a working application in days instead of months.

As a data engineer, I spent years learning how to write production-quality code, debug complex pipelines, and navigate technical implementation details. Those skills still matter, but AI changed their relative value. Suddenly, the bottleneck was no longer writing code—it was understanding the problem deeply enough to ask the right questions and guide the solution.

I initially felt what many engineers feel: a mix of excitement and discomfort. But I quickly realized AI wasn't replacing expertise; it was amplifying it. The engineers who understand systems, users, trade-offs, and business outcomes now have even greater leverage."

Deepti Bahel, Senior Data Engineer at Gifthealth

"For me it wasn't a single dramatic event — it was the morning I watched an assistant scaffold a data pipeline and a set of Kubernetes manifests in minutes, work that used to cost me an afternoon of careful, hard-won effort. I'd spent fifteen years getting fast and clean at exactly that kind of plumbing, and suddenly the typing was the cheap part. My first reaction was honestly a little defensive. Then it clicked: the value was never in writing the pipeline, it was in knowing which pipeline to build, why, and what it would cost when it ran at scale. AI didn't take my job — it took my keyboard. The judgment stayed mine. Once I reframed it that way, the shift stopped feeling like a threat and started feeling like leverage."

Divya Singh, Consultant, Data Engineering at Dell Technologies

"We’re actually on the platform side — we build the infrastructure that lets everyone else in the company use AI agents. So I get to see adoption happening across the whole organization, which is pretty fascinating. You watch teams realize they’ve been doing something manually for years that an agent could just… handle. For me personally, I’ve been using AI a lot for the communication overhead — drafting emails, summarizing threads, the stuff that eats into your day before you’ve even started the real work. It doesn’t sound glamorous, but it genuinely frees up mental space for the decisions that actually need my judgment. I think that’s the real value for someone in a leadership role — not replacing your thinking, but protecting time for it."

Andrea Coifman, Director of Software Engineering, GenAI Platform at Nasdaq

"Working in a regulated industry changes the nature of this question quite a bit. Technical decisions at our level don’t stay neatly technical — they touch compliance, risk, audit requirements, sometimes regulatory implications we won’t fully see for months. So the scope was always going to be wide. What I’ve had to get better at is holding both the technical and the organizational question at the same time. “Can we build this?” is usually straightforward. “Should we, and what are we responsible for if something breaks?” — that one takes longer, and it involves a lot more people. I try to make sure my team feels comfortable asking the second question without being seen as slowing things down. That cultural piece is honestly harder than any technical challenge I’ve dealt with."

Andrea Coifman, Director of Software Engineering, GenAI Platform at Nasdaq

"I embrace it because it aligns with how technology should be built. My healthcare journey taught me that the most elegant technical solution is useless if it doesn't solve a real human problem. When building AI-powered tools for kidney patients, I spend as much time thinking about patient trust, accessibility, safety, and adoption as I do about technology.

I encourage teams to move beyond asking "Can we build it?" and start asking "Should we build it?" and "Who benefits if we do?"

The engineers who thrive in the AI era will be those who understand technology, business outcomes, and human impact simultaneously."

Deepti Bahel, Senior Data Engineer at Gifthealth

"In data engineering and infrastructure, reliability and cost were always near my day-to-day — but now those conversations start earlier and include people who don't write code. Navigating it means making trade-offs explicit instead of implicit: cost versus latency versus reliability, said out loud, with the business impact attached. Knowledge graphs have been a real help here, because lineage and impact become legible to people who'd never read a config file. For my team, I push ownership down. I want every engineer reasoning about blast radius and cost before they ship, not just whether the build is green. We run blameless reviews and I work hard to make the why of a decision as visible as the how. Wider responsibility only scales if more people can carry it."

Divya Singh, Consultant, Data Engineering at Dell Technologies

"My honest view is that the great engineers were always the ones who could think past the obvious answer. AI just makes that more visible now. These tools are genuinely impressive at synthesizing existing knowledge — they’ll give you a solid answer to a well-formed question faster than any human could. But they work within what’s already known. The edge cases, the genuinely novel problems, the moment where the technically correct solution is the wrong one for this team, this context, this constraint — that’s still human territory. That’s where real engineering judgment shows up. I use AI constantly, and I think every engineer should. But I see it as something that sharpens your thinking, not something that replaces it. The engineers who will stand out are the ones who can look at the AI’s answer and ask a better question."

Andrea Coifman, Director of Software Engineering, GenAI Platform at Nasdaq

"I believe AI has made the deeper parts of engineering more visible.

The best engineers were never defined solely by how quickly they could write code. They were defined by their ability to solve meaningful problems, make sound decisions under uncertainty, communicate clearly, and build systems people could trust.

AI has simply exposed that reality. As code generation becomes easier, qualities like judgment, curiosity, empathy, systems thinking, and domain expertise become even more important. Those were always valuable—they're just harder to ignore now."

Deepti Bahel, Senior Data Engineer at Gifthealth

"It made them visible. A great engineer was never the fastest typist — but for years, fluency with syntax was a convincing disguise for actual judgment. AI stripped that disguise away. When anyone can generate plausible code, the differentiator becomes the things that were always the real work: system thinking, knowing what not to build, reading failure before it happens, and explaining a decision to someone who'll live with its consequences. AI didn't redefine greatness. It just removed the proxy we kept mistaking for it."

Divya Singh, Consultant, Data Engineering at Dell Technologies

"Get genuinely good at using AI coding tools — not just familiar with them, actually fluent. There’s a real difference, and it shows. But here’s what I think matters even more: make sure you actually understand what the tool is producing. Using AI to write code you can’t explain is a risk, not an advantage. At some point someone will ask you to defend it, debug it, or extend it. The other thing I’d focus on is learning to define problems, not just solve them. That might sound abstract, but as AI handles more implementation work, the valuable skill is figuring out what to build and why — and that requires you to understand the business context, talk to stakeholders, and make judgment calls that don’t have a clean technical answer. The engineers who develop that early are going to have a real edge."

Andrea Coifman, Director of Software Engineering, GenAI Platform at Nasdaq

"Focus on becoming exceptional at learning. Tools will change. Models will change. Frameworks will change.

What lasts is the ability to understand a problem, break it into components, learn what you don't know, and deliver results.

Use AI aggressively, but don't outsource your thinking. Learn why solutions work. Learn how systems fail. Learn how business decisions are made.

The engineers who thrive won't be the ones who use AI the most. They'll be the ones who combine AI with strong fundamentals and sound judgment." 

Deepti Bahel, Senior Data Engineer at Gifthealth

"Learn the things AI can't fake on your behalf: how systems fail, how data actually moves, and how to reason about a problem before you reach for a tool. The market no longer rewards people who can only generate output — it rewards people who can verify and direct it. So become the person who can look at AI-written code or infra and say, with confidence, "this is wrong, and here's why." In data specifically: understand the data, not just the pipeline. The engineers who'll thrive are the ones developing taste — the judgment to tell good output from output that merely looks good."

Divya Singh, Consultant, Data Engineering at Dell Technologies

"Because these three things together are what actually make you useful in a world where anyone can generate code. AI fluency means you know how to use the tools. Critical thinking means you don’t just accept what they produce. And problem-solving is what happens when the AI gives you something technically correct that completely misses the point. What I see employers — and honestly, collaborators — respond to is evidence that someone can think, not just output. Projects where you made a real decision, hit a real constraint, had to change direction. That’s what separates someone who worked with AI from someone who let AI work for them."

Andrea Coifman, Director of Software Engineering, GenAI Platform at Nasdaq

"Build something that solves a real problem for a real person. Not a tutorial. Not a clone.

Find a challenge in your community, workplace, family, or industry and create a solution. Then put it in front of users and improve it based on feedback.

Many of the healthcare applications I've built started with challenges I experienced personally as a kidney patient and transplant recipient. That experience taught me that the strongest portfolio is not a collection of technologies—it's a collection of problems you've solved."

Deepti Bahel, Senior Data Engineer at Gifthealth

"Ship one real thing, end to end, and be able to defend every trade-off in it. Not a tutorial clone — a project where you took an ambiguous problem, made real decisions, instrumented it so you can see it working, and can explain what broke and what you'd do differently. Evidence of judgment beats evidence of syntax every time. When you can walk someone through why you chose this architecture over that one, and what it would cost at ten times the load, you've shown the one thing AI can't show on your résumé for you."

Divya Singh, Consultant, Data Engineering at Dell Technologies