How AI is Shaping Me as an Engineer
Reflections on Building Software in the Age of AI
👋🏻 Hey, I'm Priya I am software developer at HackerRank.
I have been a Student Software Developer under Google Summer of Code for CHAOSS and have been an intern at Dineout (Times Internet).
💬 Reach me: twitter.com/shivikapriya
When I started out as an engineer, I thought my job was to write perfect code. I once spent an entire weekend refactoring a small function, only to realize later that barely anyone used it. That experience taught me something I’ve been relearning ever since: the hard part of engineering isn’t the code itself, it’s choosing the right problems to solve.
That lesson became even clearer when I worked on two very different teams: one building 0→1 products where speed mattered most, and another maintaining critical systems where stability and trust came first. In both, the quality of my decisions mattered more than the elegance of my code.
AI has made this shift impossible to ignore. It can generate the “how” in seconds, which means my value as an engineer increasingly depends on the “what” and the “why.” Every time I use AI, I’m forced to think more critically about my goals, assumptions, and trade-offs. In that sense, it’s not just speeding up my coding, it’s reshaping how I approach engineering itself.
Building for Products vs. Building for Curiosity
One of the biggest shifts in my thinking as an engineer has been realizing that what I’m building for changes everything about how I build.
When I’m working on a POC at work or a 0→1 feature, the real question is: does this solve the right problem for the user or the business? In that mode, AI tools become part of a pipeline that helps me frame and validate ideas faster:
I’ll use Claude Projects to brainstorm and organize product features. Sometimes it feels like a draft spec generator, it doesn’t just spit out code, it lays out flows and trade-offs. The discussion becomes a way to explore my ideas into product spec which I can then go ahead and build.
From there, I’ll move to Lovable to spin up a working prototype. Seeing a demo in hours makes it much easier to ask, “should we pursue this?” rather than getting stuck in “can we build this?”.
Then I’ll pull the project into Cursor, where I extend the code, refine the rough edges, and build out the actual features.
I can use ChatGPT to get a rough cost estimate of the infra I’m building, like how much a particular architecture or setup might cost to run in the cloud.
That chain: idea to spec to prototype to product used to take weeks. Now it can happen in a matter of days.
But when I’m building for myself, on personal projects, the mindset is different. There, the question is what do I want to learn, and how can I build something hands-on to learn it?
One time, I tried to implement a version of jq in Go using Claude Code. The model took the regex path for string manipulations. It worked, but I realized quickly that an AST-based approach would have been more reliable and extensible. That single exercise, even though it was just for fun, taught me something valuable: AI can accelerate exploration, but it can also expose the trade-offs in your design choices.
For me, both styles of building matter.
Product-led work teaches me judgment: focusing on user value, not just code.
Curiosity-led work stretches my technical range: trying stacks or approaches I wouldn’t otherwise attempt.
And AI sits in both worlds, not as a replacement for me, but as a collaborator that adapts to the goal I have in mind.
AI as a Thinking Partner
I use Claude and ChatGPT almost daily, not just for code, but as thinking buddies.
Have you ever been in a deep brainstorming session with ChatGPT that feels like you’re pair-exploring with someone who never gets tired?
It’s not about them being right (they’re wrong plenty of times). It’s about how the process sharpens my reasoning. Explaining an idea to AI often surfaces flaws I wouldn’t have noticed. Sometimes it even introduces me to solutions I didn’t know existed.
I’m still in the early part of my career, and I’ll admit — there are many choices and solutions out there I haven’t been exposed to yet. More than once, a “research session” with AI has pointed me toward an approach or technology I didn’t even know to search for. Those moments have been game-changing, not because AI gave me a possible answer, but because it widened the space of possibilities I could explore.
It feels less like outsourcing thinking, and more like having a tireless rubber-duck debugger: one that occasionally asks the right questions back.
Prototyping at Warp Speed
What excites me the most being an engineer in the AI-enabled world is the ability to prototype at the speed of thought!
You don’t get stuck for weeks on “is this worth building?”, you can answer that in a weekend.
Curiosity compounds faster. I can explore domains outside my comfort zone. With AI as my learning buddy, I can poke around in design, ML, or infra without getting stuck in tutorials. I like figuring things out by trying, breaking, and iterating, seeing where my questions lead.
The shift toward judgment and creativity as the differentiator. Everyone can generate code now, but not everyone can decide what’s worth solving.
If I get an idea Friday night, I can ship a rough prototype by Sunday. A few months ago, I had an idea for a small internal tool. Normally, it would have taken me two weeks of evenings to get a demo running just enough to see if the idea was worth anything. With Lovable, I had a working prototype in under 4 hours. By Monday, I was already showing it to teammates and getting feedback.
That speed completely changed the question. Before, I would waste time wondering “Can I even build this?” Now, the real question is “Should we build this at all?”
AI makes failure cheaper, which makes exploration bolder!
AI in Production Systems
Working on production systems is very different. There’s no room for “move fast and break things.” Trust is the product.
Here, AI isn’t a silver bullet. It won’t replace careful testing or deep domain understanding. But it does help in subtle ways: generating test cases, suggesting edge cases I hadn’t considered, improving documentation for teammates. AI sped up the routine parts, leaving me face-to-face with the hard questions only a human can answer.
I have spent my fair share of time contemplating reliability in the world of AI. I will not blindly trust AI to code entire production systems for me. That is a formula for issues. AI may suggest solutions, but the responsibility of ensuring correctness, consistency, and robustness remains with me. It’s easy to get impressed by prototypes, but the real challenge is making AI reliable at scale. That means system design fundamentals: observability, validation, fallbacks, and well-architected workflows. These are the same fundamentals we apply elsewhere, now re-imagined for GenAI.
Reliability is what makes or breaks software in production. Users return not for intelligence alone but for consistency, predictability, and trust. Even one failure, hallucinated output, or unexpected behavior can erode confidence.
Trust is engineered, not assumed. That means I approach AI-assisted development with human judgment firmly in the loop. Every suggestion, every generated snippet, every prototype goes through evaluation, testing, and context-aware adaptation. In production systems, reliability is not an afterthought, it is a first-class metric. AI accelerates work, but it does not replace the responsibility of building systems that are safe, and reliable.
Knowing what you want
AI won’t magically know your goals. If you don’t have clarity on what “better” looks like, no prompt will get you there. The more explicit your intent, the more powerful AI becomes. It’s not about saying, “fix this!” It’s about providing context, defining your objectives, and guiding AI toward solutions that matter.
What I Will Tell My Future Self
With AI, you are no longer just a software engineer. You are a product developer. Ideas can go from thought → prototype → real product faster than ever before.
But never hand over critical decisions blindly. Let AI accelerate your work, but keep human judgment at the center. Focus on learning, experimentation, and understanding trade-offs. Use AI to stretch your curiosity and explore areas you wouldn’t attempt on your own.
Keep asking the big questions: Am I solving the right problem? Is this useful? Is this reliable? AI can speed you there, but you are still the pilot.
Being an engineer today isn’t about how many lines of code you write. It’s about asking sharper questions, testing ideas faster, and using AI to accelerate not replace your judgment. If AI is our co-pilot, the real question is: what kind of pilots do we want to be?
