Agentic AI started as a coding accelerator. But the shift happening inside engineering organizations now goes beyond productivity. Engineers are assembling their own agent teams, scoping what those agents can access, defining outcomes, and taking responsibility for what those agents produce. The role is evolving from task executor to orchestrator, and the expectations around what an individual contributor delivers are rising accordingly.
Leszek Wisniewski, Senior Engineering Manager at Magic Leap, leads a service team delivering productivity tools and analytics powering computer vision and algorithm development for Magic Leap's flagship product. Before Magic Leap, he held software engineering roles at Archilyse, EPAM Systems, and Lufthansa Systems. He holds a master's degree in Electronics from the Technical University of Gdansk.
"Right now, every individual contributor has a chance to be a manager because they can actually create an agent. They can create an agent team," says Wisniewski.
Wisniewski sees three immediate use cases driving adoption across his team and peer network: automating organizational bureaucracy like status updates and reporting, accelerating coding workflows, and using conversational AI as a leadership sounding board for managers facing difficult decisions or complex contexts.
The third use case is personal to him. "Leadership is a lonely position. When you have a tough decision, nobody will ever completely understand the context of your situation. AI gives you an opportunity to see options you haven't thought of before."
But the deeper organizational shift is what happens when agents absorb the execution work that used to define an engineer's day. Wisniewski now challenges his team to think like small business owners rather than task-focused contributors. "You have to think one abstraction level above. For a software engineer, that means thinking about revenue, not just improving a workflow by X percent." The expectation across his organization is that every individual contributor connects their work to broader business outcomes because the agent handles the layer below.
The shift creates a visible spectrum within teams. Some engineers thrive, treating the change as an opportunity to exercise language skills and strategic thinking alongside technical depth. Others struggle. "There are people who really excel in this new setup and there are people who don't do that very well yet. My main task as a manager right now is to get as many people on the other side of that spectrum."
Wisniewski identifies two risk profiles that concern him most. The first is the complacent senior engineer who delegates to agents without verifying output. The second is the junior engineer who lacks the intuition to recognize when an agent's output misses the mark. Both cases point to the same problem: ownership.
"You are the sole owner of the solution you're crafting. You can't delegate things to the AI and say if I messed up, it's what the agent messed up. At the end of the day it's always you." He sees this as a coaching challenge more than a technical one. Guardrails help, but the real defense is a culture where engineers understand they are accountable for every artifact their agents produce.
When pressed on where architectural stress concentrates as more engineers orchestrate agents, Wisniewski is clear: the application layer. "I believe the application layer is the best place to validate where all of the data is coming in. With the amount of integrations you can have, you now have just as many new data sources entering your system."
He favors the classical model where data is sanitized, validated, and gated through API boundaries before anything reaches the database, keeping the architecture interchangeable and deterministic regardless of which agents are operating above it.
The database remains the system of record, not the place where agents should operate freely. "Senior engineers who have taken more reps in this classical approach know that data should always be sanitized, reviewed, and validated before it hits the database. I think that model will prevail." He acknowledges that some companies will chase efficiency by loosening agent access to the data layer directly, and that competitive pressure will push others to follow. But the more durable pattern, he argues, keeps intelligence at the edge and truth in the database.
Looking further ahead, Wisniewski expects agents to become first-class actors in engineering systems with scoped permissions and event-driven interactions. But he also expects the competitive advantage of agentic AI itself to eventually flatten.
"AI and agentic AI will not be a competitive advantage at some point. It could be three years, it could be ten." What will differentiate teams then is whether engineers take ownership of what their agents build and whether the architecture underneath enforces that accountability by design.
