Back in 2016, I decided to go back to school to get my undergrad in computer science at the University of Kentucky. I didn't know much about coding at the time. I'd worked with someone in the Navy who had written a Python script to auto-generate reports, and it hit me—this was a skill I'd need no matter where I went. Even if my primary role wasn’t developing software, the technology would certainly give me an edge.
While I was there, I heard the same joke on repeat: a degree in computer science is really just a degree in googling.
They weren't wrong. Development is research-intensive because every problem has a multitude of viable solutions. The real skill is finding the best one for your use case—or at least one that works if you're under pressure. You're constantly hunting through Stack Overflow, pulling up answers from a decade ago, watching YouTube tutorials, and piecing together something that fits your specific situation.
Then AI came along.
Now I give Claude my problem, and it spits out a coded solution. I don't have to dig through forums or watch tutorials. The googling part—that entire research phase that used to consume hours of a developer's day—it's just gone.
But there’s a line we can’t cross: we can't hand everything over to AI, no matter how useful it's becoming. It isn’t a person. As developers, we're still accountable for how the end user experiences what we build. And no AI model can fully account for that human context—at least not yet.
So I asked some fellow developers at Nymbl how their day-to-day work has actually changed. What's different compared to five years ago? Where are they spending their time now? And what do they expect the landscape to look like in 2031? Here's what I learned.
How Our Day-to-Day Work Has Changed
Five years ago, a massive portion of a lead developer's day was spent in a continuous loop of manual tasks—research, experimentation, iteration. Writing boilerplate code, looking up syntax, configuring routing, mapping data structures, and creating standard unit tests—all of it was largely manual effort. If you wanted to build a new internal tool or stand up a prototype, you built it piece by piece.
Today? Much of that effort has been compressed dramatically.
Barkha Sinha, who works with AI coding tools daily, put it simply: "The work hasn't disappeared, it has evolved." She's still doing the same job—now she's solving more problems in the same amount of time.
Mubeen Mohamed describes a similar shift: "I now spend more time understanding requirements, reviewing AI-generated solutions, improving business logic, and focusing on problem-solving." The shift is real—less time on execution mechanics and the grunt work, more time on thinking about what actually matters and drives outcomes.
Looking ahead to 2031, the trajectory is clear. Development is moving toward a model where engineers will work more as solution architects and reviewers— setting direction, evaluating output, and ensuring AI tools build the right things reliably. The human skills that matter most—critical thinking, system design, communication, validation—are only becoming more important.
The Genuinely Useful Moments
When has AI actually been a game-changer in your day-to-day work? When did it become clear that certain tasks simply could not get done as fast without it?
Barkha captured this perfectly: "What used to take hours can often be completed in a fraction of the time, allowing me to focus on the actual problem I'm trying to solve." But the impact goes beyond speed. The tunnel vision that used to set in with hours of troubleshooting is far less a risk when you can describe your problem to a model and get a structured response. And in the process of describing it clearly, you're forced to think about the actual high-level requirement. You have to understand what you're actually asking for before you can ask it well.
Mubeen echoes that: "Instead of spending hours searching documentation or testing multiple approaches, AI helps identify possible root causes, suggest fixes, and generate optimized solutions within minutes." That productivity shift has a real compounding effect. It means developers can focus on the parts of the job that actually require human judgment—the business logic, the design decisions, the tasks that can't be outsourced to a model.
Where We Still Don't Trust AI
Here's where I have to push back on the narrative that AI is going to solve everything.
AI isn't a person. It can’t understand requirements the way a stakeholder can, and it can’t anticipate how a real user will interact with what you built. Recently, I was trying to build a new feature for a ticketing app and had to ask the requester how the feature should behave. It wasn't something Replit could answer because Replit isn't a person who's going to be using this application.
Barkha flagged hallucinations as her biggest concern: "The biggest concern for me is still hallucinations. They're subtle and often don't look obviously wrong at first glance, which makes them particularly risky." In theory, context windows should help with that. But this is a situation where human oversight is necessary. An AI-generated solution may compile successfully, look well-structured, and even appear logically sound, while still containing incorrect assumptions or edge-case failures.
Mubeen emphasizes what I think is the core issue: "I still do not fully trust AI for security-sensitive implementations, complex business logic, and debugging subtle issues in large codebases." This is not a dismissal of AI’s value. She's saying that "human review and understanding are still essential to ensure reliability, maintainability, and security." She treats AI output as a first draft — one that requires careful review before it goes anywhere near production.
Barkha drives the point home: "You can't assume it's correct just because it runs." Executing without errors and doing what you actually need it to do are two very different things.
Verification: How We Know It Actually Works
Knowing that AI output requires review is one thing. Having a consistent method for doing it is another.
Mubeen’s approach is methodical: "I usually verify AI-generated code by reviewing the logic line by line, testing different scenarios, and comparing the output with the actual business requirement." What’s evolved over time is where she focuses her attention: "My approach has shifted from trusting quick outputs to focusing more on validation and edge cases." The complexity and business impact of a given implementation determine how rigorous that validation needs to be — not the fact that a model generated it.
Barkha thinks about it similarly. Rather than reviewing every line of AI-generated code with equal scrutiny, she calibrates: "I apply a risk-based approach. The higher the complexity, business impact, or potential for failure, the more rigorous the validation process becomes." For smaller, lower-stakes snippets, a quick review may be sufficient. For anything critical? That's where you slow down and actually dig in.
The common thread is this: AI accelerates your work, but is not an authoritative source. It's a starting point that requires human judgment.
The Skill Atrophy Question: Real Concern or Overblown?
It's a fair question: if AI is writing more and more of the code, are developers at risk of losing the skills that made them effective in the first place?
Barkha thinks "AI raises the bar because you're now expected to move faster while maintaining quality." The speed of development has changed dramatically. What might have taken a team six months to build can now be prototyped in a fraction of that time. New frameworks, architectures, and tools are emerging at an incredible pace. And because AI can accelerate execution, "expertise is even more valuable." You need to know your domain to evaluate what the model gives you, to debug issues, to make architectural decisions. She believes “continuous upskilling has become even more important in the age of AI”. The time AI frees up from heads-down execution is time that can — and should — go toward learning something new.
Mubeen frames it slightly differently. "Strong fundamentals, problem-solving ability, and technical understanding are still important for making correct decisions, handling complex scenarios, and maintaining high-quality applications." The risk of skill atrophy is real, but it's conditional. It applies to developers who treat AI as a shortcut and stop engaging with what's happening beneath the output. For those who stay curious and keep building their knowledge, AI functions as a force multiplier — accelerating what they're already capable of rather than replacing the capability itself.
Where AI Can Do Good
Beyond productivity gains and workflow changes, there's a bigger question worth asking: where does AI actually move the needle for people?
Mubeen thinks about democratization: "AI can help small teams and individuals create solutions that previously required large organizations." The barrier to entry for building technology is dropping. You don't need a massive team or massive resources. You need an idea and the ability to describe it clearly to an AI model. That shift in accessibility is powerful.
Barkha takes a broader view: "It's amplifying human curiosity and helping us solve problems faster than we've ever been able to before." She sees AI as a catalyst for accelerating research and discovery—helping researchers process vast amounts of information, explore hypotheses, create simulations, and evaluate outcomes far more quickly than would otherwise be possible.
On a personal level, that resonates. AI has made it possible to develop software solutions without deep full-stack experience — closing gaps that would have previously required years of specialized training. But even beyond work, it helps people access information that previously has been institutionally gatekept. That's not a side benefit. That's the equalizer.
The Bottom Line: Automation, Not Replacement
Barkha's framing is the one worth ending on: "The trajectory isn't towards replacing developers; it's towards amplifying what developers can accomplish."
We've automated the research layer of software development. We've taken that part of the job—the googling, the hours of searching through documentation and Stack Overflow—and handed it to AI.
But we haven't automated judgment, oversight, nor decision-making. Those are distinctly human elements. And if anything, they're becoming more important as the heads-down grunt work of old-school programming gets taken over by AI.
When I started my degree in 2016, the joke was that computer science was just a degree in googling. Now the googling is automated. What remains is the thinking, the understanding, the validation — the capabilities that require a person to actually be present and accountable for the outcome.
Those capabilities have always mattered. In an AI-accelerated world, they're worth more than ever.
Ali Wallace is a Solution Architect at Nymbl. This piece is part of the Women of Nymbl AI series.
#WomenOfNymblAI #WomenInAI #WomenInTech #Nymbl #AI #DiversityInTech
Copy editing assistance from Anthropic Claude
