Jaskaran Singh — Senior Software Engineer, AI Trainer
A few weeks ago I watched an agent open a GitHub issue, write the fix, run the tests, and open a pull request. No human typed a line of code. The PR passed review.
I didn't find this inspiring. I found it genuinely disorienting. I say that as someone who trains AI models for a living and is currently building an agent of my own.
If you're a software engineer in 2026 and you haven't had that moment yet, you will soon. Agentic AI is being called the third seismic shift in software engineering this century, after open source and DevOps. That framing might be overblown. It might not be. Either way, something real is happening and it's worth thinking clearly about instead of panicking or dismissing it.
Here's what I actually think is going on.
The Numbers Stopped Being Theoretical
A survey of nearly 1,000 engineers published in early 2026 found that 95% use AI tools at least weekly, 75% use AI for half or more of their engineering work, and 55% regularly use AI agents. That last number is the one that matters. Copilots have been mainstream for two years. Agents are different.
A copilot suggests. An agent acts. It reads your codebase, decides what to do, does it, checks whether it worked, and tries again if it didn't. The feedback loop is closed without you in it.
In 2025, coding agents moved from experimental tools to production systems that ship real features to real customers. In 2026, single agents are becoming coordinated teams of agents.
I've been watching this from an unusual angle. My job involves evaluating AI-generated code for quality: finding the failure modes, writing the rubrics, doing the multi-turn reviews. At the same time I'm building a Python agent that monitors the OINP immigration portal and pushes Telegram alerts whenever a new Masters Graduate stream draw drops. Two different relationships with the same technology. Both have given me a clearer picture than I'd have from either side alone.
What Agents Are Actually Good At Right Now
Most takes on agentic AI are either breathless or dismissive and neither is useful. Let me be specific.
Agents handle implementation tasks well when the problem is well-scoped and verifiable. "Add pagination to this endpoint." "Write tests for this module." "Refactor this class to use dependency injection." These are tasks with clear success criteria: the code runs, the tests pass, the interface contract is unchanged. The agent can verify its own work.
The implementation quality still varies. My evaluation work confirms what engineers describe: they develop intuitions for delegation over time, tending to hand off tasks that are easily verifiable or low-stakes. That intuition is real and it matters. Knowing what to delegate is itself a skill now.
Where agents fall apart is anything requiring judgment about what the right problem even is. An agent given an ambiguous brief will confidently solve the wrong version of it. I've seen this pattern repeatedly, not as an occasional edge case but as a consistent failure mode when the task specification has gaps. The agent doesn't ask for clarification. It infers, fills in, and proceeds. Sometimes the inference is right. When it's wrong, it's wrong in ways that are coherent and hard to catch.
The Shift That's Actually Happening to Engineering Teams
Gartner predicts 80% of organizations will evolve large software engineering teams into smaller, AI-augmented teams by 2030. The trajectory is already visible. Teams that used to need eight engineers to maintain a product are running it with four. Not because the other four got fired, but because agent-assisted output per engineer went up enough that the headcount math changed.
The pattern emerging in 2026: software development is moving toward a model where human expertise focuses on defining the problems worth solving while AI handles the tactical work of implementation.
That framing is mostly right but it undersells something. "Defining problems worth solving" sounds clean and strategic. In practice it means writing a spec precise enough that an agent doesn't go off the rails, reviewing agent output at a level that catches subtle correctness issues, and making architecture decisions that hold up when the agent starts filling in implementations you didn't anticipate.
Those are all hard skills. They're also different from the skills that got most of us into engineering. We learned by writing the implementation ourselves. The feedback loop of "I wrote this, it broke, I understand why" is how you build the mental models that make good judgment possible. It's not obvious that judgment transfers cleanly to directing agents at tasks you've never done yourself.
What This Means If You're Mid-Career
I've been thinking about this a lot. I'm five years into my career. I've shipped production Android apps, done fintech work, and I'm now working at the AI training layer. The people who seem least threatened by this shift share one thing: they understand systems, not just syntax.
A developer who knows Kotlin and can write Jetpack Compose components is in a different position than a developer who understands why coroutine cancellation works the way it does, when a ViewModel scope is the wrong choice, and what the architectural consequences of a particular state management approach are three features down the road. The first kind of knowledge is increasingly delegatable. The second is what you need to review what the agent produces.
This is not a comfortable message. It basically says the work that builds deep knowledge is being automated before you've had a chance to accumulate it through repetition. That's a real problem for junior developers and I don't have a clean answer to it. What I do think is that engineers who actively seek out the "why" behind every pattern they use, even when an agent handed them that pattern, will pull ahead of those who treat agent output as a black box.
The Security Problem Nobody Talks About
Agentic coding is changing security in two directions. As models get more capable, building security into products gets easier. But the same capabilities that help defenders help attackers too.
There's a third direction I'd add from my evaluation work: agents introduce security risks through confident implementation of insecure patterns. An agent writing a data pipeline will reach for the most direct path to working code. Input sanitization, parameterized queries, credential management, error handling that doesn't leak internals: these require deliberate thought. Agents do them inconsistently.
The more autonomous the coding pipeline, the more critical it is to have security review that isn't the same agent that wrote the code. This is not theoretical. I've flagged SQL injection vulnerabilities in agent-generated Python and credential handling issues in agent-generated Kotlin. The code was functionally correct. It would have passed a cursory review. It shouldn't have shipped.
Why I'm Still Building Agents
None of this made me stop building the OINP monitoring bot. It made me more deliberate about it.
The thing I'm building isn't trying to do something clever. It checks a government webpage on a schedule, parses the draw results, compares against the last known state, and fires a Telegram message if something changed. The agent part is the parsing logic: handling inconsistencies in how the page is structured, dealing with cases where the data format shifts slightly. That's a good use of what these tools are actually good at.
The immigration system in Canada is opaque in ways that are genuinely stressful for people on it. If a monitoring tool reduces that stress even slightly, it's worth the weekend. The judgment about what's worth building and why is still entirely mine.
That's probably the honest answer to "now what." The judgment work is still yours. The implementation is increasingly negotiable.
Jaskaran Singh is a Senior Software Engineer working in AI training and evaluation, with production experience in Android development using Kotlin and Flutter. Currently building a Python-based OINP immigration monitoring agent.
Top comments (0)