Engineering Management · PiniShv

Agentic Overwatch: Why Your Next Dev Team Will Look Like a NASA Control Room

Mon, 01 Jun 2026 21:00:00 +0300

It’s 3:00 AM and a dozen screens are still on. Most of the company is asleep. A few people aren’t, because the systems they watch don’t keep office hours. A graph spikes red, someone acknowledges the alert, a fix goes out, the line settles back to green. Then the next one.

Early in my career I spent less than a year inside a Network Operations Center like that. Short stint, but it stuck with me. We kept thousands of live servers running in real time, 24/7. When something broke at 3:00 AM we didn’t file it for the morning stand-up. We fixed it then and there. We were the failsafe, and the failsafe doesn’t get to sleep through the incident.

I keep coming back to that room, because I think it’s where the whole software industry is heading. Not just engineering. All of it.

Here is the part most people haven’t clocked yet. The agents everyone is so excited about don’t only write code. Inside the organizations that are actually leaning in, one agent is rebalancing cloud spend before the monthly bill blows the budget. Another just quarantined a leaked token and is drafting the security writeup. A third is rewriting the flaky test suite that’s been blocking the release train. A fourth shipped the incident postmortem before the humans woke up. A fifth is halfway through a customer’s support ticket. None of them asked permission. Every one of them is doing work that used to belong to a person with a title.

That isn’t a dev team anymore. It’s a workforce. And almost nobody has a single screen that shows what the whole workforce is doing right now.

We are handing autonomous agents the keys to engineering, operations, security, QA, data, and support, at a velocity no human team can match. And we are still governing them with the model we built for hand-typed software: nine to five, five days a week, with a fragile on-call rotation taped to the side. We still expect a tired human to “step up” at 2:00 AM and babysit production.

That expectation was already shaky when humans wrote all the code. It snaps the moment the code, the infra changes, the security responses, and the test rewrites all start writing themselves.

You cannot govern a workforce that runs flat out, around the clock, with a team that logs off at 5 PM.

We are entering the era of Agentic Overwatch.

Defining the term
#

I want to say plainly what I mean, because the industry keeps gesturing at this without naming it.

Agentic Overwatch is the discipline of supervising a fleet of autonomous AI agents in production the way an operations center supervises live infrastructure. A NOC watches uptime. A SOC watches threats. Agentic Overwatch watches the agents themselves, whatever function they happen to be performing, and keeps a human in the loop for the decisions that carry real consequences. Continuous, tiered, shift-based. The unit of work is no longer a line of code. It is the fleet, and the human’s job is to steer, judge, and authorize rather than type.

That is the whole idea. Everything below is the architecture of it.

The room needs a name too, because it earns one. A NOC is a Network Operations Center. A SOC is a Security Operations Center. This is the Agent Operations Center, the AOC, and the people who staff it are the AOC team. That is what I mean every time I say “the room” from here on.

A couple of things it gets confused with, so let me clear them out of the way.

It is not AIOps or observability. Those tools watch your systems and surface anomalies for a human to go fix. Overwatch watches your agents, the workers that are themselves taking action, and a human approves or vetoes what they propose. The thing under supervision moved up a level. Your dashboards used to show you CPU and latency. Now they have to show you what your workforce is deciding to do about CPU and latency.

It is also not vibe coding. Vibe coding is the casual, almost magical act of prompting an AI to spit out an app while you sip your coffee. Fun trick. It completely ignores what happens after the demo, when that code scales and thousands of agents are making real decisions in a live environment at once. Vibe coding is about generating. Overwatch is about governing. They are not in the same job family.

And to head off the obvious question: yes, a few security vendors ship products with “OverWatch” in the name for threat hunting. This is broader than any one product. Agentic Overwatch is not a thing you buy. It is the operating model for supervising your whole agent fleet, whatever job it happens to be doing.

It was never just about code
#

The phrase “AI writes code” undersold this from the start. Code was simply the first job agents got good enough to take.

Watch where they spread next, because it is already happening. In operations, agents scale services up and down, reroute traffic, and roll deployments back when error rates climb. In security, they triage alerts, revoke credentials, and isolate compromised workloads. In QA, they generate tests, reproduce bugs, and gate releases. In data, they fix broken pipelines and backfill tables. In FinOps, they hunt down waste and right-size infrastructure. In support, they resolve tickets that used to sit in a queue for two days. Each of these is a function that an entire team used to own. Now an agent owns a slice of it, and the slice keeps growing.

I wrote a while back about putting AI agents on the org chart, with real owners and real KPIs. The point lands harder now. If agents staff every function, then the most dangerous failures are not the ones inside a single function. They are the ones that cross between them. The cost agent right-sizes a database at the exact moment the deploy agent ships a migration against it. The security agent revokes a service account that, three systems away, runs the nightly billing job. No single team owns that collision. No single dashboard sees it coming.

That is why this has to be one room watching one fleet, not five tools watching five corners. The whole reason the NOC worked was that it sat above the silos and saw the system whole.

The governance gap
#

Output is compounding across every one of those functions. Oversight is flat. I made this point about code specifically, but the curve is identical for deploys, security responses, and data changes: we can produce far faster than we can supervise.

That is the governance gap, the widening distance between how much autonomous work is happening and how much human oversight actually covers it. We are treating agents like a brilliant intern we leave alone in the building overnight. Never sleeps, never tires, ships to production on its own schedule, and nobody is watching while it does. Shadow AI already proved teams will wire up unsupervised agents faster than leadership can react. This is not a forecast. The gap is in your stack tonight.

When those agents trigger a cascading failure at 3:00 AM, and eventually they will, “we were all asleep” is not a line you want in the postmortem. Closing the gap is not a tooling purchase. It is a change in how teams are built and how they run the clock.

Borrow the tier model from the NOC
#

Here is what the NOC got right decades ago, and it maps onto agents almost perfectly. Operations has always run in tiers. Agentic Overwatch keeps the structure and changes who sits in each chair.

Tier 1, detection and triage. Agents. They watch every signal across every function, correlate the noise, classify severity, and kill the false alarms that used to wake people up for nothing.

Tier 2, diagnosis and remediation. Agents. They reproduce the failure, trace the blast radius, draft the fix, write the rollback plan, and stage it. This is the work that used to eat a senior engineer’s entire night.

Tier 3, judgment and authorization. Humans. Not because we are faster, but because we own the consequences. This is the split-second call that actually carries weight: “Agent 4 found a memory leak in the payment gateway and wants to roll the database back. Approve or reject?” Or the one that crosses functions: “The security agent wants to revoke this service account to contain a breach. It also runs tonight’s billing. Approve or reject?”

Agents do the work in Tiers 1 and 2. Humans own the call in Tier 3.

The leverage is obvious once you see it. Tiers 1 and 2 were always the exhausting, repetitive, sleep-wrecking tiers, and those are exactly the tiers agents are best at. The human moves up to Tier 3, where the work is rare, consequential, and human by nature.

The agents do the work. The humans own the call. That is the entire operating model, and it fits on a sticky note.

The human becomes the orchestrator
#

So what is left for the human in the loop? Everything that actually matters.

The people in the Overwatch room are orchestrators. They don’t write the hotfix, because the agent already wrote three versions of it. They bring the judgment, the context, and the boundaries the agent doesn’t have. They decide which proposal ships and which one gets killed before it touches a customer.

This is the thread I keep pulling on. I’ve written about AI reviewing AI’s code and about orchestrating multiple agents when one isn’t enough, and I’ve argued that the IDE is becoming mission control. Every vendor is rebuilding its product around the agent rather than the file. Overwatch is what that mission-control surface is finally for. Walk into one of these rooms in a few years and you will not see engineers hunting for a missing semicolon. You will see a wall that tracks the live workflows, decision trees, spend, and health of thousands of agents across every department, and a small number of very sharp people steering it.

The Overwatch engineer is part SRE, part reviewer, part air traffic controller. The scarce skill is not typing speed. It is the calibrated judgment to know when an agent’s confident-looking fix is about to make everything worse.

For this to work, the culture has to borrow the operational rigor of those old NOC rooms. The artisan era of software is giving way to an industrial one, and industrial operations do not go home at 5 PM. The 9-to-5 gets replaced by continuous, shift-based orchestration. Follow-the-sun, the way global operations have run for decades. Nobody wakes a single exhausted developer at 2:00 AM. A fresh, fully alert Overwatch engineer on the AOC team catches the agent’s proposed fix and authorizes the deploy before the customer ever sees a glitch.

The handoff: ownership changes hands at the end of the day
#

A NOC shift never ends with everyone just going home. It ends with a handoff. The outgoing team tells the incoming one what is running, what is fragile, what to watch, and what to do if it breaks. Agentic Overwatch needs the same ritual, and it is the piece most teams will forget.

When a developer wraps for the day, they should not close the laptop and hope their agents behave overnight. They hand ownership of their in-flight work to the AOC team. Not “keep an eye on things.” Actual ownership: these agents are mine, here is what they are doing, and from now until tomorrow morning they are yours to steer.

What makes that handoff real is the runbook. For every agent or workstream a developer hands over, there is a short, blunt document that answers the questions the AOC team will actually face at 3:00 AM:

What is this agent doing, and what does normal look like?
What are the failure modes, and how do I tell them apart?
For each scenario, what is the AOC authorized to do on its own? Approve the rollback? Pause the agent? Reroute traffic? Page the owner? Or just log it and wait?
What must never happen without waking me up?

This is what lets a human who did not write the code still own the call. A good runbook turns “I don’t know, it isn’t my code” into “the runbook says approve the rollback, so I approve it.” Without runbooks the AOC can only watch and escalate, which means you are right back to waking people at 2:00 AM. With them, the room can act with the same confidence the author would have had.

So the definition of done changes.

A feature is not done when the code merges. It is done when the AOC can run it without you.

The runbook becomes part of shipping, the same way tests and docs are. If you cannot hand your agent off with a page that tells a stranger how to govern it at 3:00 AM, you have not finished building it. You have just stopped typing.

The Overwatch Maturity Model
#

If you want to know where your team actually sits today, and where it needs to go, here is the curve. Borrow it, argue with it, cite it.

Level 0, blind. Agents do real work, humans review during business hours, and nobody watches what runs overnight. Most teams are here and don’t know it.

Level 1, alerting. Agents act, and when something breaks they page a human who logs in and fixes it by hand. The on-call rotation with extra steps. Still reactive, still wrecking someone’s sleep.

Level 2, assisted remediation. Agents detect, diagnose, and propose fixes. A human reviews the proposal and approves execution. Tier 3 exists, but coverage is patchy and tied to working hours.

Level 3, continuous Overwatch. Shift-based human coverage, agents running Tier 1 and Tier 2 around the clock, and a real authorization layer for consequential actions. The room is staffed whenever the agents are working, which is always.

Level 4, orchestrated fleet. Overwatch itself is the discipline the company is organized around. One view across thousands of agents in every function, codified escalation policies, agent KPIs, and humans whose entire job is steering the swarm. This is the control room.

Almost everyone is at Level 0 or 1. The point is to stop pretending otherwise.

The honest answer for almost everyone reading this is Level 0 or 1. The point is not to leap to Level 4 next quarter. It is to stop pretending you are further along than you are.

How to start before your agents force the issue
#

You do not need a war room with floor-to-ceiling monitors next week. You need to start building the operational muscle now, while the stakes are still survivable.

Map your autonomy honestly. Write down every place an agent already acts without a human in the loop, across every function, not just engineering. The list is longer than you think, and the surprises on it are your real risk.
Define the authorization boundary. Decide which actions an agent runs freely and which require a human first. Payments, migrations, credential changes, anything that can take down the service or leak data: agent recommends, human approves, agent executes.
Instrument the agents, not just the systems. You need a view of what your agents are deciding, not only what your servers are doing. If you cannot see the fleet, you cannot steer it.
Write the runbooks, and make them part of done. For every agent a developer hands off, ship a page that tells whoever is on shift what normal looks like, what the failure modes are, and exactly what they are allowed to do about each one. No runbook, not done.
Staff the clock, not the calendar. Start small. Even a thin follow-the-sun rotation across two or three regions beats one time zone pretending production sleeps.
Give the room real authority. An Overwatch engineer who cannot veto an agent or halt a deploy is not doing Overwatch. They are a spectator with a nice dashboard.

The teams that build this muscle now will run hybrid fleets calmly while their competitors are still getting paged at 3:00 AM and writing apologies in the morning.

The fleet doesn’t sleep
#

The agents never tire. They never log off. Soon our operational models won’t either.

The move from artisan to operator is not optional, and it is not far off. It is the difference between governing your agents and being governed by their failures. The companies that win the next decade will not be the ones that generate the most code, or close the most tickets, or ship the most deploys. They will be the ones that can watch the whole fleet do all of it: continuously, calmly, around the clock.

Stop writing lines of code. Start commanding the fleet.

Welcome to the era of Agentic Overwatch.

I lead Innovation for a global SaaS platform, and I spend my time on one question: how do teams get dramatically more out of the people and tools they already have? Agentic Overwatch is my own thesis about where that goes next, and it is what I have been preaching to anyone who will listen. If it resonates, or you are just realizing you are sitting at Level 0, I want to hear about it. Find me on X, LinkedIn, or Telegram. And if you start using the term, you know where it came from.

Org Charts for AI Agents: Mapping Your Human and AI Workforce

Sat, 13 Dec 2025 15:30:00 +0200

I’m already doing this. My teams have AI agents doing real work, with defined roles, human owners, and performance metrics. We’ve moved past “should we use AI?” a long time ago. But when I talk to other engineering leaders, most are still running pilots on “how to use ChatGPT effectively.” They’re debating tools while we’re deploying workers. If that’s you, wake up. AI agents are here. They’re not coming. They’re already doing work. And they need to be somewhere in your org chart.

I’m not being metaphorical. These aren’t tools that sit on a shelf waiting to be invoked. They’re systems that do real work across the entire development lifecycle. They read Jira tickets and break them down into smaller, actionable tasks. They analyze the codebase to understand context before writing code. They write the code itself. They review pull requests from both humans and other agents, catching issues before merge. They run tests, interpret failures, and fix what broke. They deploy to staging and production. They update ticket status and add implementation notes. They generate documentation when features ship. They run 24/7. They have defined responsibilities. They produce output that affects your business.

If that sounds like a job description, that’s because it is.

The question isn’t whether AI agents belong on your org chart. The question is why you haven’t put them there yet.

The wake-up call most teams need
#

Let me describe what I’m seeing in organizations that are actually ahead on AI adoption.

Company A has agents embedded in their entire development workflow. One agent monitors the backlog, breaks down tickets, and prepares implementation plans before engineers even start their day. Another picks up tasks and writes the actual code, creating PRs ready for review. A third reviews every PR, checking for security issues, test coverage, and architectural consistency. A fourth handles deployments, monitors rollouts, and rolls back automatically if error rates spike. Their engineering lead treats these agents like team members because functionally, they are. They have owners, performance metrics, and defined responsibilities.

Company B still has their engineering team debating whether Copilot is worth the license cost. They’re running a three-month pilot with a committee to evaluate results. Their developers manually review every PR line by line, deploy through a manual checklist, and spend the first hour of every ticket just understanding what needs to be built.

The gap between these two isn’t technology. It’s mindset.

Company A asked: “How do we integrate AI into how we work?” Company B asked: “Should we use AI?” By the time Company B finishes asking, Company A will have deployed their fourth agent.

This is the wake-up call: AI agents are here. They’re working. They’re producing output. The adoption curve for agentic AI has been faster than anything we’ve seen before. Within two years, roughly a third of enterprises have deployed agents in production. And the organizations actually using them? Most already treat agents as coworkers, not tools. If you’re still thinking about this as “adopting a new tool,” you’ve already fallen behind teams that are thinking about it as “building a hybrid workforce.”

Why agents belong on the org chart
#

I know what you’re thinking. “Putting software on an org chart sounds ridiculous.” But hear me out.

Org charts exist for clarity. They answer: Who does what? Who’s responsible for what? Who reports to whom? If an AI agent is doing meaningful work, those questions apply to it too.

When you don’t include AI agents in your organizational structure, you create invisible workers. Work gets done, but nobody knows exactly what’s doing it or who’s accountable when it goes wrong. That’s not a small problem. That’s the recipe for incidents that nobody can trace, drift that nobody notices, and technical debt that compounds invisibly.

Here’s what putting AI agents on the org chart actually solves:

Accountability. Every agent has a human owner. When the development agent writes code that breaks in production, someone is responsible for improving its guardrails. When the code review agent starts missing security issues, someone tunes its rules. When the deployment agent causes a failed release, someone owns the post-mortem. When the ticket analysis agent consistently overestimates complexity, someone adjusts its model. No more “the AI did it” as an excuse.

Visibility. Your team can see what’s actually doing the work. Everyone knows the ticket analysis agent breaks down and estimates new issues before sprint planning. The development agent picks up approved tasks and creates PRs. The code review agent checks every PR before the tech lead sees it. The deployment agent handles staging releases automatically but flags production deploys for human approval. No mystery workers.

Planning. When you understand your full workforce (human and AI), you can plan capacity properly. You know what you have, what it can do, and where the gaps are. You can make real decisions about when to hire humans versus when to deploy another agent.

Coordination. Workflows become explicit. “New tickets get analyzed by the ticket analysis agent, which breaks them into tasks and estimates complexity. The development agent picks up tasks and writes the code. The code review agent checks every PR. If it passes automated checks, the tech lead does final review. The deployment agent handles staging, runs integration tests, and notifies the team. Production deploy requires human approval.” Everyone knows the handoff points between humans and agents.

What this looks like in practice
#

Let me make this concrete.

The wrong way: You give developers access to Copilot and call it done. Some use it heavily, some ignore it. Nobody knows which code was AI-assisted. PRs get merged without anyone understanding if the AI suggestions were good or just fast. When bugs slip through, there’s no way to trace whether AI-generated code was the cause. The team has AI, but no structure around it.

The right way: You deploy agents with clear positions in your org structure. Your development agent reports to your Tech Lead. It picks up tasks from the backlog, analyzes the codebase for context, writes the code, adds tests, and creates PRs. The Tech Lead reviews its output, provides feedback when the approach is wrong, and approves when it’s right. Your code review agent also reports to the Tech Lead. It checks every PR for security vulnerabilities, test coverage gaps, and violations of your architectural patterns. It comments on PRs, requests changes, and approves when standards are met. Humans handle the judgment calls: is this the right approach? Does this solve the actual problem? Everyone knows the workflow. It’s documented. It’s managed.

Same pattern applies across the development lifecycle. Your ticket analysis agent reports to whoever owns backlog grooming. Your development agent reports to whoever owns the codebase and architecture. Your deployment agent reports to whoever owns release management. Your documentation agent reports to whoever owns developer experience. Each has clear scope, clear ownership, and clear metrics.

This isn’t theoretical. My teams work this way, and every high-performing team I know has already made this shift. They don’t think of AI as a tool they use. They think of it as a capability they manage.

Best practices from teams actually doing this
#

I lead teams that work this way, and I’m in contact with engineering leaders across the world doing the same. Some patterns work better than others.

Give every agent a human owner
#

This is non-negotiable. Every AI agent needs a human who is responsible for its output. Not “responsible if something goes wrong.” Responsible, period.

That human should:

Review the agent’s outputs regularly (not just when there’s a problem)
Know what the agent is supposed to do and what it’s not supposed to do
Have the authority to tune its behavior or shut it down
Be the escalation path when the agent encounters something outside its scope

Think of it like managing an extremely productive but occasionally confused team member. They need oversight. They need feedback. They need someone paying attention.

Define explicit boundaries
#

AI agents should have clear job descriptions. What tasks they handle. What decisions they can make. When they must escalate to humans.

This isn’t just about safety (though it is). It’s about reliability. An agent with clear boundaries is predictable. You know what to expect from it. Your team knows what to expect from it. Customers know what to expect from it.

Vague scope leads to vague results. If you can’t articulate exactly what your agent is supposed to do, you’re not ready to deploy it.

Onboard and train them like team members
#

New AI agents should go through an onboarding process. Load them with your context: codebase architecture, coding standards, style guidelines, past decisions, and domain knowledge. A development agent needs to understand your patterns, your conventions, and why things are built the way they are. Configure access permissions carefully. Set up integration points with your ticketing system, code repository, CI/CD pipeline, and communication tools.

Then train your human team to work with them. What can the agent do? What are its limitations? How do you interpret its outputs? How do you give it feedback?

The teams that skip this step wonder why their agents produce inconsistent results. The teams that invest in proper onboarding get agents that actually fit into their workflows.

Set goals and measure performance
#

If your human team members have KPIs, your AI agents should too.

For a development agent: Code quality of generated output. How often its PRs pass review on the first attempt. Test coverage of code it writes. Bugs introduced per feature. Time from ticket to working PR.

For a code review agent: Accuracy of flagged issues. False positive rate. Time saved per review. Security vulnerabilities caught. Bugs that slipped through despite review.

For a ticket analysis agent: Quality of task breakdowns. Accuracy of complexity estimates. Time saved in sprint planning. How often humans override its suggestions.

For a deployment agent: Successful deployment rate. Mean time to rollback when issues occur. False positive rate on health checks. Incidents caused by deployment failures.

Track this data. Review it regularly. If an agent isn’t meeting its targets, tune it or remove it. Don’t let underperforming agents linger just because “AI is supposed to be good.”

Keep humans in the loop for consequential actions
#

Some actions are too important to delegate fully. Production deployments. Database migrations. Changes to authentication or payment systems. Anything that could take down the service or expose customer data.

For these, the right pattern is: agent recommends, human approves, agent executes. The development agent writes the code and creates the PR, but a human reviews before merge. The deployment agent prepares the release and runs pre-flight checks, but a human approves production deploys. Then the agent handles the actual execution, monitoring, and rollback if needed.

This isn’t about not trusting AI. It’s about maintaining appropriate control over decisions that matter. Even great AI agents make mistakes. For high-stakes decisions, you want a human checkpoint.

The uncomfortable conversations this forces
#

Putting AI on your org chart forces conversations that many teams have been avoiding.

“What are we actually paying people to do?” When agents handle the routine work, human roles need to shift. Are your developers still manually checking PRs for test coverage and linting issues? Why? Are they still writing boilerplate code that an agent could generate? Are they still manually updating Jira tickets after every commit? The value of human work should be in architecture decisions, complex problem-solving, and handling the edge cases that AI can’t reason about.

“How do we grow junior talent?” If AI handles the entry-level tasks that used to train juniors, how do juniors learn? This is a real problem that requires intentional design. Junior developers need to understand what the AI is doing, not just accept its output. They need opportunities to work without AI assistance so they build foundational skills.

“Who’s actually accountable when AI fails?” AI failures aren’t like software bugs. They’re often subtle, contextual, and hard to detect until damage is done. Someone needs to be watching. Someone needs to care. If nobody on your team owns the AI agent’s behavior, you have a governance gap.

“How much of our capability is human versus AI?” Some organizations are discovering that more of their output than expected is AI-generated. That’s not necessarily bad, but it requires honesty about what you’re building and who’s building it.

The risks nobody wants to talk about
#

I’d be doing you a disservice if I only talked about the upside. Deploying AI agents without proper structure creates real problems.

Most AI projects fail, and it’s rarely the technology. The pattern I see repeatedly: teams deploy agents, get excited about initial results, then watch things fall apart over months. The failure isn’t usually the AI itself. It’s organizational. Siloed decision-making. No clear ownership. Agents that automate broken processes instead of reimagining them. If your current workflow is a mess, an AI agent will just create mess faster.

Agents can drift without anyone noticing. Unlike human employees who complain when things aren’t working, agents just keep running. They’ll quietly degrade, produce increasingly irrelevant outputs, or develop blind spots as your business changes around them. Without active monitoring and regular review, you end up with agents that technically work but practically don’t help.

Shadow agents are already in your organization. Teams are deploying AI assistants, connecting them to systems, and using them for work without telling IT, security, or leadership. This isn’t malicious. It’s people trying to be more productive. But it means you have invisible workers making decisions, accessing data, and producing outputs with zero oversight. The solution isn’t to ban experimentation. It’s to channel it into structured pilots with proper governance.

Integration with legacy systems is harder than it looks. That shiny new agent needs to talk to your five-year-old ticketing system, your decade-old ERP, and your custom-built internal tools. Every integration point is a failure point. Every data handoff is an opportunity for things to go wrong. Plan for this. Budget for this. Don’t assume the agent will “just work.”

Costs compound in ways you don’t expect. The API calls, the compute, the storage, the maintenance, the tuning, the monitoring. Running agents at scale isn’t free. Some organizations have been surprised to find their AI “cost savings” evaporating into operational expenses they hadn’t budgeted for. Track the total cost of ownership, not just the initial deployment.

The governance question isn’t optional. Who audits the agent’s decisions? Who checks for bias in its outputs? Who ensures it’s not leaking sensitive data in its prompts? Who handles it when a customer complains about an agent interaction? If you don’t have answers to these questions before deployment, you’re building on sand.

None of this means you shouldn’t deploy agents. It means you should deploy them with eyes open, with proper structure, and with humans who are actually paying attention.

What changes, what doesn’t
#

What changes:

Your org chart now includes non-human workers with defined roles. Planning and capacity discussions include AI capabilities. Job descriptions evolve to focus on judgment, oversight, and collaboration with AI.

New roles are already emerging. Some teams have “agent supervisors” who manage portfolios of AI workers the way a manager oversees human teams. Others have “orchestrators” who design how humans and agents hand off work to each other. The most effective people in these roles aren’t necessarily the deepest technical experts. They’re generalists who understand the business, can spot when an agent is drifting off-course, and know when to override automation with human judgment. The specialists become the exception handlers, the ones who step in when agents encounter situations outside their training.

Hierarchies flatten. When one person can effectively oversee dozens of agents doing work that used to require a large team, you need fewer layers of management. But you need those remaining humans to be much better at systems thinking, quality judgment, and strategic direction.

What doesn’t change:

Humans are still responsible. Every AI action ultimately traces back to a human decision to deploy that AI, configure it a certain way, and keep it running. Quality still matters. AI-generated output isn’t automatically good. It needs review, validation, and continuous improvement. Culture still drives outcomes. An organization that treats AI as a magic fix will get poor results. An organization that thoughtfully integrates AI into its culture will thrive.

Start small, but start now
#

If you haven’t thought about where AI fits in your organization, start.

Pick one agent. Maybe it’s a ticket analysis agent that breaks down new issues and estimates complexity. Maybe it’s a development agent that picks up well-defined tasks and creates working PRs. Maybe it’s a code review agent that checks every PR for security issues and test coverage. Maybe it’s a deployment agent that handles staging releases and runs smoke tests automatically.

Give it a clear scope. Assign a human owner. Define its success metrics. Put it somewhere in your team structure where its role makes sense.

Then watch how it performs. Tune it. Improve it. Learn how to manage it.

The goal isn’t to have AI everywhere immediately. The goal is to develop the organizational muscle for working with AI as part of your team, not just as a tool you occasionally use. The first agent teaches you more about your organization than any planning document could. You’ll discover where your processes are actually unclear, where your data is messier than you thought, and where your team’s comfort with AI-assisted work really stands.

Once the first agent is working well, expand thoughtfully. Not by deploying agents everywhere at once, but by picking the next highest-value, lowest-risk opportunity and applying what you learned. The teams that succeed treat this as continuous capability building, not a one-time transformation project.

The teams that figure this out now will be running hybrid workforces of humans and AI agents, coordinating seamlessly, shipping faster than competitors who are still debating whether to adopt AI at all.

The teams that don’t? They’ll still be running three-month pilots while their competitors deploy their tenth agent.

The bottom line
#

AI agents aren’t tools you use. They’re workers you manage. The sooner you internalize that shift, the sooner you can start building the organizational capabilities to leverage them effectively.

Your org chart is a representation of how you get work done. If AI agents are doing work (and they are, whether you acknowledge it or not), they belong there. Not because they’re human. Because they’re doing jobs that matter, and those jobs need accountability, oversight, and coordination just like any other.

The debate about whether to use AI is over. The teams that recognized this are already operating differently. They’re building hybrid workforces. They’re thinking about agents as team members. They’re developing new management practices for this new reality.

The question isn’t whether this shift is coming. It’s whether you’ll be ready when it arrives at your door, or still debating whether to open it.

Building hybrid teams of humans and AI agents requires intentional organizational design. If you’re wrestling with how to structure this transition for your team, I’m always interested in these conversations.

When AI Writes 90% of Your Code, What Are You Actually Doing?

Fri, 17 Oct 2025 00:00:00 +0000

At the Salesforce Dreamforce conference last week, Anthropic CEO Dario Amodei dropped a number that’s been making waves: “I made this prediction that, you know, in six months, 90% of code would be written by AI models. Some people think that prediction is wrong, but within Anthropic and within a number of companies that we work with, that is absolutely true now.”

Ninety percent. That’s not a demo. That’s how one of the world’s leading AI companies actually builds software today.

The immediate reaction: developers are done, engineering teams will shrink, why hire software engineers when AI can write the code?

But when Salesforce CEO Marc Benioff asked if that means Anthropic needs fewer engineers now, Amodei’s answer was the opposite of what people expect.

The 10% That Actually Matters
#

Amodei was clear: “If Claude is writing 90% of the code, what that means, usually, is, you need just as many software engineers. You might need more, because they can then be more leverage. They can focus on the 10% that’s editing the code or writing the 10% that’s the hardest, or supervising a group of AI models. And so what happens is, you know, you just end up being 10 times more productive.”

Ninety percent AI-written code doesn’t mean fewer developers. It means developers doing fundamentally different work.

This isn’t about replacement. It’s about “rebalancing,” as Amodei put it. The job is changing to focus on what actually requires human judgment.

I’ve been saying this for months, and this statement from someone at the bleeding edge confirms what I’ve been seeing: writing code was never the bottleneck. Understanding what to build, how to architect it, and how to guide AI safely were always the hard parts. AI just made that reality impossible to ignore.

What Does That 10% Actually Include?
#

When AI writes 90% of your code, what are you doing with your time?

You’re making architectural decisions that ripple across the entire system. You’re catching edge cases that AI misses. You’re supervising the AI’s output architecturally. Does this approach scale? Is this secure? Does this follow our patterns? You’re debugging the weird stuff when production behavior doesn’t make sense. You’re making trade-off decisions based on business context, team capabilities, and long-term strategy.

This is what I wrote about in hiring developers in the age of AI: the developers who thrive aren’t the ones who can write code fastest. They’re the ones with systems thinking, architectural reasoning, and problem decomposition skills.

The Productivity Multiplier Nobody Talks About
#

Here’s what gets lost in the “AI will replace developers” narrative: if your developers can be 10 times more productive, you don’t need one-tenth the headcount. You build 10 times as much with the same team.

The companies winning aren’t firing developers. They’re building faster than competitors while others argue about whether AI is good enough. But this only works if your developers can actually operate at that level, with deep systems understanding and architectural thinking.

I wrote about this pattern in what’s holding you back from succeeding in the AI era. The developer I called Marcus shipped 247 commits in a month using AI. Impressive numbers. But when I asked him to explain the architecture of a feature he’d shipped, he couldn’t. Three days later, production incident. He’d implemented decisions he didn’t understand.

Marcus isn’t alone. This is the risk nobody’s talking about when they celebrate AI writing 90% of code.

The Divide Between AI Operators and AI-Augmented Engineers
#

Not all developers are getting 10x more productive with AI. Some are getting 10x faster at shipping code they don’t understand.

The ones succeeding use AI to accelerate work they already know how to do. They recognize when AI suggestions are headed down the wrong path and can evaluate trade-offs without running the code. They’re using AI as a thinking partner for implementation while they focus on design and edge cases.

The ones struggling use AI as a crutch for things they never learned properly. They can ship fast but can’t debug what they shipped because they never built the mental models.

This is what I meant when I wrote about being pro-AI while worried about our next senior engineers. The gap between these two types of developers is widening fast. The scary part? They can have nearly identical output metrics for six months. The difference only becomes obvious when things break.

What This Means for Engineering Teams
#

If Anthropic needs the same number of engineers (or more) even with 90% AI-generated code, what should engineering leaders be doing differently?

Stop optimizing for typing speed. Invest in architectural skills and systems thinking. Create oversight mechanisms that review architectural decisions, not individual lines. Measure production incidents per feature, not commit counts. Develop deep expertise in distributed systems, security, and architecture.

This aligns with what I wrote about AI security being a culture problem. You can have the best AI tools, but if your culture treats “works on my machine” as good enough, you’ll have problems.

The Junior Developer Problem
#

If AI writes 90% of code today, how do junior developers build the expertise to be valuable tomorrow?

The teams doing it right are being extremely intentional. Junior developers don’t just accept AI output. They’re required to explain architectural decisions, walk through how features handle edge cases, and defend trade-offs. They use AI to move faster, but must understand everything they ship.

The teams doing it wrong measure productivity by output volume. Junior developers prompt AI, ship code, move to the next ticket. Fast velocity, zero learning.

Six months from now, the first group will have developers who can architect features independently. The second group will have “AI operators” who panic when AI fails.

What About The Other 10%?
#

Amodei said 90% of code is AI-written “for most teams at Anthropic.” Not all teams. That 10% human-written code isn’t random. It’s the hardest stuff: novel algorithms, performance-critical paths, security-sensitive logic, the architectural foundation everything else builds on.

That 10% is where all the leverage comes from. Get that 10% right, and AI can generate the other 90% reliably. Get it wrong, and you’re building on a broken foundation.

This matches what I’ve seen with developer work not changing, just the sequence. The actual job didn’t disappear. What changed is when those activities happen and how much implementation detail developers handle personally.

The Uncomfortable Truth for Developers
#

If you’re a developer whose primary value was writing clean, working code quickly, you’re in trouble. That skill is being commoditized right now.

If your value is understanding complex systems, architecting for scale, catching subtle bugs, making informed trade-offs, and guiding AI to produce maintainable solutions, you’re more valuable than ever.

The uncomfortable part: many developers thought they were the second type, but were actually the first. AI is exposing that gap brutally.

The good news: these skills can be learned. But you have to be intentional. You won’t build them by accident while prompting AI to generate features.

Rebalancing, Not Replacing
#

Amodei’s point about “rebalancing” is the right frame. The work didn’t disappear. It shifted.

Less time writing boilerplate, more time on architecture. Less time debugging syntax errors, more time designing systems that are debuggable. Less time on mechanical tasks, more time on judgment calls.

This is a better job. More interesting, more impactful, more creative. But only if you have the skills to operate at that level.

What Comes Next
#

I keep coming back to something I wrote in from toys to tools: most developer time isn’t typing, it’s understanding. AI writing 90% of code doesn’t eliminate that understanding requirement. If anything, it makes it more critical.

The winning developers aren’t the ones who resist AI or blindly trust it. They’re the ones who use AI to handle implementation details while they focus on the parts that actually require human judgment.

That’s what Amodei is describing. That’s what I’m seeing in successful teams. And that’s where software development is headed.

The question isn’t whether AI will write most of your code. It already does at leading companies, and the rest will follow within months.

The question is whether you’re building the skills to be valuable in that world. To operate at the architectural level. To guide AI effectively. To catch the edge cases. To make the trade-offs. To be the 10% that makes the 90% possible.

Because that’s the job now.

AI Agents for Real Productivity: What Works in 2025

Thu, 02 Oct 2025 00:00:00 +0000

The promise of AI agents is everywhere: autonomous assistants that handle your busywork, orchestrate complex workflows, and give you back hours of your day. The reality is messier.

Most AI agent demos look impressive until you try to use them for actual work. They either do too little (fancy chatbots with extra steps) or try to do too much (autonomous chaos that breaks things in creative ways).

But between the hype and the disappointment, there’s a middle ground that actually works. AI agents you build yourself, focused on specific problems, constrained by proper guardrails, and integrated into your real workflow.

This isn’t about building the next big AI product. This is about understanding what actually works so you can make smart decisions about where to invest time and resources.

What makes an agent different from a chatbot
#

The terminology is confusing because vendors use “agent” to describe everything from glorified autocomplete to autonomous systems that make irreversible decisions.

Here’s the practical distinction that matters:

A chatbot responds. You ask a question, it answers. The conversation ends. If you want something different, you ask again.

An agent decides and acts. You give it a goal, and it figures out the steps: what information it needs, what tools to use, what order to execute things in. It makes decisions dynamically based on what it learns along the way.

The key difference is agency: the ability to use tools, make decisions, and adapt based on results.

Example: You tell a chatbot “check if our API is healthy.” It might tell you how to check. An agent would actually call your monitoring API, parse the results, identify any issues, check the error logs for those specific issues, and give you a diagnosis.

That’s powerful. It’s also where things get dangerous if you build without thinking through the consequences.

Where agents actually help (and where they don’t)
#

After months of experimenting with agents for real work, I’ve seen clear patterns emerge about what succeeds and what fails.

Agents work well for:

Repetitive information gathering across multiple systems. The kind of task where you need to check five different places, correlate the data, and synthesize an answer. Agents excel at this because they don’t get bored and they’re consistent.

Example: “Analyze the last production incident - check the error logs, look at the related code changes, find similar past incidents, and summarize what happened and why.” That’s four different data sources (logs, Git, incident database, codebase) that need to be queried and connected. An agent handles it in one shot.

Workflow orchestration with clear decision points. Tasks with branching logic that depends on results. If X happens, do Y. If not, do Z. Agents can follow these flows without you manually steering each step.

Example: A code review assistant that checks style, runs security scans, looks for common anti-patterns specific to your codebase, and only escalates to human review if it finds something it can’t handle. The logic is clear, the boundaries are defined.

Data analysis and reporting. When you need to query data, transform it, apply business logic, and generate insights. As long as the queries are read-only and the logic is sound, agents can do this repeatedly without fatigue or errors.

Example: Weekly customer health reports that pull data from your database, your support system, and your usage analytics, then generate a summary with trend analysis and flagged accounts. That’s several hours of manual work that an agent can do in minutes.

Agents struggle with:

Ambiguous goals without clear success criteria. If you can’t define what “done” looks like in concrete terms, the agent will wander. Agents need specific targets.

High-stakes decisions without human oversight. Letting an agent autonomously make decisions that cost money, delete data, or affect customers is asking for trouble. Always put humans in the loop for irreversible actions.

Creative work that requires taste and judgment. Agents can generate options, but they can’t tell you which design feels right, which message resonates with your audience, or which technical trade-off aligns with your product strategy. That’s still your job.

Novel problems they haven’t seen before. Agents work best within known patterns. When they encounter something truly new, they guess, and those guesses can be confidently wrong.

The agent landscape in 2025: what’s actually worth using
#

The market has exploded with agent platforms, frameworks, and tools. Some are genuinely useful. Many are solutions looking for problems. Here’s what matters for builders.

Cloud platforms: fast to start, limited control
#

OpenAI Agents SDK (GitHub) is the easiest path to a working agent if you’re already in the OpenAI ecosystem. The Responses API handles multi-step workflows, and the Agents SDK adds tool calling, file handling, and web search. You can connect it to your systems through MCP (Model Context Protocol).

What’s good: Fast iteration. Strong model quality. Built-in safety controls. Web search and computer use features that let agents interact with browser interfaces.

What’s limited: You’re locked into OpenAI’s infrastructure. Cost control requires discipline. Less flexibility than open-source approaches.

When to use it: Rapid prototyping, proof of concepts, or production systems where convenience matters more than control.

Microsoft’s agent stack spans multiple products: (Azure AI Foundry Agent Service) for managed runtime, (Copilot Studio) for low-code multi-agent orchestration, and Semantic Kernel (GitHub) for custom development.

What’s good: Deep integration with Microsoft 365 and Azure. Enterprise governance and security built in. Computer use for automating legacy systems without APIs.

What’s limited: Complex product surface area. Licensing can get expensive. Best fit if you’re already Microsoft-heavy.

When to use it: You’re a Microsoft shop and need agents integrated with Teams, Office, or Azure services.

AWS Bedrock Agents (docs) with Guardrails for safety, plus the open-source Strands orchestration framework for multi-agent coordination.

What’s good: Scales naturally with AWS infrastructure. Strong security posture. Guardrails for Bedrock give you programmable safety controls.

What’s limited: Setup complexity is higher than other platforms. Service-specific features create lock-in.

When to use it: You’re AWS-first and want agents that integrate tightly with your existing cloud stack.

Google Vertex AI Agent Builder (docs) includes the Agent Development Kit (ADK), Agent Engine for managed runtime, and Memory Bank for stateful conversations.

What’s good: Built-in tools for code execution, search, and data access. Agent-to-agent (A2A) protocol for complex orchestrations. Strong if you’re GCP-native.

What’s limited: Newer than competitors, so some features are still in preview. Best value comes from using it with other Google Cloud services.

When to use it: You’re on GCP and need agents that work naturally with BigQuery, Cloud Storage, and other Google services.

Salesforce Agentforce (announcement) is purpose-built for customer-facing workflows. If your work lives in Salesforce CRM, Sales, or Service Cloud, Agentforce gives you pre-built templates and deep integration.

What’s good: Fast deployment for GTM and customer service use cases. Native to the Salesforce ecosystem. API and mobile SDK for custom development.

What’s limited: Best value comes from using it within Salesforce. Less general-purpose than other platforms.

When to use it: You’re a Salesforce shop and need agents for customer operations, sales workflows, or service automation.

Databricks Agent Bricks (docs) is optimized for data and analytics teams. It’s tightly integrated with Unity Catalog, MLflow, and the lakehouse architecture.

What’s good: Natural fit for data-centric agents. Strong evaluation and serving infrastructure. Enterprise governance built in.

What’s limited: Best suited for organizations already on Databricks. Less general-purpose than other frameworks.

When to use it: You’re building data or analytics agents on a lakehouse architecture.

Open-source frameworks: maximum flexibility, you run the infrastructure
#

LangGraph (GitHub) is the current leader in open-source agent orchestration. It’s built on LangChain but designed specifically for stateful, graph-based agent workflows.

What’s good: True control over behavior. Graph-based execution lets you see and debug agent reasoning. Built-in persistence, retries, and human-in-the-loop patterns. Huge ecosystem of integrations. Works with any LLM.

What’s limited: You manage the infrastructure. Steeper learning curve than managed platforms. You’re responsible for safety and guardrails.

When to use it: You need maximum flexibility, want to avoid vendor lock-in, or have requirements that managed platforms can’t meet.

LlamaIndex (GitHub) focuses on data-centric agents. If your agent needs to work with documents, databases, and complex data sources, LlamaIndex has the deepest RAG (retrieval-augmented generation) tooling.

What’s good: Excellent data connectors. AgentWorkflows for multi-agent patterns. Strong at combining structured and unstructured data.

What’s limited: Narrower focus than general-purpose frameworks. Best suited for data and knowledge work.

When to use it: Your agents primarily work with documents, databases, and knowledge bases.

CrewAI (GitHub) is opinionated about multi-agent teams. You define roles, assign skills, and CrewAI orchestrates collaboration between agents.

What’s good: Simple mental model. Fast growing community. Good for scenarios where you want specialized agents working together.

What’s limited: Less low-level control than LangGraph. Opinionated design means you work within its patterns.

When to use it: You want team-of-agents patterns without building orchestration from scratch.

Haystack (GitHub) from deepset is production-grade RAG plus agents. It’s mature, well-documented, and has clear patterns for evaluation and deployment.

What’s good: Battle-tested in production. Pipeline model is easy to reason about. Good observability and eval integration.

What’s limited: Less flexible than LangGraph for complex agent behaviors. Optimized for RAG-heavy workflows.

When to use it: You need production-ready RAG with agent capabilities, and you value stability over cutting-edge features.

Safety and observability: the unsexy stuff that matters
#

NVIDIA NeMo Guardrails (GitHub) is the most programmable safety layer. It works across different stacks and lets you define explicit policies for what agents can and can’t do.

Why this matters: Agents without guardrails will eventually do something you didn’t intend. NeMo lets you prevent that proactively with code, not hope.

LangSmith (site), Arize Phoenix (GitHub), and Weights & Biases Weave (docs) give you observability into what your agents are actually doing. Trace every step, see every tool call, measure quality and cost.

Why this matters: Agents are black boxes without instrumentation. When something goes wrong (and it will), you need to see exactly what happened. When costs spike, you need to know why.

Making the right choice for your situation
#

The landscape is crowded, but the decision framework is straightforward.

If you’re already invested in a cloud ecosystem:

Go with your cloud provider’s agent platform. The integration is easier, the security model aligns with your existing setup, and you leverage investments you’ve already made.

Microsoft 365/Azure heavy → Microsoft’s agent stack
AWS infrastructure → Bedrock Agents with Guardrails
GCP and BigQuery → Vertex AI Agent Builder
Salesforce for GTM → Agentforce
Databricks lakehouse → Agent Bricks

If you need maximum flexibility and control:

Start with LangGraph. It’s the most mature open-source orchestration framework with the largest ecosystem. Add LlamaIndex for data-intensive work, NeMo Guardrails for safety, and LangSmith for observability.

If you want to move fast with minimal setup:

OpenAI Agents SDK gets you running quickest. Strong defaults, good documentation, integrated tools. Accept the vendor lock-in as the trade-off for speed.

If you’re in a regulated industry or have strict compliance needs:

Microsoft’s agent stack or AWS Bedrock give you the enterprise controls and audit trails you’ll need. NVIDIA NeMo Guardrails works across platforms if you need programmable safety.

What matters more than the platform
#

The platform choice matters less than these fundamentals:

Clear problem definition. Vague goals produce vague results. Agents need specific, measurable success criteria.

Proper guardrails from day one. Safety isn’t something you add later. Build it in from the start.

Observability and measurement. You can’t improve what you can’t see. Instrument everything.

Realistic expectations. Agents augment human judgment, they don’t replace it. The best results come from thoughtful human-agent collaboration.

Iterative refinement. Your first agent won’t be great. That’s fine. Build, test, learn, improve.

For engineering leaders: the strategic opportunity
#

If you lead a team or organization, AI agents represent more than a productivity tool. They’re a forcing function for operational clarity.

The immediate play: Teams with well-designed agents handle more work with the same headcount, or maintain output with less burnout. The productivity gains are real and measurable.

The deeper value: Building agents forces you to clarify processes, document decisions, and standardize workflows. That organizational clarity compounds beyond just the agents themselves.

The investment thesis: Start small with focused agents solving specific problems. Build expertise through real use. Expand as you learn what works in your specific context.

The approach that works: Don’t mandate top-down. Let teams build agents for their own pain points. Provide infrastructure, guidelines, and shared learnings. The best agents emerge from people solving their own problems.

The risks to watch: Agents without guardrails. Agents without observability. Agents that automate broken processes. Teams that become dependent without understanding the underlying work.

The goal: Leveraged productivity, not maximum automation. Free your team from repetitive cognitive work so they can focus on problems requiring judgment, creativity, and expertise.

For developers: why this matters to your career
#

Building agents isn’t specialist knowledge. It’s becoming table stakes for productive developers.

The skill combination that’s valuable: Understanding both AI capabilities and production systems. How to give AI the right context without compromising security. How to design integrations that teams actually use.

What’s valuable right now:

Using existing agent frameworks effectively
Building focused agents for specific workflows
Implementing proper security and guardrails
Designing integrations that scale

What becomes more valuable:

Deep expertise in agent orchestration patterns
Domain-specific integration knowledge
Platform-level thinking about AI-system connections
Security and compliance for AI integrations

The trajectory: Developers who can build reliable agents that solve real problems are differentiating themselves. Not because it’s exotic, but because it’s practical infrastructure work that delivers measurable value.

What separates success from expensive failure
#

Most AI agent projects fail. Not because the technology isn’t ready, but because teams skip fundamentals.

They build before understanding the problem. They automate before adding guardrails. They deploy before instrumenting. They scale before validating.

The agents that work share common traits:

Focused on specific, well-defined problems
Built with clear boundaries and safety controls
Instrumented from day one with proper observability
Validated with real use before broad deployment
Maintained and improved based on actual usage patterns

The discipline required is higher than traditional development. Agents make autonomous decisions. Mistakes compound. Poor judgment scales. You need to be more thoughtful, not less.

But when done right, the leverage is real. Work that took hours happens in minutes. Repetitive cognitive tasks disappear. Context gathering becomes automatic. Teams handle more complexity with less stress.

Where to start
#

Understanding the landscape is step one. Building something real is step two.

In my next article, I’ll walk through the practical steps: picking the right first problem, setting up your tools, building a working agent in a week, and deploying it to your team. The tactical guide to actually shipping.

For now, the strategic takeaway is clear: AI agents work when they’re focused, bounded, and built for specific workflows. The platform matters less than the approach.

The teams winning with agents aren’t the ones with the best strategy. They’re the ones who started experimenting months ago and never stopped learning.

Start small. Build focused. Measure ruthlessly. The productivity gains compound faster than you’d expect.

Key resources:

LangGraph documentation for open-source agent orchestration
OpenAI Agents SDK for managed agent development
Microsoft Semantic Kernel for multi-language agent development
NVIDIA NeMo Guardrails for cross-platform safety controls
LangSmith for agent observability and debugging

The gap between AI agent demos and actual productivity is understanding what works and what doesn’t. Then building accordingly.

What's Holding You Back from Succeeding in the AI Era?

Wed, 01 Oct 2025 00:00:00 +0000

I’ve been experimenting with AI in development teams. Some experiments have gone well. Developers shipping faster, workflows getting streamlined, genuine productivity gains. Others… not so much. I’m still figuring this out, honestly, but I keep running into patterns that concern me.

Last week, something happened that crystallized these concerns.

A developer I know (let’s call him Marcus) was excited to show me his GitHub stats. Impressive numbers: 247 commits in a month, 23 features shipped, velocity charts trending up. His manager was thrilled. Out of curiosity, I asked him to walk me through the architecture of a feature he’d shipped recently. Simple question: “Why did you structure the caching layer this way?”

He paused. Then admitted he wasn’t sure. The AI had suggested it. It worked. He shipped it. Three days later, that feature caused a production incident. Forty minutes of downtime. Significant revenue impact. All because he’d implemented architecture decisions he didn’t fully understand.

Marcus isn’t failing because AI isn’t good enough. He’s failing because he’s gotten really good at using AI without building the judgment to evaluate what it produces.

This got me thinking about something I’m noticing more often. Not that AI will replace developers (I don’t think that’s the real risk), but that we might be accidentally creating developers who move fast but think shallow, and managers who confuse speed with capability. The numbers are striking: by 2028, 90% of enterprise software engineers will likely be using AI code assistants, up from less than 14% in early 2024. Yet 77% of engineering leaders see integrating AI as a major challenge.

Maybe the issue isn’t AI itself. Maybe it’s that AI amplifies whatever approach you already have. If you think deeply about problems, AI helps you think faster. If you don’t… well, AI helps you not-think faster too.

I’m starting to see a pattern in how this plays out, and I think it’s worth sharing what I’ve noticed.

The Great Divide: Marcus vs. Sarah
#

We’re accidentally creating a divide. Not between people who use AI and people who don’t, but between those who let AI carry them and those who use it to leap forward.

Marcus represents the first group. There’s another developer I’ll call Sarah who seems to represent the second. Same company, similar experience level, both use AI heavily. But when I asked Sarah the same architecture question, she didn’t just answer. She walked me through her reasoning: the trade-offs she’d considered, why she’d rejected the AI’s first two suggestions (one would have created a memory leak under load, the other couldn’t scale horizontally), what she’d validated before shipping, and what monitoring she’d added because she knew this approach had specific failure modes under network latency.

Sarah’s velocity? Nearly identical to Marcus’s. But Sarah’s code doesn’t cause incidents. When it does break (because all code eventually breaks) she diagnoses it in minutes, not hours. She’s using AI to move faster, but her understanding of systems architecture is actually deepening. She treats AI as a thinking partner that suggests solutions, which she then stress-tests against her mental model of how distributed systems behave.

The difference between them isn’t talent. It’s approach. Marcus accepts AI suggestions that look good on the surface. Sarah interrogates them. Marcus ships fast. Sarah ships right. Marcus is becoming dependent. Sarah is becoming more capable.

And here’s what makes this dangerous: for the first six months, they look identical on paper. Same velocity, same feature throughput, same commit frequency. The difference only emerges when systems hit scale, when architectural decisions made months ago come home to roost. By then, Marcus has shipped dozens of features built on shaky foundations, and the technical debt is crushing.

The Self-Deception Patterns
#

Beyond the Marcus/Sarah divide, I’m noticing three patterns that seem to lead to struggles:

The Resisters refuse to engage with AI at all. I know a brilliant engineer who was convinced Copilot would “rot their brain.” Six months later, they were frustrated and behind, trying to catch up with tools they didn’t understand while everyone else had already learned to use them thoughtfully.

The Checkbox Adopters use AI just enough to say they’re using it. They’ll accept a Copilot suggestion here and there, maybe prompt ChatGPT when really stuck, but fundamentally they’re doing things the old way with a thin veneer of AI adoption. They think this is a safe middle ground. It’s actually the worst of both worlds. They’re not building deep AI collaboration skills because they’re not truly engaging. And they’re not building deep foundational skills because they’re using AI as a crutch for the things they don’t want to learn properly.

Meanwhile, the AI world makes huge leaps forward monthly. Not yearly. Monthly. If you learned Copilot in 2023 and called it done, you’re falling behind while convincing yourself you’re staying current. The gap between you and people actively learning these tools isn’t just widening. It’s compounding like interest you can’t afford.

The Manager’s Blind Spot might be the most concerning. I’m hearing more managers wonder if they still need developers at all. AI can write code, ship features, fix bugs. Why keep investing in expensive engineering talent when AI does it faster and cheaper?

I think this is a dangerous miscalculation. They do still need developers. Desperately. But they need a fundamentally different kind. They need developers who can see the whole picture, who can challenge AI when it’s wrong, who understand both the product vision and the code architecture deeply enough to orchestrate AI effectively.

From Privates to Generals
#

Think about it this way: if AI can write the code, you don’t need code writers anymore. You need generals who can command an AI army.

I mean this literally. In military terms, a private follows orders and executes tasks. A general orchestrates entire campaigns: seeing the terrain, understanding the objective, marshaling resources, adapting to changing conditions, and making strategic decisions that ripple across the entire operation.

That’s what developers need to become. Someone who can define the business problem, set architectural constraints, establish quality bars, plan rollout strategy, and then marshal multiple AI tools to execute on that vision while maintaining coherence across the system. Someone who spots when the AI is headed down the wrong path, not because they read every line of generated code, but because they understand the system deeply enough to catch the architectural smell.

The private-to-general shift isn’t about seniority. It’s about thinking level. I’ve seen 25-year-old developers who think like generals and 45-year-old senior engineers who still think like privates. The generals understand systems, trade-offs, second-order effects. The privates understand syntax.

Most managers are still hiring and evaluating for privates while wondering why their team can’t handle complexity. They’re measuring lines of code, tickets closed, features shipped (all private-level metrics). They should be measuring systems thinking, architectural coherence, the ability to spot when AI suggestions don’t fit the bigger picture, and the judgment to maintain quality at AI-augmented speed.

The Invisible Barriers
#

From what I’ve observed working with teams going through this transition, there seem to be five core barriers:

The Fundamentals Gap: I’ve interviewed developers who learned to code entirely in the AI era. They’ve never written a hundred lines without Copilot running. They can ship features fast, but they can’t debug when the AI steers them wrong because they’re missing the mental models that tell you when something smells off. It’s like someone who learned to navigate exclusively with GPS suddenly needing to read a map and orient themselves by landmarks. The skill atrophied before it fully developed.

The Management Gap: When AI handles syntax, what remains is collaboration, problem decomposition, and creative solutions to ambiguous problems. But many engineering managers rose through the ranks by being excellent individual contributors. They know how to review a pull request, but not how to review someone’s AI collaboration process. They can spot a memory leak, but they can’t spot a team that’s becoming dependent on tools that mask their fundamental skill gaps.

The Ethics and Security Blind Spot: Bias in AI-generated code isn’t just a headline. I’ve heard about recommendation algorithms that worked perfectly in testing but systematically disadvantaged certain user groups in production because the training data was skewed. Data privacy leaks happen when someone prompts ChatGPT with actual customer data to debug an issue, and suddenly proprietary information is in OpenAI’s training corpus. These risks are real and can be project killers.

The Burnout Nobody Saw Coming: I know a developer (call him Jason) who went from energized to exhausted in several months of heavy AI use. He wasn’t working more hours. But the cognitive load was crushing him. Before AI, natural breaks were built into his workflow: write code, get stuck, think through the problem, research solutions. With AI, the suggestions come instantly. The code appears. The tests pass. The features ship. There’s no natural stopping point. Jason told me: “I used to finish a feature and feel done. Now I finish a feature and immediately have three AI-generated options for the next one waiting for review. I’m not coding more, but I’m deciding constantly. My brain never gets to rest.” The pressure isn’t about hours anymore. It’s about attention.

The Skill Gap: AI won’t make engineers obsolete. It’ll automate the repetitive work and free you for complex problem-solving. But only if you develop those complex problem-solving skills. If you spend all your time prompting and none of your time learning fundamentals, you’re not building a career. You’re becoming an AI operator. And when the AI gets better, what value do you bring?

What Works for Managers
#

If you lead a team or a group, you’re in the position to shape how AI gets adopted. But first, get honest with yourself about what you actually need. You don’t need a team that can write code faster. You need a team of AI generals.

Here’s what seems to be working from what I’ve observed:

Institute AI literacy training, but make it real. I suggest to a team to try “fundamentals Fridays.” For two hours every Friday afternoon, no AI tools. Period. They work through algorithm problems from scratch, debug performance issues with just a profiler and their understanding of systems, and review code the old-fashioned way. The first few weeks, developers hated it. Three months in, something shifted. They started catching subtle bugs in AI-generated code they would have missed before. They became the team’s quality gatekeepers, not because they rejected AI, but because they could evaluate it critically. Meanwhile, I know about teams that went all-in on AI without fundamentals training having much higher incident rates and senior engineer burnout.

Set KPIs around quality, not just speed. Track code review depth. Measure incident resolution time and root cause quality. Monitor technical debt accumulation. If you only measure velocity, you’ll get velocity at the cost of everything else that matters.

Prioritize soft skills development. Run exercises where developers explain AI outputs in plain English to non-technical stakeholders. If they can’t explain why the AI suggested an approach, they probably shouldn’t ship it.

Implement ethical guidelines before you need them. Create clear policies for AI use: what data can go into prompts, what outputs require human review, how to audit for bias, what the security boundaries are. We want those teams that are avoiding serious incidents not because they got lucky, but because they’ve thought through the risks ahead of time.

Promote work-life balance aggressively. Enforce no-AI-after-hours rules if you need to. Set clear boundaries to prevent the 24/7 treadmill. Burnout destroys teams slowly, then all at once.

Invest in upskilling with real budget and real time. McKinsey’s research highlights that AI accelerates innovation in software development, but only with skilled teams. Make continuous learning part of the job, not something people do on weekends.

What Works for Developers
#

If you’re a developer, you have more control over your trajectory than you might think. Don’t wait for your company to figure this out. Take ownership of your growth.

Master the fundamentals alongside the tools. Spend time every week coding without AI. Implement algorithms from scratch. Debug performance issues using only profiling tools and your understanding of systems. This feels inefficient in the moment. You could ship faster with Copilot. But this is the time investment that makes you valuable. When you’re the person in the room who can debug the AI’s output, who can spot architectural problems before they ship, who can make trade-offs that the model can’t understand, that’s when you become indispensable.

Stay actively current, not passively aware. The AI landscape moves at a pace I’ve never seen before in my career. What’s cutting-edge this month is table stakes next month. One way to stay up to date is to follow me - I regularly share insights about new AI developments and how they impact software development. Beyond that, learn one new AI-related skill or tool every month, minimum. Not just surface-level “I tried it once.” Actually integrate it into your workflow and understand its strengths and limitations. Read about what’s working in production. Try new models when they drop. Understand what changes when context windows expand from 200K to 1M tokens. Stop lying to yourself that minimal engagement is enough. The gap is widening monthly.

Hone your soft skills deliberately. This isn’t fluffy advice. It’s career-critical. Join every code review you can. Present your work to the team regularly. Practice explaining technical decisions to non-technical people. Work on your writing. Clear documentation is a superpower in an AI-augmented world. AI can’t replace your storytelling. It can’t replicate your ability to build consensus, to read the room, to know when to push an idea and when to let it go.

Stay ethical and secure by default. Always validate AI outputs for bias and security implications. Make it a habit. Study real cases of AI projects that failed, not to be scared, but to learn the patterns of what goes wrong. When you’re prompting, be paranoid about what data you’re including.

Manage your time and energy like the finite resources they are. Track your productivity not just in features shipped, but in energy levels and work satisfaction. When you notice the treadmill speeding up, push back. The fastest way to stall your career is to burn out and need many months to recover.

The Uncomfortable Truth About What Comes Next
#

Remember Marcus and Sarah from the beginning? Same tools, same company, similar experience. One caused a six-figure production incident. The other is becoming a more capable engineer every week.

The gap between them isn’t widening linearly. It’s widening exponentially.

One year from now, Marcus will be even more dependent on AI because that’s the only way he knows how to work. When the AI fails (and it will, because all tools fail) he’ll be stuck. When his manager finally realizes he’s been shipping fast but shallow, his career trajectory will have already calcified.

Sarah will be leading architecture discussions. She’ll be mentoring other developers on how to use AI effectively. She’ll be the person who gets pulled into critical incidents because she can diagnose systemic problems, not just fix symptoms. She’ll be positioned for the next level of responsibility because she’s demonstrated judgment, not just velocity.

The market is already splitting, and it’s splitting fast. There are developers who think deeply, paired with AI that moves fast. There are managers who lead boldly, building teams that thrive because of AI, not despite it. These people are pulling ahead at a pace that would have seemed impossible five years ago. They’re not working longer hours. They’re working with deeper understanding and sharper judgment.

Then there are people getting left behind, not because they’re not using AI, but because they’re using it wrong. They’re over-relying without building foundations. They’re resisting out of fear. They’re engaging halfway and calling it done. They look productive today, but they’re accumulating a debt (technical, intellectual, professional) that will come due in ways they don’t yet understand.

McKinsey’s 2025 outlook shows that AI’s impact grows when combined with human ingenuity, not when it replaces it. The differentiator isn’t whether you use AI. By 2028, everyone will. The differentiator is whether you use it as a boost or a crutch. Whether you’re becoming more capable or more dependent. Whether you’re building judgment or eroding it.

Your Move
#

Marcus can still become Sarah. Sarah could still become Marcus if she gets lazy. The trajectory isn’t fixed, but it’s compounding, and the gap widens every month.

If you’re a manager: Your job right now is to build teams of generals, not privates. That means investing in skills deliberately, setting boundaries aggressively, creating psychological safety for experimentation, and holding quality bars even when it’s easier to ship fast and sloppy. It means measuring the right things: systems thinking, architectural coherence, AI collaboration effectiveness, judgment under pressure.

If you’re a developer: Your job is to become someone who elevates AI, not someone who’s elevated by it. That means mastering fundamentals while learning tools. Staying actively current, not passively aware. Building soft skills that AI can’t replicate. Maintaining the judgment that separates generals from privates. Treating AI as a thinking partner, not an autopilot.

The AI era isn’t about surviving. It’s about succeeding. The people who succeed will be the ones who overcome these barriers deliberately, who build both their AI collaboration skills and their independent judgment in parallel, who understand that velocity without understanding is just speed toward the cliff.

Six months from now, you’ll either be further ahead or further behind than you are today. The compounding has already started. The question isn’t whether the AI era is here. It’s whether you’ll be one of the people who define it or one of the people left wondering what happened.

So here’s my question for you: Which path are you choosing today?

Not tomorrow. Not when you have more time. Not when things settle down. Today.

What’s your first step?

The gap between teams that successfully navigate the AI transition and those that struggle often comes down to intentional strategy around skill development and quality standards. If you’re wrestling with how to build AI-augmented teams that maintain deep engineering capability, I’m always up for a conversation.

Model Context Protocol: The Missing Connection Between AI and Your Real Work

Tue, 30 Sep 2025 00:00:00 +0000

Your AI coding assistant can write impressive code. But it can’t read your company’s database schema, your internal documentation, or your production logs. It doesn’t know your team’s conventions, your deployment workflows, or why that weird workaround exists in the payment service.

This is the context gap. And it’s why AI tools feel powerful in demos but limited in real work.

The Model Context Protocol (MCP) is changing that. Not with better models or smarter prompts, but by standardizing how AI connects to the actual systems where your work lives.

Here’s what you need to know, what you can do today, and why this matters more than most AI announcements.

The problem MCP solves
#

AI assistants live in a bubble. They see what you show them: the current file, maybe the conversation history, perhaps a few documentation snippets you paste in.

What they don’t see:

Your database tables and relationships
Your API schemas and internal services
Your Git history and commit patterns
Your company’s documentation and decision records
Your production metrics and error logs
Your team’s code conventions and architectural patterns

Every time you switch contexts, you’re starting over. The AI has to relearn. You spend time explaining things it should already know.

The traditional solution: Build custom integrations. Write a plugin that connects Claude to your database. Write another for ChatGPT. Another for Cursor. Maintain them all as things change.

This doesn’t scale. Three AI tools, five data sources, fifteen custom integrations. Then a new AI tool launches and you start over.

MCP solves this by standardizing the connection layer. Build once, use everywhere.

What MCP actually does
#

MCP is an open protocol that lets AI applications connect to three types of capabilities:

1. Resources (what AI can read)

Your databases, files, documentation, APIs. Anything that provides context the AI needs to understand your work.

Example: Your database exposes its schema as an MCP resource. Now Claude can see your table structure without you pasting it into the chat.

2. Tools (what AI can do)

Search operations, API calls, data queries, workflow triggers. Actions the AI can take on your behalf.

Example: A search tool lets the AI query your documentation. A database tool lets it run read-only queries. A Git tool lets it analyze commit history.

3. Prompts (how AI should think)

Templated workflows for specific tasks. Structured ways to guide AI behavior for your team’s common patterns.

Example: A code review prompt that includes your team’s specific conventions. An incident analysis prompt that knows your logging structure.

Understanding the architecture (if you’ve built APIs, you’ll get this)
#

If you’ve worked with REST APIs, MCP will feel familiar. It’s the same pattern applied to AI integrations.

REST API thinking:

Server exposes endpoints (GET /users, POST /orders)
Client makes requests to those endpoints
Standard protocol (HTTP) means any client can talk to any server
Authentication and authorization control access

MCP thinking:

Server exposes resources, tools, and prompts
Client (AI application) discovers and uses those capabilities
Standard protocol (JSON-RPC) means any MCP client can talk to any MCP server
Host (container for the AI) enforces permissions and approval

The three-layer architecture
#

1. Server (your systems)

The MCP server wraps your existing systems and exposes them through a standard interface. This is like building a REST API for your database, except instead of HTTP endpoints, you’re exposing MCP resources and tools.

Example: Your PostgreSQL database gets an MCP server that exposes:

Resources: schema definitions, table structures
Tools: query execution (read-only to start)
Prompts: common analysis patterns your team uses

2. Client (the connection layer)

The MCP client sits between the AI and the servers. It discovers what’s available, routes requests, and handles responses. Think of it like an API gateway, but for AI integrations.

The client handles:

Connection management to multiple servers
Capability negotiation (what does this server support?)
Message routing and response handling
Security boundaries enforcement

3. Host (the orchestrator)

The host is the container that manages everything. It controls which servers the AI can access, enforces approval flows for sensitive operations, and mediates access to the AI model itself.

This is the security and policy layer. Even if a server offers dangerous tools, the host can require explicit user approval before the AI can invoke them.

How it compares to other integration patterns
#

Like REST APIs:

Standard protocol that anyone can implement
Server/client architecture with clear separation
Discoverability (list available endpoints/resources)
Stateless individual operations, stateful sessions

Like GraphQL:

Clients can discover the schema (what’s available)
Type-safe interactions with JSON Schema validation
Flexible queries for exactly what you need

Like OAuth:

Explicit permission and consent flows
Scoped access to resources
User remains in control of what AI can access

Unlike traditional APIs:

Bidirectional communication (servers can request things from clients)
Built-in support for streaming responses
Designed specifically for AI-to-system integration
Security model assumes untrusted AI behavior

The transport layer (how data moves)
#

MCP uses two primary transports:

stdio (standard input/output): For local processes. The MCP server runs on your machine, communicates through stdin/stdout. Simplest and most secure for desktop applications. This is how Claude Desktop connects to local servers.

Streamable HTTP: For remote servers. JSON-RPC over HTTP with server-sent events for streaming. Use this when you need team-wide access to a server or want to deploy servers in the cloud.

Why this matters: Start with stdio (local, simple, secure). Move to HTTP when you need remote access or horizontal scaling.

The protocol is simple (intentionally)
#

MCP uses JSON-RPC 2.0. If you’ve worked with JSON APIs, the message format will look familiar:

{
 "jsonrpc": "2.0",
 "method": "resources/list",
 "id": 1
}

The simplicity is deliberate. Easy to implement, easy to debug, easy to extend.

Why this architecture works
#

Separation of concerns: Servers don’t need to know about AI models. AI applications don’t need to know about your database internals. The protocol is the contract between them.

Composability: One AI application can connect to multiple servers. One server can serve multiple clients. Mix and match based on needs.

Security boundaries: Servers are isolated from each other. The host enforces what the AI can access. Sensitive operations require explicit approval.

Ecosystem effects: When everyone builds to the same protocol, servers become reusable assets. Your PostgreSQL MCP server works with Claude, ChatGPT, and Gemini. Build once, benefit everywhere.

How to start using MCP today
#

This is the important part. You don’t need to build MCP servers to benefit from MCP. Start by using what exists.

Step 1: Install an MCP-compatible client
#

Claude Desktop is the easiest starting point. Download it, and you already have an MCP client ready to go.

Cursor supports MCP through Claude Desktop integration. If you’re using Cursor for coding, this path makes sense.

Other options: Zed, Windsurf, and Sourcegraph Cody all support MCP. Pick the tool you already use.

Step 2: Add your first MCP server
#

Start simple. The filesystem server lets Claude read your local files.

What this gives you: Instead of copying and pasting code into Claude, you can say “read the authentication module and suggest improvements.” Claude accesses the file directly, sees the full context, and gives better answers.

Five minute setup:

Install the filesystem MCP server
Configure Claude Desktop to use it
Point it at your project directory
Now Claude can read your actual codebase

Step 3: Connect to your databases
#

The PostgreSQL MCP server (and similar for other databases) exposes your schema and enables read-only queries.

What this changes: You can ask “show me all users who signed up in the last week but haven’t completed onboarding” and Claude queries your database directly. No copy-paste, no context switching.

The right way to do this: Start with read-only access. Use environment variables for credentials. Test on development databases first.

Step 4: Add Git context
#

The Git MCP server exposes repository history, branches, and diffs.

What becomes possible: “Analyze the last ten commits to the payment service and summarize what changed.” Claude reads the actual Git log and gives you a coherent summary.

Step 5: Connect to your tools
#

Existing MCP servers cover Google Drive, Slack, GitHub, Postgres, and more. The MCP Registry (in preview) is where you find community servers.

Pick what matters to your workflow. Documentation? Customer data? Production metrics? Connect the systems where your context lives.

What changes when AI has real context
#

This isn’t just convenience. It’s a fundamental shift in how you work with AI.

From manual context to automatic context
#

Before: You spend five minutes explaining your database structure, pasting schema definitions, copying relevant code into the chat.

After: Claude already sees your schema. You skip straight to the actual question.

The compounding effect: Over dozens of interactions per day, you save hours of context-gathering work.

From shallow answers to deep understanding
#

Before: AI suggests generic solutions because it doesn’t know your actual constraints and patterns.

After: AI sees how your team actually structures code, what conventions you follow, what trade-offs you’ve made. Suggestions are specific to your reality.

The quality shift: Fewer “that won’t work here” moments. More “that actually fits our architecture.”

From single-turn to multi-step workflows
#

Before: Every task is a new conversation. AI has no memory of what you’re working on or why.

After: AI can follow multi-step workflows that span files, systems, and contexts. It remembers the goal and carries it forward.

Example: “Analyze the performance metrics for the API, identify the slow endpoints, check the database queries for those endpoints, and suggest optimizations based on our actual schema.”

That’s four different context sources (metrics, API code, database, schema) orchestrated into one coherent workflow.

When to start building your own MCP servers
#

Once you’ve used MCP and see the value, you’ll spot the gaps. Systems specific to your company. Internal tools that don’t have public MCP servers. Workflows unique to your team.

That’s when you build.

The right first server to build
#

Your internal documentation. If you have Confluence, Notion, or internal wikis, an MCP server that exposes them as resources solves an immediate problem.

What it enables: Developers can ask AI questions about your internal systems and get answers sourced from your actual docs. No more hunting through wiki pages.

Technical complexity: Low. Resources are read-only, security is straightforward, and the value is immediate.

The second server: your APIs
#

Expose your internal API schemas and enable AI to understand how services connect.

What becomes possible: “Show me how to call the user service to update preferences” gets a response based on your actual API, not generic examples.

The integration pattern: Start with read-only schema exposure. Add safe test operations. Never expose production-write operations without explicit approval flows.

Building with the official SDKs
#

Official SDKs exist for TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift. Pick your stack and start.

The architecture is simple:

Expose resources through resources/list and resources/read
Declare tools through tools/list and handle calls through tools/call
Define prompts that guide AI behavior for your specific use cases

Use the MCP Inspector to test your server. Connect to it, browse resources, invoke tools, see what the AI sees. Essential for debugging.

Security patterns that matter
#

1. Start local, go remote carefully

Local servers (stdio transport) are simpler and more secure. They run on the developer’s machine with their permissions.

Remote servers (HTTP transport) enable team-wide access but require proper authentication, authorization, and audit logging.

2. Read-only first, mutations later

Resources are safe. Tools that modify data are not. Start with exposure, add write operations only when you have proper approval flows.

3. Never trust inputs

Validate everything. Use JSON Schema for tool parameters. Sanitize inputs. Assume the AI might be tricked into sending malicious requests.

4. Handle credentials properly

Environment variables for development. OS keychains for local desktop apps. Proper secret management for remote servers. Never in code, never in logs.

Why OpenAI and Google adopted this so fast
#

MCP launched in November 2024 from Anthropic. By March 2025, OpenAI adopted it. By April, Google announced support.

When competing AI companies agree on a standard in months, not years, pay attention.

The reason: Everyone faces the same integration problem. Claude needs to connect to databases. ChatGPT needs to connect to databases. Gemini needs to connect to databases.

The old approach: Build custom connectors for each AI tool and each data source. Multiplication of effort.

The MCP approach: Build one server that exposes your database through a standard protocol. Every MCP-compatible AI tool can use it immediately.

The ecosystem effect: As more tools adopt MCP, every MCP server you build becomes more valuable. As more servers exist, every AI tool that adopts MCP becomes more useful.

This is infrastructure-level network effects.

What this enables that wasn’t possible before
#

The real shift isn’t about making current work easier. It’s about making new patterns possible.

Contextual code review
#

AI that reviews code with full access to:

Your architecture decision records
Previous similar changes and their outcomes
Production metrics for affected services
Team conventions and style guides

This isn’t generic linting. It’s review that understands your actual system and suggests improvements based on what you’ve learned, not what’s theoretically best.

Predictive debugging
#

When an error occurs, AI with MCP access can:

Read the error logs from your monitoring system
Analyze the relevant code with full repository context
Check similar past incidents and their resolutions
Query the database state at the time of the error
Suggest fixes based on your actual patterns

From hours to minutes. The context gathering that used to take most of the debugging time happens automatically.

Architectural coherence
#

AI that can enforce architectural patterns by:

Seeing your actual service boundaries and dependencies
Understanding the intent behind your design decisions
Catching violations as they’re written, not in review
Suggesting alternatives that fit your established patterns

This moves from reactive to proactive. Instead of fixing architectural drift, you prevent it.

Knowledge continuity
#

When a developer leaves or moves teams, their context doesn’t disappear if it’s encoded in MCP servers. The AI has the same access to systems, docs, and patterns.

Onboarding acceleration: New developers get answers sourced from actual systems, not just wikis that might be outdated.

For managers: the strategic opportunity
#

If you’re leading a team or organization, MCP represents more than a technical standard. It’s a forcing function for better infrastructure.

The immediate productivity play
#

Week 1: Install Claude Desktop for your team. Add filesystem and Git MCP servers. Developers can now ask AI about your actual codebase.

Week 2-4: Add database MCP servers (read-only, development instances). Connect to internal documentation.

Month 2: Measure time saved on context gathering, debugging, and code review.

The ROI is quick and measurable. Developers spend less time hunting for context and more time solving problems.

The platform investment
#

MCP forces you to think about your systems as APIs. What should be exposed? What’s the right level of abstraction? What are the security boundaries?

This work pays dividends beyond AI. Better-defined interfaces, clearer boundaries, improved documentation. You get organizational clarity whether or not MCP becomes the dominant standard.

The competitive positioning
#

AI adoption is uneven across teams. The constraint isn’t model quality, it’s integration with real work.

Teams with good MCP infrastructure can use AI effectively. Teams without it are stuck with generic, context-free interactions.

This creates meaningful differentiation in productivity, quality, and velocity.

The talent development angle
#

Engineers who understand how to build, secure, and scale MCP integrations are developing valuable skills.

This is infrastructure-level knowledge that transfers across companies. It’s not framework-specific or company-specific. It’s fundamental to how AI connects to systems.

Investing in team education here compounds. These skills become more valuable as the ecosystem matures.

The broader pattern: context is infrastructure
#

MCP is part of a larger shift. AI isn’t just about better models. It’s about better connections between models and the systems where work happens.

We’re moving from:

Isolated AI interactions to connected workflows
Generic suggestions to context-specific guidance
Manual context gathering to automatic context access
Single-turn conversations to multi-step orchestration

This is the infrastructure layer for AI-native development. Just like REST APIs became infrastructure for web services, MCP is becoming infrastructure for AI integration.

The companies and teams that recognize this early and build the right connective tissue will have a sustained advantage.

What comes next
#

Near-term (Q4 2025):

MCP 1.0 spec release (November 25, 2025)
Wider IDE integration as standard feature
Improved tooling for building and testing servers
Enterprise adoption at scale

Medium-term (2026):

MCP becomes expected, not optional
Security and compliance frameworks mature
Performance optimizations and caching patterns
Vertical-specific server ecosystems emerge

Long-term trend: AI context shifts from “what you paste in the chat” to “what the AI has access to through proper integrations.”

The quality of AI assistance becomes proportional to the quality of your MCP infrastructure.

For developers: the career angle
#

What’s valuable right now:

Understanding how to use existing MCP servers effectively
Building servers for gaps in your team’s workflow
Implementing security patterns correctly
Designing integrations that scale

What becomes valuable:

Deep expertise in MCP architecture and best practices
Domain-specific integration knowledge (healthcare, finance, etc.)
Platform-level thinking about how AI connects to systems
Security and compliance for AI integrations

The skill combination that matters: Understanding both AI capabilities and production systems. How to give AI the right context without compromising security. How to design integrations that teams actually use.

This is infrastructure work. It’s less flashy than training models but more durable and more broadly applicable.

Start now, build as you go
#

If you’re a developer:

Install Claude Desktop this week
Add filesystem and Git servers to your workflow
Notice where you still need to manually provide context
Build MCP servers for those gaps
Share what you build with your team

If you’re a manager:

Set up MCP infrastructure for your team this month
Measure time saved on context gathering
Identify team-specific systems that need servers
Invest in building those integrations
Make MCP literacy part of onboarding

The best time to start was six months ago when MCP launched. The second best time is today.

The teams that move now will have compound advantages as the ecosystem matures. Not because they predicted the future, but because they built the infrastructure that makes AI actually useful for real work.

Get started:

The gap between AI demos and AI productivity is context. MCP is how you close it.

Developer Work Did Not Change. The Sequence Did.

Sat, 27 Sep 2025 00:00:00 +0000

On most teams, productivity hits a weird ceiling. New tools make us faster, then we bottleneck on context, reviews, and decision time. The blocker is rarely typing speed. It’s waiting for the right information to show up.

AI doesn’t make the job different. It changes when parts of the job happen. The moment a ticket is clear enough for a human, it can be clear enough for a model that knows your repo. That single shift moves context earlier. It turns Monday morning from archaeology into editing.

This is a perspective on helping teams find ways to build more while staying balanced. Not a prescriptive guide, just an approach that’s proven effective in practice.

The bottleneck is us, not the tools
#

Two-week sprints, estimates, planning, PRs, CI, retro. These rituals mostly work. The problem is their timing. Context arrives late, so developers spend the first hour of every ticket just getting oriented. Models help most when they create good starting points before we start.

A small, useful shift
#

When a ticket is truly ready, it should be ready for both a person and a model. Ready means: goal, relevant paths in the repo, constraints, acceptance examples. With that, you can ask a model for four things:

A change outline - what needs to touch what
A thin scaffold - something that compiles and runs
Tests that fail for the right reasons - executable specifications
A short risk list - what could break

You wake up to a draft you can run and critique. The first hour becomes review and naming, not searching and guessing.

What changes, what doesn’t
#

Changes: sequence, not ownership. Planning, scaffolding, and tests move earlier. Pull systems work better because tickets carry context with them.

Doesn’t change: taste, trade-offs, responsibility. Humans still decide shapes, enforce style and architecture, and say no when a fast path breaks the system.

A day in this rhythm
#

Maya opens a ticket about retry logic for webhooks. The ticket links two specific modules (webhooks/handlers.py and utils/backoff.py), shows the current handler function, sets a 200ms performance budget, and mentions idempotency concerns.

Overnight, someone asked the model for an outline, tests, and a sketch of the exponential backoff. Maya pulls the branch, runs the failing tests, fixes the import paths, renames retryWithDelay to retryWithBackoff, and adds the edge case the model missed: what happens when the webhook endpoint returns a 2xx but with an error payload.

The pull request explains why this retry shape fits the existing error-handling patterns. Review is quicker because the tests tell a coherent story and the implementation follows established conventions.

Other days the draft is wrong. That’s fine. Treat model output like a junior colleague who works nights. Useful, not in charge.

Rules that work
#

Move work left. Earlier context beats later speed. A well-prepared ticket with model scaffolding saves more time than the fastest possible code review.

Tests first, always. A failing test is a better specification than three paragraphs. It’s also harder for models to misinterpret.

Keep context near code. Prompt fragments, architectural decisions, and constraint notes live in the repo, in README files, in draft PRs, embedded in comments. Not buried in tickets.

Guardrails on by default. Lint, types, security scanning, secret detection. Machines excel at boring compliance checks.

Measure flow, not effort. Track cycle time per PR, lead time per ticket, escaped defects. Forecast by readiness and risk, not by story points.

Privacy and security require explicit protocols. The risk of accidentally sharing sensitive code with public AI models is real and costly. Establish clear guidelines: never include API keys, connection strings, or personally identifiable information in prompts. Use enterprise-grade, secure AI platforms that offer data residency guarantees and audit trails for proprietary codebases. Train teams to craft prompts that describe patterns and requirements without sharing actual sensitive business logic. When in doubt, use masked or synthetic data for sensitive workflows.

If you manage people
#

Your job is removing friction, not managing output. Give time for tickets to become model-ready. This is planning work, not overhead. Keep a small library of prompt examples and improve them during retrospectives.

Tighten CI so “fast” doesn’t mean “sloppy.” Publish a simple flow dashboard that shows where work gets stuck. Hire for judgment and systems thinking. These are the skills that matter when the typing is handled.

The jargon, decoded
#

CI/CD: Continuous Integration/Deployment. Scripts that build, test, and deploy code automatically
PR: Pull Request. A proposed change waiting for review and approval
Scaffold: A minimal starter that compiles and runs, giving structure without implementation
SAST: Static Application Security Testing. Automated scans that catch risky code patterns

Common challenges and practical fixes
#

This isn’t magic. Not every ticket will be well-prepared, and AI-generated code comes with predictable problems. Here’s what we’ve learned from teams making this transition:

Ambiguous requirements lead to hallucinated features. When tickets say “make it faster” or “improve error handling,” models invent requirements that sound reasonable but miss the point. Fix: Break vague tickets into smaller, well-defined tasks with specific success criteria. “Reduce webhook timeout from 30s to 10s” beats “improve webhook performance.”

AI misreads context and creates plausible but wrong solutions. Models excel at patterns but struggle with business logic edge cases. Fix: Implement a quick human-in-the-loop review before any AI-generated code gets merged. Treat the first commit as a draft that needs validation, not a solution that needs polish.

Legacy systems resist model understanding. Older codebases with inconsistent patterns, missing documentation, or complex implicit contracts confuse models. Fix: Start with greenfield features or well-documented modules. Let models learn your patterns gradually rather than throwing them at your most complex legacy code first.

Developer experience matters
#

Efficiency gains mean nothing if developers lose engagement. The teams seeing the best results from this approach focus as much on satisfaction as speed.

Automating repetitive tasks creates space for creative problem-solving. Developers report higher job satisfaction when they spend less time on boilerplate and more time on architecture, user experience, and system design. The cognitive overhead of switching between mundane tasks and complex decisions is real.

Maintaining ownership prevents AI dependency. The key is ensuring developers still feel ownership over their work. AI provides starting points, not finished solutions. Developers should be critiquing, refining, and ultimately deciding what ships. When people feel like code reviewers rather than code authors, engagement drops.

Recognition and growth paths need updating. Traditional metrics like lines of code or features shipped become less meaningful. Focus instead on system design contributions, code review quality, and mentoring newer team members on effective AI collaboration patterns.

Practical patterns that work
#

Here are specific workflows teams are using to shift work earlier and run processes in parallel:

Background ticket processing. Set up automation that starts working on tickets as soon as they’re marked “ready for development.” While you finish your current task, AI generates scaffolding, tests, and implementation sketches for the next three tickets in your queue. You arrive to find branches with failing tests and working code that needs review, not blank files.

Automated test generation on PR creation. Every time someone opens a pull request, trigger automation that generates comprehensive test cases based on the code changes. The developer reviews and refines these tests using AI feedback loops. Multiple processes run in parallel: the original feature development, test generation, security scanning, and performance analysis.

Proactive code review preparation. Before requesting human review, run AI analysis that identifies potential issues, suggests improvements, and generates explanatory comments. The reviewer gets a pre-analyzed PR with highlighted concerns and suggested fixes, turning review from detective work into decision-making.

Context-aware documentation updates. When code changes, automatically generate documentation updates and README modifications. AI identifies which docs are affected and creates draft updates that maintainers can approve or refine.

Dependency and impact analysis. For every change, run background analysis of what else might be affected. Generate migration guides, update scripts, and compatibility notes before anyone asks for them.

Parallel environment management. While you work on feature A, have automation preparing environments, running tests, and validating deployments for features B and C. Manage multiple workstreams simultaneously without context switching.

The key is treating AI like a team of junior developers working different shifts. They prepare, you decide. They draft, you refine. They analyze, you prioritize.

Start small, learn fast
#

Pick one team, one project type, one workflow. See what works. The goal isn’t perfect tickets overnight, it’s better starting points for the work that matters most.

We’ll keep our rituals. We’ll move their weight. When a developer opens a ticket and sees tests, a sketch, and a plan, the day starts on step two. The work that remains is the part that needs judgment. That’s the part worth getting faster at.

The sequence changed. The responsibility didn’t. AI gives us starting points; humans decide where to go.

Teams moving in this direction often find the trickiest part isn’t the technical implementation, it’s the cultural shift. If you’re curious how this might work for your organization, feel free to reach out.

Hiring Developers in the Age of AI: What Actually Matters Now

Mon, 22 Sep 2025 00:00:00 +0000

Let’s be honest: LeetCode is dead.

Not because solving algorithm puzzles was ever the perfect way to measure real-world skills, but because today it’s simply irrelevant. With GenAI tools writing clean code, fixing bugs, and suggesting multiple solution paths before lunch, traditional coding tests have lost their predictive power.

I’ve seen the earthquake that AI has caused in our industry over the past two years. The results have been staggering: teams that embraced AI and shifted focus from raw coding ability to systems thinking and AI collaboration aren’t just doing better, they’re demolishing their competition. I’m talking 2-3x faster delivery times, dramatically fewer production issues, and consistently better architectural decisions.

So if not coding tests, then what? What should we actually be looking for when we hire developers now?

The Old Way (And Why It Worked… Until Now)
#

The traditional approach was elegantly simple:

Throw candidates into a coding challenge
Test their ability to debug, write clean functions, and handle scale
Hire the ones who could execute under pressure

It worked decently well for building teams of strong individual contributors. We got developers who could implement features, fix bugs, and optimize performance; exactly what we needed when writing code was the primary bottleneck.

Why That Mental Model Is Broken
#

Here’s the uncomfortable truth: writing code is now tactical work.

I’ve watched junior developers with six months of experience use Claude or Cursor to produce code that would have taken senior developers hours to write just two years ago. The AI handles boilerplate, suggests optimizations, and even catches edge cases that humans regularly miss.

The real bottleneck isn’t typing code anymore, it’s knowing what to build, how to design it, and how to guide AI to get you there safely.

Talking with hiring managers and candidates, a clear pattern emerges: many candidates who excel at complex LeetCode problems struggle to design a simple feature end-to-end. They know algorithms but not architecture. They can optimize a function but can’t decompose a business problem.

Those candidates wouldn’t last six months on a modern development team.

What We Actually Need Now: The New Developer Profile
#

The developers you want on your team in 2025 aren’t “code monkeys.” They’re system architects with hands-on pragmatism and AI fluency.

Here’s what I actively look for:

Systems Thinking
#

They see the whole picture without blind spots. When you describe a feature, they immediately start asking about data flow, failure modes, and integration points. They think in terms of systems, not just functions.

Architectural Reasoning
#

They can translate messy business problems into clean technical blueprints. More importantly, they can explain their design decisions and trade-offs to both technical and non-technical stakeholders.

Problem Decomposition
#

They break down complexity into clear, buildable parts. They don’t get overwhelmed by large problems, they methodically slice them into manageable pieces and tackle them systematically.

AI Collaboration Skills
#

This is the big one. They know how to write effective prompts, guide AI tools toward useful solutions, and—critically—review AI output for correctness and maintainability. They’re not intimidated by AI; they’re empowered by it.

Quality Gatekeeping
#

They maintain high standards when AI “gets creative.” They catch hallucinations, spot security issues, and ensure that generated code meets production standards.

In short: I want generalists who can connect the dots across the entire system, not specialists who excel at optimizing one corner.

How We Test for This: A Practical Interview Framework
#

I’ve completely restructured my interview process around two core evaluations:

Interview 1: Architecture & Systems Design (60 minutes)
#

Present a realistic business problem and watch how they think through it. I’m not looking for the “perfect” solution, I want to see their thought process.

What I’m evaluating: What questions do they think to ask.

Do they ask clarifying questions about scale, requirements, and constraints?
Can they sketch out data models, API contracts, and system boundaries?
Do they consider failure modes, monitoring, and rollback strategies?
Can they explain complex technical decisions in simple terms?

I don’t mind if candidates don’t immediately know the answers - in fact, I expect them to leverage AI for help. What I’m really evaluating is whether they know what questions need to be asked in the first place. The best candidates:

Think out loud and demonstrate their reasoning process
Ask insightful questions that reveal system-level thinking
Know when and how to use AI effectively to fill knowledge gaps
Arrive at pragmatic solutions that account for real-world constraints

It’s not about having all the answers memorized - it’s about knowing which questions matter and how to find answers systematically.

Interview 2: Problem Analysis + AI Collaboration (90 minutes)
#

This is where the magic happens. I give candidates access to their preferred AI tools (Cursor, Claude, ChatGPT, whatever) and present a realistic development challenge.

Example: “Our API response times have increased 300% over the past month. Here’s our codebase and monitoring data. Figure out what’s wrong and propose a fix.”

What I’m evaluating: Managing the process.

How do they break down the investigation process?
What prompts do they write to get useful AI assistance?
How do they verify AI suggestions before implementing them?
Do they maintain code quality standards while moving fast?
Can they explain their findings and proposed solution clearly?

This interview reveals exactly how they think, how they collaborate with AI, and whether they hold themselves to high standards when tools are doing the heavy lifting.

A Note to Technical Recruiters (This Could Change Your Game)
#

If you’re screening candidates, stop filtering solely on “years of Java experience” or “React expertise.” Those metrics are becoming less predictive by the month.

Instead, ask these questions:

“Walk me through how you’d approach building [specific system] from scratch.” Listen for systems thinking and architectural reasoning.
“Tell me about a time you used AI tools in development. What worked well? What didn’t?” You want candidates who’ve thoughtfully integrated AI into their workflow.
“How do you ensure code quality when using AI assistance?” The best candidates have developed personal standards and review processes.
“Describe a complex problem you’ve broken down into smaller parts.” Problem decomposition skills transfer across technologies and domains.

Helping your hiring managers identify these profiles will make you stand out in a crowded market. You’ll be the recruiter who actually understands what modern development teams need.

The Competitive Advantage: Speed vs. Wisdom
#

Here’s what I’ve learned from teams that have successfully made this transition: the companies winning in the AI era aren’t just moving faster, they’re making better decisions faster.

When your developers can think architecturally and collaborate effectively with AI, you get both velocity and quality. Features ship quickly, but they’re well-designed, maintainable, and robust.

When you hire traditional “coders” who struggle with AI collaboration, you get neither speed nor quality. They’re intimidated by the tools, suspicious of AI output, and spend too much time doing things that should be automated.

What’s Next: The Future of Developer Hiring
#

The industry is already splitting into two camps: companies that have modernized their hiring practices and those still clinging to the old ways.

The companies in the first camp are building teams of AI-augmented architects who can design and deliver complex systems at unprecedented speed.

The companies in the second camp are collecting strong individual contributors who excel at tasks that AI is increasingly handling better.

Guess which teams will be more competitive in 2026?

The way we hire has to evolve, and it has to evolve now. Code challenges won’t disappear overnight, but their value is fading rapidly. If you’re still hiring the “old way,” you’re probably missing the kind of people who will thrive in the AI-driven future of software development.

The Bottom Line
#

The transition is already happening. The question isn’t whether to change your hiring process, it’s whether you’ll change it proactively or be forced to change it when your competitors start outshipping you with smaller teams.

I’ve seen this transformation up close. Companies that embrace it early get first pick of the best AI-native talent. Companies that wait find themselves competing for a shrinking pool of traditional developers who may not be equipped for the future of software development.

Want More Guidance?
#

I’ll be publishing a follow-up article specifically for developers looking to thrive in this AI-driven job market. We’ll cover:

How to demonstrate your architectural thinking in interviews
Building a portfolio that showcases your AI collaboration skills
Practical exercises to strengthen your system design abilities
Tips for discussing AI tools without overselling them

Stay tuned. The future of development is exciting, and I want to help you be ready for it.

I'm Pro-AI. That's Exactly Why I'm Worried About Our Next Senior Engineers

Thu, 18 Sep 2025 00:00:00 +0000

I’m the person inside my company who pushes AI. I run pilots, set policies, and cheer when a team ships twice as fast with a good copilot. I’m not a doomer. But I keep bumping into a hard question that’s keeping some people up at night:

What happens to the next generation of senior engineers if AI eats all the work that used to grow them?

This question hits differently depending on where you sit. If you’re an engineering manager, you might have junior developers on your team right now who are impressively good with AI tools but struggle when those tools fail. If you’re a junior developer, you might wonder how to stand out in a world where everyone can prompt their way to working code.

Both of you are facing the same challenge: in a world of AI-assisted development, how do you build (or grow) engineers who can think beyond the tool?

The real problem: AI operators vs. AI-augmented engineers
#

Here’s what I’m seeing across teams: we’re accidentally creating two types of junior developers.

Type 1: AI Operators - They’re fast with prompts, great at stitching together tool outputs, and can ship features quickly. But they struggle when the AI is wrong, when context is missing, or when they need to debug something the model has never seen.

Type 2: AI-Augmented Engineers - They use AI aggressively but maintain the ability to reason from first principles. When the copilot fails, they don’t panic—they switch to manual mode and solve the problem.

Guess which type becomes your next senior engineer?

The difference isn’t talent—it’s how they learned to work with AI. The first group learned with AI as a teacher; the second learned with AI as a tool.

For Engineering Managers: Growing AI-Augmented Engineers
#

If you manage junior developers, you have the power to shape which type they become. Here’s your playbook:

Design “AI-off hours”
#

Block out 2-3 hours per week where your juniors solve problems without AI assistance. Yes, they’ll be slower. That’s the point. They’re building mental models they’ll need when the AI is wrong or unavailable.

Example: Give them a bug that requires reading logs, tracing execution, and writing a fix from scratch. No copilot, no ChatGPT. Just them, the debugger, and their brain.

Create critical-thinking exercises
#

Present two plausible AI-generated solutions to the same problem. Ask your junior to pick one and defend their choice with tests, performance metrics, and trade-off analysis.

Why this works: You’re not testing their ability to prompt—you’re testing their ability to evaluate, which is what senior engineers do all day.

Make AI transparency mandatory
#

In code reviews, ask juniors to include their prompts and explain their verification process. Don’t just review the code—review how they worked with the AI.

Questions to ask: “How did you validate this suggestion?” “What did you do when the first attempt didn’t work?” “How confident are you that this handles edge cases?”

Rotate “first-principles on-call”
#

When systems break, give juniors the first shot at diagnosing (with a senior on backup). They need to learn how to read logs, trace problems, and write clear incident reports without AI assistance.

Pair AI-natives with domain veterans
#

Your best senior engineer might not prompt as smoothly as your junior, but they know every edge case in your system. Pair them. The junior learns context; the senior learns tools.

For Junior Developers: How to Stand Out
#

If you’re a junior developer, here’s how to differentiate yourself from the crowd of AI operators:

Build your “no-AI” skills
#

Spend time every week solving problems without AI assistance. Pick small challenges: write a sorting algorithm by hand, debug a performance issue using only profiling tools, trace through a complex codebase to understand how data flows.

Why this matters: When you’re the only person in the room who can debug the AI’s output, you become indispensable.

Learn to evaluate AI output critically
#

Don’t just accept what the AI gives you. Ask: “Is this the best approach?” “What are the trade-offs?” “How would this perform at scale?” “What happens if this assumption is wrong?”

Practice exercise: Take an AI-generated solution and try to break it. Write tests that expose its weaknesses. Then improve it.

Become an AI transparency expert
#

Document your AI workflows. Show your manager not just what you built, but how you used AI to build it, what you validated, and where you made decisions the AI couldn’t make.

Career benefit: This demonstrates judgment, not just tool proficiency. Judgment is what gets you promoted.

Volunteer for “AI-unfriendly” tasks
#

When something breaks at 2 AM and the AI doesn’t understand your legacy system, volunteer to dive in. When there’s a gnarly performance issue that requires deep system knowledge, raise your hand.

The pattern: While others rely on AI for everything, you become the person who can work when AI can’t help.

Study the fundamentals
#

AI can’t replace understanding of data structures, algorithms, system design, and debugging. Invest time in these foundations. They’re your differentiator in a world of prompt engineers.

Ask senior engineers about their “pre-AI” war stories
#

How did they debug race conditions? How did they optimize that critical query? How did they design that tricky API? Learn from their mental models, not just their code.

The uncomfortable truth about career paths
#

Here’s what I tell the junior developers I mentor: the market is about to be flooded with people who can use AI tools effectively. That’s not special anymore—it’s table stakes.

What’s rare (and valuable) is someone who can use AI tools effectively and think independently when those tools fail. Someone who can prompt well and code well without prompts. Someone who can ship fast with AI and debug deep problems when AI can’t help.

That person is your future senior engineer. The question is: are you building that person, or are you just building better AI operators?

The bottom line
#

I’m not anti-AI—I’m pro-expertise. The future belongs to engineers who can harness AI’s speed while maintaining their ability to think, debug, and solve problems independently.

If you’re a manager, you have the power to shape this. Design deliberate learning experiences. Protect the struggle that builds judgment. Review not just what your juniors build, but how they think through problems.

If you’re a junior developer, the opportunity is enormous. While others become fluent in prompting, become fluent in fundamentals. While others depend on AI, learn to evaluate it. While others panic when tools fail, become the person who steps up and solves the problem.

The market will soon be flooded with AI operators. Don’t be one of them. Be the AI-augmented engineer your future self will thank you for becoming.

From "Toys" to "Tools": The Missing Layer Developers Actually Need

Tue, 16 Sep 2025 00:00:00 +0000

I’m no longer a hands-on developer and haven’t written production code in a while. Over the last year, though, I’ve been busy rolling out AI tooling to make developers more productive. That vantage point made Idan Gazit, Head of GitHub Next, and his talk at GitHub Connect Israel really resonate: it put clean language to patterns I’ve seen on the ground.

AI coding isn’t about clever completions anymore. It’s about stitching work together so results cross the threshold from toy to tool—from interesting demos to outcomes you can trust.

Where productivity really lives
#

Idan emphasized something we often forget: most developer time isn’t typing—it’s understanding. Reading code, tracing decisions, navigating repos, connecting issues to diffs. If that’s the job, then the winning AI isn’t a “faster keyboard”; it’s a context engine. In my deployments, the largest gains came when tools reduced the time to find and trust the next action, not when they suggested a few extra lines.

Models matter; orchestration matters more
#

Idan shared that Cursor’s rise was helped by early access to strong models that GitHub Copilot didn’t yet have (e.g., Anthropic’s Claude 3.5). GitHub Copilot is catching up fast with smarter selection and repo-scale workflows. Same editor base (VS Code); different orchestration philosophies. And that’s the real race: who turns messy inputs (code, issues, docs, tests) into a clear plan with traceable steps—at a sensible latency and cost?

Two pragmatic truths follow:

Latency won’t magically vanish. Treat it as a design constraint, not a bug. Good tools keep you moving while the model works: batch related calls, prefetch likely context, stream or show partial results, and always land progress in a reviewable artifact (branch/PR/plan) instead of a spinning loader. You stay productive; the heavy lifting can finish in the background.

Cost and correctness are product features. Model choice is an economic and risk decision. The tool should make that trade-off visible (and often choose for you): fast/cheap paths for low-stakes edits; slower/more thorough paths for refactors and migrations. Show expected cost/latency, explain why a model was selected, and offer a one-click upgrade/downgrade when stakes change.

The firehose problem
#

AI didn’t reduce information; it amplified it. More suggestions, more tabs, more “help.” Without a memory of intent, this becomes context switching with extra steps. The tools that stick are the ones that carry context forward—they remember the goal, thread it through each step, and keep the evidence attached so trust can accumulate.

The gap between IDE and platform
#

This is why Idan’s hint about a technical preview in ~six weeks caught my attention: something that sits between the IDE (where you do the work) and GitHub (where you collaborate). That’s exactly the seam where productivity currently leaks. Most real tasks span files, repos, people, and tickets; the handoffs are where intent gets lost.

If I could spec that missing layer, I’d keep it simple:

Hold the intent. Start every task with a plain-English objective and keep it attached to every artifact—plan, diff, test, PR. Every change should answer: does this move us closer to the stated goal?

Prefer plans over paragraphs. Propose steps (analyze → patch → test → PR) with clear checkpoints. Humans review plans faster than prose.

Make provenance and reversibility default. Show what sources the AI used and always operate on a branch/PR so rollback is one click, not a hope.

When we rolled out AI internally, even lightweight versions of the above moved the needle more than any single “smarter” model choice.

So, will developers stop looking at code?
#

Probably not. But they’ll look at less code and more intent, diffs, and evidence. The center of gravity shifts from “type this” to “approve this change under these constraints.” For that to work, the system must preserve context, explain itself, and keep the human decisively in the loop.

I left the event convinced of one thing: the future isn’t another sidebar. It’s continuity. When tools remember what we’re trying to do and carry that memory across the workflow, AI finally feels less like a toy—and more like a tool.

Engineering Management · PiniShv

Agentic Overwatch: Why Your Next Dev Team Will Look Like a NASA Control Room

Defining the term #

It was never just about code #

The governance gap #

Borrow the tier model from the NOC #

The human becomes the orchestrator #

The handoff: ownership changes hands at the end of the day #

The Overwatch Maturity Model #

How to start before your agents force the issue #

The fleet doesn’t sleep #

Org Charts for AI Agents: Mapping Your Human and AI Workforce

The wake-up call most teams need #

Why agents belong on the org chart #

What this looks like in practice #

Best practices from teams actually doing this #

Give every agent a human owner #

Define explicit boundaries #

Onboard and train them like team members #

Set goals and measure performance #

Keep humans in the loop for consequential actions #

The uncomfortable conversations this forces #

The risks nobody wants to talk about #

What changes, what doesn’t #

Start small, but start now #

The bottom line #

When AI Writes 90% of Your Code, What Are You Actually Doing?

The 10% That Actually Matters #

What Does That 10% Actually Include? #

The Productivity Multiplier Nobody Talks About #

The Divide Between AI Operators and AI-Augmented Engineers #

What This Means for Engineering Teams #

The Junior Developer Problem #

What About The Other 10%? #

The Uncomfortable Truth for Developers #

Rebalancing, Not Replacing #

What Comes Next #

AI Agents for Real Productivity: What Works in 2025

What makes an agent different from a chatbot #

Where agents actually help (and where they don’t) #

The agent landscape in 2025: what’s actually worth using #

Cloud platforms: fast to start, limited control #

Open-source frameworks: maximum flexibility, you run the infrastructure #

Safety and observability: the unsexy stuff that matters #

Making the right choice for your situation #

What matters more than the platform #

For engineering leaders: the strategic opportunity #

For developers: why this matters to your career #

What separates success from expensive failure #

Where to start #

What's Holding You Back from Succeeding in the AI Era?

The Great Divide: Marcus vs. Sarah #

The Self-Deception Patterns #

From Privates to Generals #

The Invisible Barriers #

What Works for Managers #

What Works for Developers #

The Uncomfortable Truth About What Comes Next #

Your Move #

Model Context Protocol: The Missing Connection Between AI and Your Real Work

The problem MCP solves #

What MCP actually does #

Understanding the architecture (if you’ve built APIs, you’ll get this) #

The three-layer architecture #

How it compares to other integration patterns #

The transport layer (how data moves) #

The protocol is simple (intentionally) #

Why this architecture works #

How to start using MCP today #

Step 1: Install an MCP-compatible client #

Step 2: Add your first MCP server #

Step 3: Connect to your databases #

Step 4: Add Git context #

Step 5: Connect to your tools #

What changes when AI has real context #

From manual context to automatic context #

From shallow answers to deep understanding #

From single-turn to multi-step workflows #

When to start building your own MCP servers #

The right first server to build #

Defining the term
#

It was never just about code
#

The governance gap
#

Borrow the tier model from the NOC
#

The human becomes the orchestrator
#

The handoff: ownership changes hands at the end of the day
#

The Overwatch Maturity Model
#

How to start before your agents force the issue
#

The fleet doesn’t sleep
#

The wake-up call most teams need
#

Why agents belong on the org chart
#

What this looks like in practice
#

Best practices from teams actually doing this
#

Give every agent a human owner
#

Define explicit boundaries
#

Onboard and train them like team members
#

Set goals and measure performance
#

Keep humans in the loop for consequential actions
#

The uncomfortable conversations this forces
#

The risks nobody wants to talk about
#

What changes, what doesn’t
#

Start small, but start now
#

The bottom line
#

The 10% That Actually Matters
#

What Does That 10% Actually Include?
#

The Productivity Multiplier Nobody Talks About
#

The Divide Between AI Operators and AI-Augmented Engineers
#

What This Means for Engineering Teams
#

The Junior Developer Problem
#

What About The Other 10%?
#

The Uncomfortable Truth for Developers
#

Rebalancing, Not Replacing
#

What Comes Next
#

What makes an agent different from a chatbot
#

Where agents actually help (and where they don’t)
#

The agent landscape in 2025: what’s actually worth using
#

Cloud platforms: fast to start, limited control
#

Open-source frameworks: maximum flexibility, you run the infrastructure
#

Safety and observability: the unsexy stuff that matters
#

Making the right choice for your situation
#

What matters more than the platform
#

For engineering leaders: the strategic opportunity
#

For developers: why this matters to your career
#

What separates success from expensive failure
#

Where to start
#

The Great Divide: Marcus vs. Sarah
#

The Self-Deception Patterns
#

From Privates to Generals
#

The Invisible Barriers
#

What Works for Managers
#

What Works for Developers
#

The Uncomfortable Truth About What Comes Next
#

Your Move
#

The problem MCP solves
#

What MCP actually does
#

Understanding the architecture (if you’ve built APIs, you’ll get this)
#

The three-layer architecture
#

How it compares to other integration patterns
#

The transport layer (how data moves)
#

The protocol is simple (intentionally)
#

Why this architecture works
#

How to start using MCP today
#

Step 1: Install an MCP-compatible client
#

Step 2: Add your first MCP server
#

Step 3: Connect to your databases
#

Step 4: Add Git context
#

Step 5: Connect to your tools
#

What changes when AI has real context
#

From manual context to automatic context
#

From shallow answers to deep understanding
#

From single-turn to multi-step workflows
#

When to start building your own MCP servers
#

The right first server to build
#

The second server: your APIs
#

Building with the official SDKs
#

Security patterns that matter
#

Why OpenAI and Google adopted this so fast
#

What this enables that wasn’t possible before
#

Contextual code review
#

Predictive debugging
#