Reflections from a software engineer navigating AI.
I started developing software in 2012. Nearly fourteen years later, I still encounter problems I don't immediately know how to solve.
If anything, experience has made me more aware of how much I don't know.
My career began working with Ruby on Rails as a frontend developer at Cloud.com, part of Citrix Systems. I was one of three web developers in a startup-style environment, surrounded by a growing engineering team that went from roughly fifteen to forty-five developers working across different platforms.
Being surrounded by engineers with different backgrounds and specialties was an incredible opportunity to learn.
Even back then, I didn't believe becoming a better developer meant learning as many programming languages or frameworks as possible. The idea of constantly having to learn something new just to keep up felt overwhelming, and I wasn't convinced it was the best way to grow.
Instead, I wanted to really understand one language, become proficient with it, and learn how to use it to solve increasingly complex problems.
To me, programming languages were simply different ways of achieving an outcome. Learning another language wasn't necessarily going to make me a better engineer if I hadn't developed a deeper understanding of what I was trying to accomplish.
I didn't have everything figured out then, and I certainly don't now. But looking back, I think that early instinct shaped how I approach software development today.
The tools have changed dramatically. Artificial intelligence is perhaps the biggest shift I've experienced since entering the industry.
And in many ways, it's reinforcing something I've believed for a long time: the real challenge in software engineering isn't simply knowing how to write code.
It's understanding what you're trying to build, why you're building it, and how to make thoughtful decisions along the way.
I use AI regularly in my own work. It helps me explore ideas, accelerate development, investigate problems, and experiment with solutions. I'm genuinely excited about what it makes possible.
But the more capable these tools become, the more I find myself thinking about the value of experience, human collaboration, and perhaps most importantly, knowing when to question an answer.
Knowledge isn't the same as experience
One of the most remarkable things about AI is how much knowledge it makes accessible.
You can ask an LLM how to implement authentication, structure a database, integrate a payment provider, or design an entire application, and receive a detailed response in seconds.
A few years ago, many of those questions would have involved hours of research, reading documentation, experimenting, and probably a fair amount of frustration.
That's an extraordinary improvement.
But there's a difference between having access to information and knowing how to apply it.
Experience is shaped by the things that didn't go according to plan.
It's remembering the seemingly harmless change that broke something elsewhere. The elegant solution that became unnecessarily difficult to maintain. The feature that worked exactly as specified but didn't actually solve the user's problem.
It's learning that the simplest approach is often better than the most technically impressive one.
And sometimes, it's recognizing a familiar warning sign without immediately knowing what's wrong.
I don't think experience makes someone immune to mistakes. I've certainly made my share, and I expect I'll make plenty more.
But those experiences have changed the questions I ask before making decisions.
The problem with always having an answer
Large language models are remarkably good at producing convincing responses.
Give one a technical problem, and it will often propose a solution, explain the reasoning, and generate the implementation.
Sometimes it's exactly what you need.
Other times, it confidently recommends an API that doesn't exist, misunderstands a requirement, overlooks an important constraint, or produces something that appears correct until you examine it more closely.
We've become familiar with calling some of these mistakes hallucinations.
But what concerns me isn't just that AI can be wrong.
It's how easily a plausible answer can create the impression that a problem has been understood.
Software development is full of situations where there isn't one objectively correct solution. Requirements are incomplete. Priorities conflict. Budgets are limited. The consequences of a decision might not become apparent until months later.
In those situations, a confident answer isn't necessarily helpful.
Sometimes the responsible response is to acknowledge that we don't have enough information.
Sometimes it's to challenge the assumptions behind the question.
And sometimes it's simply to say, "I don't know. Let's investigate."
AI can do these things too. It can express uncertainty, compare alternatives, and challenge an approach. But it can also be overly agreeable, following the direction of a conversation toward a solution that perhaps shouldn't have been pursued in the first place.
That's something I try to remain conscious of when using it.
A convincing solution isn't the same as a well-understood problem.
Faster code doesn't always mean faster development
I recently came across a freelance job posting from someone who had used AI to modify their website and was now looking for an experienced developer to help fix it.
The client described the result as "AI slop."
What I found particularly interesting was what they wanted the developer to do.
Rather than asking someone to rebuild the website, they wanted an experienced professional to review it, identify the problems, recommend improvements, and provide instructions that another AI could use to implement the changes.
In other words, they were willing to pay someone not primarily to write code, but to evaluate it.
I think that's a fascinating example of how the profession is evolving.
AI can generate code remarkably quickly. But reviewing AI-generated code can require just as much critical judgment as writing it yourself. Sometimes more.
When you write something from scratch, you generally understand the decisions you made along the way.
When reviewing generated code, you're inheriting assumptions and decisions you weren't present to make.
You need to understand how the pieces fit together, what might break, whether the architecture makes sense, and whether the implementation actually solves the original problem.
Does it handle unexpected inputs? Is it secure? Will someone be able to maintain it? Does it introduce unnecessary complexity?
A working application isn't necessarily a reliable one.
And a passing test doesn't necessarily mean you've tested the right things.
AI can assist with all of this, and I use it for code review and debugging myself. But its output still needs to be evaluated.
The faster we generate solutions, the more important it becomes to understand what we're accepting.
The value of having someone to think with
I've had conversations with other software engineers and mentors about where our profession is heading.
There's an understandable uncertainty about how we continue to make ourselves relevant as AI becomes increasingly capable.
One observation from those conversations has stayed with me.
People still want someone they trust to help them navigate technology.
Not necessarily someone who knows everything, or someone who can write code faster than AI.
Someone they can talk to.
Someone who understands what they're trying to accomplish, asks questions they hadn't considered, and helps them make decisions they're comfortable with.
I've experienced this in my own work.
When someone approaches me with an idea, they rarely arrive with a perfectly defined technical specification.
They might want a new website, an application, an integration, or a way to automate part of their business.
But what they initially ask for isn't always what they actually need.
Sometimes a complete rebuild isn't necessary. Sometimes a complicated custom solution can be replaced with something simpler. Sometimes an idea needs more exploration before anyone should start implementing it.
The conversation matters.
A good collaborator doesn't simply agree with every suggestion and start building.
They might say, "Yes, but I'd approach it differently."
Or, "Have you considered what happens if this fails?"
Or, "I think we should understand the problem a little better before deciding."
That's not about being the smartest person in the room.
It's about bringing another perspective into the decision.
And being willing to disagree when it matters.
Learning to work with uncertainty
I think one of the most important things experience teaches us is how to navigate uncertainty.
Not eliminate it. Navigate it.
Software engineering has always involved incomplete information, changing requirements, unexpected behavior, and tradeoffs that aren't immediately obvious.
You make assumptions. You test them. You learn something. You adjust.
Over time, you develop a better sense of which decisions deserve more investigation and which risks are reasonable to accept.
That doesn't mean intuition should replace evidence. Quite the opposite.
Experience should make us more deliberate about validating our assumptions.
And that's especially relevant when working with AI.
We can reduce the impact of hallucinations by grounding models in actual documentation, examining the code they generate, running tests, validating behavior, and breaking complicated problems into smaller, verifiable steps.
But I don't think the answer is simply to write better prompts until AI stops making mistakes.
Humans make mistakes too.
The goal is to build a process that recognizes uncertainty and catches problems before they become consequential.
For me, that means treating AI as a powerful collaborator in the development process without automatically accepting its conclusions.
Sometimes I need it to generate an implementation.
Other times I need it to explore alternatives, identify weaknesses, or help me understand something unfamiliar.
And sometimes I need to stop asking for answers and reconsider the question entirely.
What happens when AI gets better at judgment?
There's an uncomfortable question worth acknowledging.
What happens when AI becomes better at recognizing uncertainty, challenging assumptions, understanding business needs, and recommending appropriate solutions?
We're already seeing improvements in these areas.
I don't think it's reasonable to assume that judgment, creativity, or critical thinking will always remain exclusively human strengths.
Nor do I believe that years of experience automatically make someone's decisions better than those of an AI system.
The technology is advancing too quickly for that kind of certainty.
But I also think there's a distinction between receiving a recommendation and having a relationship with someone who understands your circumstances and takes responsibility for the outcome.
When people collaborate, they're doing more than exchanging information.
They're developing a shared understanding of a problem. They're bringing different experiences into the conversation. They're questioning each other, negotiating priorities, and making decisions together.
Trust develops through communication, consistency, and accountability.
Whether AI will eventually replicate every aspect of that experience is an open question.
For now, I still find tremendous value in working with people who are willing to say what they think, challenge my assumptions, and admit when they don't know something.
And I try to offer the same in return.
Fourteen years later, I'm still learning
I love building software.
I love taking an idea, exploring what it could become, and gradually turning it into something useful, intuitive, or unexpected.
AI has made that process faster and, in many ways, more exciting.
It has also made me reconsider parts of my profession that I once took for granted.
If generating code becomes increasingly accessible, perhaps the value of engineering will be measured less by how much we produce and more by how thoughtfully we approach what we're building.
How well we understand the people we're building for.
How we handle uncertainty.
How willing we are to question our own decisions.
And how responsibly we use the tools available to us.
I started developing software in 2012, and I certainly don't pretend to have everything figured out.
There are technologies I haven't explored, problems I haven't encountered, and lessons I haven't learned yet.
But after nearly fourteen years, I'm increasingly comfortable with that.
Because one of the most valuable things experience has taught me isn't how to have all the answers.
It's knowing when I need to ask better questions.