Developer Productivity · PiniShv

Stop Reviewing Code. Start Reviewing Evidence.

Fri, 10 Jul 2026 12:00:00 +0300

The math went first. Faros telemetry puts hard numbers on what agent-heavy teams already feel: they produce 98% more PRs, 154% larger, and those PRs wait 4.6x longer for a reviewer to even pick them up.

Twice the PRs. Two and a half times the size. Nearly five times the wait before a human even opens the diff.

The pull-request review model, where one busy human reads a diff, understands it, and approves it, didn’t bend under agent volume. It snapped. And the industry’s answer so far has mostly been to tell humans to read harder.

That won’t work, and most of us already know it. The fix for the verification bottleneck is not humans reading more diffs. It is building verification capacity as a system, the way we once built CI. Humans stop reviewing code. They start reviewing evidence.

The bottleneck moved downstream and put on a disguise
#

The generation problem is solved. An MIT study of more than 100,000 developers found code volume up roughly 180% while shipped software rose only about 30%. The constraint is no longer producing code. It is getting code to a state anyone is willing to put in production.

And here is the part that should sting. A LinearB study of 8.1 million PRs across 4,800 organizations found developers feel 20% faster while merged-to-production time is actually 19% slower. Everyone is typing less and waiting more. The keyboard got fast. The gate stayed human-sized.

I wrote before that AI made code cheap to produce, not cheap to own. This is that gap, matured into a full-blown organizational failure mode. Ownership starts at the review gate, and the review gate is where the whole pipeline now piles up.

The human GIL is a correct diagnosis and a terrible strategy
#

Martin Fowler named the problem precisely: the human is the Global Interpreter Lock for agents. Everything the fleet produces serializes through one person’s attention. His advice: don’t launch more agents than you can properly review. Two weeks later he quoted Charity Majors on what happens when you ignore that: “when you ship code faster than engineers can read it… reliability degrades, institutional knowledge evaporates.”

They are right about the failure mode. Zoom out two years and the curve is even steeper: The Pragmatic Engineer reports teams running agents now ship five times more pull requests than they did two years ago, at triple the size, and the same writeup carries a Meta account-takeover vulnerability as the cautionary tale of what merges when volume outruns comprehension. Nobody serious disputes the diagnosis.

But “slow down” is a holding pattern, not a strategy. It caps your engineering organization’s output at the reading speed of its most conscientious reviewers. Forever.

We have seen this exact shape of problem before. Twenty-five years ago the bottleneck was testing. Releases piled up behind manual QA cycles, and the industry’s first instinct was the same one it has now: test harder, run longer QA cycles, slow the releases. That instinct lost. We built CI instead. Nobody today asks a release manager to hand-run the regression suite, and nobody calls that recklessness. We turned verification from a human virtue into a system property.

Bryan Finster put it bluntly: AI broke traditional code review, and the answer is to restructure it rather than heroically read more diffs. I’d go one step further. The review gate has to become something else entirely.

The review gate becomes an evidence gate
#

Here is the reframe I’ve landed on after living with agent fleets in production.

Stop asking humans to verify code. Ask the system to produce evidence, and ask humans to judge it. The evidence gate replaces “a person read the diff” with “the change arrived with machine-verified proof”: failing-then-passing tests, a reproduced bug, validation runs, scope and regression checks. The human rules on the two things machines can’t: intent and architecture.

Call it evidence-based review. The diff is the claim. The evidence is the proof. The human is the judge, not the fact-checker.

Concretely, evidence looks like this:

Reproduction. A bug fix ships with the bug demonstrated failing before the change and passing after it. Not “trust me.” A recorded, re-runnable repro.
Adversarial tests. Tests written to break the change, ideally by a different agent than the one that wrote it. Author-written tests are a conflict of interest whether the author is a human or a model.
Validation runs. The change exercised in a real environment, end to end, with the output attached.
Scope discipline. Proof the diff touches only what the claim says it touches. Agents love to “improve” three unrelated files on the way through.
Regression and blast-radius checks. What else depends on this path, and what happened when the suite ran against it.

None of that requires a human minute. All of it can be produced by the same class of machinery that produced the code. In my own organization, that is the bar I hold the autonomous systems that investigate bugs and write fixes to: a change that arrives without its evidence isn’t “waiting for review.” It isn’t done.

And this is measurable, not hand-wavy. Cognition’s FrontierCode benchmark is the first to score agent PRs on whether a maintainer would actually merge them: correctness, test quality, scope discipline, regression safety, judged by criteria built with more than twenty senior open-source maintainers. Every frontier model passes fewer than half of the hard tasks (the leaderboard leader clears the field by about twelve points and still lands under 50%). Two lessons in one number. First: agents have not earned blind trust, so the gate stays. Second: merge-worthiness can be scored by a machine. If a benchmark can grade correctness, test quality, and scope discipline, your pipeline can demand them.

If your best engineers are your validation layer, you built the system backwards
#

LeadDev documented what agent velocity is doing to the people downstream of it: mid-level engineers silently absorbing unmeasured “invisible validation work,” with one org losing three of them in six to eight weeks while the team shipped 40% faster, right up until the production incidents arrived. A survey of 2,147 engineers found 71% often feel like a middleman between AI output and actual results.

I believe every word of it. I’ve watched the pattern form: the diligent engineers become the org’s immune system, quietly re-verifying everything the agents produce, unmeasured and unthanked, while the dashboard celebrates throughput.

But notice what that actually is. It is not proof that agents don’t work. It is proof that the organization deployed generation capacity without deploying verification capacity, and then made its most conscientious humans eat the difference. The invisible validation work exists because the visible validation system doesn’t.

That’s not diligence. That’s a design flaw with a burnout rate.

The evidence gate is the answer to the middleman problem, not a competitor to it. Every hour a mid-level engineer spends manually confirming that an agent’s fix actually fixes the bug is an hour the system should have spent producing a repro automatically. Humans reviewing evidence instead of re-deriving it is not just faster. It is the difference between judgment work, which builds engineers, and verification drudgery, which burns out exactly the people you need to become your next seniors.

Verification is a system you build, not a virtue you demand
#

If this sounds like the Agentic Overwatch tier model, that’s because it is the same shape. Code review is simply the first engineering ritual to move into the Agent Operations Center. The evidence gate runs in the same three tiers:

Tier 1, evidence production. Agents and deterministic tooling. Every change automatically generates its repro, its adversarial tests, its validation run, its scope and regression report. This is CI’s grandchild: not “did the tests pass” but “here is the complete case for this change.”

Tier 2, adjudication. Agents reviewing agents. A second system cross-examines the evidence: are these tests real or decorative, does the repro actually exercise the bug, did the diff sprawl beyond its claim. Weak cases get bounced back before a human ever sees them.

Tier 3, judgment. Humans. Intent: should this change exist at all? Architecture: does it belong here, shaped like this? Consequence: what’s the blast radius if the evidence lied? These questions don’t scale with lines of code, which is exactly the point. Human attention should never have been scaling with lines of code in the first place.

Fowler is right that human attention is the lock. So stop routing everything through it. Route claims and proofs through it, at the altitude where human judgment actually operates, and let the machinery below grind through the volume the way CI grinds through test matrices.

What to do Monday morning
#

Measure the validation tax. Ask your mid-level engineers how many hours last week went to verifying agent output that nothing tracked. The number will unsettle you. Good. Invisible work stays broken precisely because it’s invisible.

Define evidence requirements per change class. A bug fix ships with a reproduction. A refactor ships with regression proof. A dependency bump ships with a blast-radius report. Write it down like you once wrote down test-coverage rules. No evidence, no review slot.

Build the evidence harness before you scale the fleet. Every agent lane you launch without automated evidence production is another engineer conscripted into middleman duty. Verification capacity first, generation capacity second. Most orgs did it in exactly the wrong order, which is how we got here.

Retrain the reviewer role. Your reviewers stop being line-by-line readers and become adjudicators: they rule on whether the evidence supports the claim and whether the change deserves to exist. That is a promotion, not a demotion. It is also the Tier 3 skill your whole agent operation will run on.

The teams that keep the human as the interpreter lock will spend the next two years choosing between capped velocity and quiet reliability decay, while their best people burn out doing verification work no dashboard sees. The teams that build the evidence gate get the volume and the trust.

Code review isn’t dying. It’s being promoted, from reading the work to judging the case.

Stop reviewing code. Start reviewing evidence.

How is your team handling review under agent volume? Whether you’re drowning in diffs or already building the evidence machinery, I want to hear what’s working. Find me on X, LinkedIn, or Telegram.

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.

The Vibe Coding Backlash Is Right. Seniors Are Losing the Argument Anyway.

Fri, 24 Apr 2026 14:00:00 +0300

Something finally broke this week. Forbes published Vibe Coding Will Break Your Company. Senior engineers are circulating it. Other senior engineers are writing their own versions. The pushback on vibe coding culture has been brewing for months, and it just hit mainstream media.

The seniors are right. And they’re about to lose the argument anyway.

Here’s why, and what needs to happen if they actually want to win it.

What the seniors are right about
#

The data at this point isn’t close.

Multiple independent audits of AI-assisted codebases are converging on the same picture: AI-co-authored code ships with materially more “major” issues than human-written code. Audits of no-code AI app-generation platforms keep finding meaningful percentages of generated applications going live with real security holes: hardcoded API keys, client-side-only authentication, unsanitized user inputs.

In July 2025, a Replit AI agent deleted a live production database during an explicit code freeze, affecting over 1,200 executive users. The agent had permissions. The permissions were never meant for an agent. Nobody designed for the possibility.

Across the industry, Stack Overflow’s trust-gap research and DX’s Q1 2026 impact report tell the same story: 84% of developers use AI daily. Only 29% trust the code reaching production. PR throughput is up 46% in some teams. Defect rates are up 50% in some of the same teams.

And the perception gap keeps embarrassing us. METR’s study measured experienced developers as 19% slower with AI while they believed they were 20% faster. 39 percentage points of self-deception. The feeling is real. The feeling is wrong.

The craft didn’t change. The pressure to ship faster without understanding what shipped did. And when you ship what you don’t understand, you pay for it later, with interest. The next generation of senior engineers is taking the brunt of it.

The seniors are not wrong to push back. They’re watching production systems rot in slow motion.

What the vibe coders are also right about
#

For a lot of what companies actually ship, fast-and-rough is genuinely fine. Internal tools nobody will maintain in two years. One-off data migrations. Prototype features for customer calls. Throwaway scripts. The economics of fussing over these pieces changed. If an agent ships them in thirty minutes and they work, that’s a real win.

The vibe coders are also right that a lot of “senior engineering rigor” is muscle memory from an era where code was expensive to produce. Gatekeeping code review, nit-level style comments, architectural debates that take longer than the feature itself. Some of it was always noise. More of it is noise now that the economics flipped.

And they’re right that the pushback often sounds like resistance to change from people protecting their role.

Both sides are right about different things. The fight isn’t which side wins. It’s where the line gets drawn.

Why the seniors are losing anyway
#

In most engineering orgs, the pushback against vibe coding is losing. Not because the data is wrong. Because the seniors can’t make their case in the meetings where throughput metrics get shown.

Imagine the scene. Quarterly review. Director pulls up a dashboard.

PR throughput: up 46%
Commits per engineer: up 2.1x
Features shipped: up 34%
Deployment frequency: up

Then the senior engineer raises a hand and says “but the code quality is degrading.”

Where’s that dashboard? What’s the number? Can you point to the specific incidents that didn’t happen because you caught them in review? Can you show the rework that wasn’t done because you stopped a bad architecture at design time?

Usually, no. The senior engineers have the instinct and the experience. They don’t have the receipts.

Throughput is legible. Judgment is invisible. In a fight between legible and invisible, legible wins every time.

This is the real problem. The seniors are right, and they’re losing, and they’re losing because the thing they’re right about doesn’t show up on the charts.

What “legible judgment” actually means
#

In organizations doing this well, the senior engineers who keep winning this argument don’t do it by being louder. They do it by making the prevented damage visible. Five concrete moves.

Write down the decisions you stop from shipping. When you block a PR because the approach is wrong, don’t just close it. Write a one-line note: “Rejected: would create a race condition under load. Suggested redesign: queue-based.” Collect these. After six months, you have a measurable “incidents prevented” count. That’s a number. Numbers win.

Track rework on AI-generated code specifically. Most PR analytics can’t distinguish AI-generated from human-written code. If yours can, instrument it. Show the quarterly trend: what percentage of AI-generated commits get reworked within 30 days? If it’s higher than your human-written baseline, that number is your argument.

Tie blocked architectures to real incident data. When an incident happens that a senior flagged earlier, say so in the postmortem. Not as blame. As calibration data. “This failure mode was identified in PR #1847 on March 3 and was not addressed before ship.” That’s the receipt.

Put a senior on every AI-native system’s design review, not just the code review. Code review is too late. By then the architecture is set and the only conversation left is stylistic. Design review is where senior judgment actually prevents expensive mistakes. Move your seniors upstream.

Run quarterly “prevented incident” retros. Once a quarter, the senior engineers present what they caught and the counterfactual. What would have happened if this had shipped? What did it cost to catch it? That reframes senior time as prevention, not overhead.

The bigger reframe
#

The vibe coding debate is a symptom. The underlying issue is that engineering organizations built their scorecards for a world where code production was the bottleneck. In that world, throughput meant progress.

That world ended sometime around late 2024. The bottleneck isn’t production anymore. It’s ownership. Review capacity. System understanding. Architectural coherence across the full surface area. Governance. Incident response.

If your scorecard only measures production throughput, you will systematically underfund the ownership layer. The senior engineers trying to protect that layer will keep losing quarterly reviews while the on-call pager gets louder.

The seniors aren’t wrong. The scorecard is.

What senior engineers should do right now
#

Three moves, in order.

Stop arguing about vibe coding. The debate is a distraction. Every hour spent defending “slow careful engineering” in principle is an hour not spent proving prevented cost in practice.

Start a prevented-incident log today. One line per blocked PR, rejected design, caught architectural issue. Share it monthly with your manager, not as complaint, as data. Six months from now you’ll have a case you can actually make.

Volunteer for the AI incident response playbook. When the next AI agent deletes something important (and it will), be the person with the playbook. Incidents shift organizational gravity. You want to be the person organizations call, not the person who said “I told you so.”

The seniors who survive this era will not be the ones who pushed back the loudest. They’ll be the ones who learned to make their judgment measurable, visible, and impossible to dismiss when the throughput chart is on screen.

The vibe coders are going to keep shipping. That’s fine. The question is who’s going to own what they ship in production three months later. That’s the open job. If you’re a senior engineer, that’s your job. Go take it.

What prevented-incident data do you actually have from the last quarter? Find me on X, Telegram, or LinkedIn.

Disclaimer: This article references specific studies, surveys, and public commentary for illustrative and educational purposes, including work from Forbes, Stack Overflow, DX, METR, Medium authors, Replit and Lovable incident reports, and industry analyses available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies or tools mentioned. This is commentary, not investment, legal, career, or business advice.

The End of Courses: Learn From AI Like a Toddler, Or Become Obsolete

Fri, 24 Apr 2026 10:00:00 +0300

Remember when building an application required months of upfront learning? You’d buy a 40-hour video course, read through documentation, and painstakingly memorize syntax before writing a single line of logic.

Today, an AI agent builds that same application in three minutes from a single prompt.

We’re standing at a massive crossroads. Not just in software development, but in how humans acquire knowledge. And most people haven’t realized yet that the learning model they grew up with just flipped upside down. Theory used to come before practice. Now practice comes first, and theory arrives on demand. That’s a different game. We need to relearn how to learn.

What actually died
#

Let me be precise, because this is the part that gets misread.

Courses didn’t disappear. Books didn’t disappear. The sequence did.

For twenty years the path was the same. Read the book. Buy the 40-hour course. Follow the tutorial. Build the toy project. Then, eventually, attempt something real. Learning was structured, linear, and almost entirely theory-first. That sequence is what broke.

An 8-minute deep-dive on a specific trade-off, delivered exactly when you need it, is actually more valuable than ever. Targeted, just-in-time learning is a superpower. What died is the 40-hour prerequisite. The idea that you have to load all the theory before you’re allowed to attempt anything real. The agent collapsed that runway to zero.

And the data is already catching up to what everyone can feel.

The coding bootcamp industry, the market that turned “learn to code in 12 weeks” into a multi-billion-dollar business, consolidated painfully through 2024 and 2025. Entry-level roles got automated or outsourced. Programs that didn’t rebuild around AI shut down. The survivors pivoted from “teach you to write code” to “teach you to work alongside agents.” On Udemy and Coursera, the courses people actually buy now have to be updated within the last 12 months or they’re teaching deprecated APIs. The half-life of “learned knowledge” collapsed.

But the deeper shift isn’t the market. It’s the cognitive model underneath.

I wrote before that AI didn’t change the work, it changed the sequence. The same thing is happening to learning. You’re no longer supposed to load the theory first and then apply it. You apply first, and the theory arrives on demand, exactly when you need it.

Learning is now intuitive, experiential, and strictly on-the-job.

Learn like a toddler
#

Think about how toddlers learn to speak.

Nobody hands a two-year-old a grammar textbook. They don’t attend a workshop on verb conjugation. They hear words in context, try them, get corrected, try again. They absorb meaning through constant exposure, trial, error, and interaction with their environment. The adult in the loop isn’t delivering lectures. The adult is a patient partner who keeps responding, correcting, and raising the bar.

That’s exactly how we have to work with AI now.

There’s actual learning science behind this. Piaget’s stages of cognitive development put hands-on experience and interaction at the center of how humans build real understanding. A recent Springer paper on developmentally aligned AI argues that AI tools work best when they act as scaffolding, not substitution. Temporary support that strengthens the learner’s internal capacity and is gradually removed as competence grows.

Scaffolding means every time the agent generates something, you engage with it, understand it, and internalize what you didn’t know before. Substitution means the agent does it for you, and next time you need the same thing, you still can’t do it without the agent. Both look identical in the commit history. They feel completely different six months in.

This is the choice hiding in every single prompt.

As agents expose us to new architectures, libraries, frameworks, and design patterns on the fly, we have a choice: we can blindly accept the output, or we can choose to learn from it critically. I choose to learn. I choose to treat the agent, which has access to effectively all the knowledge available in the world, as a sparring partner for deep, on-the-job learning.

A sparring partner is different from a thinking partner. A thinking partner you lean on. A sparring partner pushes back. The first makes you weaker over time. The second makes you stronger. Pick the right one.

The crossroads: Operator vs. Kolboynik Architect
#

Every developer right now is standing at the same fork. Two paths. Very different outcomes.

Path 1: The Operator (accept and ship)
#

You accept exactly what the agent generated. You never interrogate the design. You never ask why this database, this pattern, this trade-off. You optimize for throughput.

Honestly? This is perfectly fine for a while. Nobody expects you to match the agent’s raw output speed or carry its encyclopedic knowledge of every framework. If your only goal is absolute scale (ship more, faster, cheaper), you can craft excellent skill.md files, feed the agent the right instructions, and trust it almost blindly to produce working applications. With a small asterisk, but you get the point.

But here’s the warning. If all you do is operate the AI and accept its outputs, you’re a prompt-runner. And a prompt-runner can, and will, be replaced by a motivated middle-schooler.

This isn’t hyperbole. The “prompt engineer” specialty, which was commanding serious salaries just two years ago, has effectively evaporated as a standalone role. Microsoft’s workforce surveys consistently rank it near the bottom of roles companies plan to add. The reason is brutal: as models got dramatically better at intent resolution, the gap between an “expert prompt” and a “decent prompt” shrank to almost nothing. The specialty evaporated because the skill stopped being scarce. Accepting output isn’t a career. It’s a commodity.

I’ve also written about this danger before: the quiet divide between AI operators (fast with prompts, lost when tools fail) and AI-augmented engineers (fast and capable of reasoning from first principles). Both look identical for six months. The gap between them compounds forever after that.

Path 2: The Kolboynik Architect (critical learning)
#

If you want to stay relevant, you have to shift from coder to “Kolboynik”, the Hebrew term for the ultimate generalist who knows a bit of everything, about everything. Not a master of one domain. A master of connecting domains.

The market is already pricing this shift in. Industry analysis is showing a clear trend: demand for roles spanning multiple domains is climbing, while roles with a single narrow skill cluster are falling. The reason is painfully simple: narrow specialization is exactly what AI replicates most efficiently. Depth in one narrow thing doesn’t make you irreplaceable anymore. It makes you replaceable.

Generalists win because they do the thing agents are still bad at. Synthesizing across ambiguous, contradictory, unstructured problem spaces. Bridging systems. Catching second-order effects. Knowing which question to ask next.

Becoming a Kolboynik doesn’t mean you read every book in the library. It means you treat every agent output as a doorway into a new domain you now need to understand just enough to judge. Instead of treating the AI’s output as the finish line, you treat it as the starting point for a deep conversation.

Don’t dive into the lines of code. Zoom out.

Question the design. Why did the agent choose this specific database structure? What alternatives did it silently reject? What would fail at 10x scale?
Challenge the constraints. Ask it about security vulnerabilities, edge cases, cloud costs, compliance implications. Make it show its work.
Interrogate the defaults. Every framework choice is an opinion. Every pattern comes with a cost. If you can’t articulate the trade-off, you don’t understand what shipped.
Guide the process. The agent knows it should write tests. Reminding it sets the standard. Over time, it learns that test coverage is a non-negotiable part of what “done” means on your team.

This deep-dive conversation will probably take longer than the agent took to write the code in the first place. And that is exactly the point. You are the human in the loop, bringing judgment, context, and critical thinking to the table. Everything else got cheap. Judgment is the only thing still scarce.

The cost of skipping the conversation
#

Here’s what the data says about developers who skip the deep-dive and just accept output.

A 2025 MIT Media Lab study found students using AI assistants showed measurably decreased neural engagement and less ownership over their work. Anthropic ran a randomized trial where developers learning a new library with AI scored 17 percentage points lower on mastery than those who learned without it. The biggest gap was in debugging. The one skill you most need when AI-generated code breaks.

More recent research has given this pattern names. Comprehension debt is the gap between how much code you’ve shipped and how much you actually understand. Cognitive debt is the gradual degradation of your team’s problem-solving capability from disuse. Intent debt is the loss of documented rationale in code and commits. The “why” that goes missing when the prompt is the only record.

A 2026 paper on cognitive offloading in agile teams found that AI-only planning significantly degraded risk capture rates. The teams performing best had a hybrid pattern: let AI do estimation and formatting, but require human deliberation for risk assessment and ambiguity resolution. The “boring” cognitive work is exactly the work you can’t offload.

And on the perception side, the numbers keep embarrassing us. Developers feel about 20% faster with AI. Objective measurement shows many of them are actually slower. I’ve referenced METR’s experienced-developer study before: 20% perceived speedup, 19% measured slowdown. The feeling is real. The feeling is wrong.

Karpathy, who literally hasn’t typed a line of code since December 2025, is the clearest voice on what replaces typing. Not passivity. Direction, taste, judgment, oversight, iteration. His own work on MicroGPT was explicitly designed “to demystify the algorithm so both humans and future agents can understand and extend it.” Even the person farthest along the agent curve is obsessed with understanding, not acceptance.

The developers who will compound in value over the next five years aren’t the ones shipping the most agent output. They’re the ones who, for every shipped feature, can also tell you exactly why it exists, what it costs, where it breaks, and what it looked like before they pushed back on the agent’s first answer.

What critical learning looks like in practice
#

This isn’t abstract. It’s a set of small habits you either have or you don’t.

Pause after every accepted suggestion. Before merging an agent’s output, ask yourself one question: if the agent disappeared tomorrow, could I modify this confidently? If no, you haven’t learned anything from this PR. You just shipped borrowed knowledge.

Turn every unfamiliar pattern into a 10-minute tangent. The agent used an event-sourced pattern you’ve never seen? Stop. Ask it to explain why. Ask for two alternatives it considered. Ask for the trade-offs. Ten minutes of critical conversation now beats a 40-hour course later that you’ll never take.

Ask for the rejected options. “What did you consider before choosing this?” is the single highest-leverage prompt I use. It forces the model to expose trade-off space that it otherwise collapses into a confident recommendation.

Argue with the model on purpose. Even when it’s probably right. Especially when it’s probably right. The act of constructing a counter-argument is where your understanding actually forms. A sparring-partner workflow beats a thinking-partner workflow every time, for exactly this reason.

Keep a “things I didn’t know yesterday” log. One file. One line per learning. Review it weekly. It’s the cheapest learning system you’ll ever run, and it’s the closest replacement we have for the structured curriculum that just died.

Re-derive the answer without the model occasionally. The AI-off hours idea I wrote about earlier applies to learning, not just execution. Your mental models don’t build themselves. They atrophy unless you use them.

If that sounds slower than just shipping the agent’s output, it is. By design. Slower code path, faster growth curve. You’re choosing to invest the difference, not spend it.

The big picture
#

We’re past the era where your value was measured by execution speed. Execution is the cheap part now. Generation is the cheap part. First drafts are free.

Your value is now determined by your ability to connect the dots, see the big picture, and deeply understand how systems behave together. It’s determined by the questions you choose to ask, the constraints you choose to enforce, and the second-order effects you choose to catch before they ship. The industry calls this being an AI Architect Programmer. I still prefer Kolboynik. Same idea. Less buzzword.

The good news is better than the bad news
#

Here’s the part I want you to sit with, because it’s easy to miss under all the doom.

The barrier to becoming the best engineer you’ve ever been just collapsed.

Every architectural debate you used to need a senior colleague for? You can have it right now, unlimited, at 2 AM, at whatever depth you want. Every pattern you never got to work on because your team didn’t use it? You can build it, study it, and break it tonight. Every paper, every book, every framework you meant to read? You can now interrogate them chapter by chapter, with the author’s ideas pushed against your specific codebase, in your own words, at your own pace.

The agent is the best teacher any of us have ever had access to. Infinite patience. Infinite availability. Knowledge of every framework, paper, and pattern humanity has written down. No ego. No bad day. It will happily explain the same concept seven different ways until one of them lands.

The only thing it can’t do is decide to learn. That part is still on you. And if you decide to, the growth curve is steeper than anything that came before. Slower code path, faster growth curve. You were never in a better position to become a serious engineer than you are right now. That’s not hype. That’s the actual deal on the table in 2026.

So stop buying 40-hour courses you’ll never finish. Stop pretending that another passive video is the missing piece. The next “thing” ships in three minutes from someone else’s prompt. Your edge isn’t in consuming more theory. It’s in how deeply you engage with what’s already landing in your PRs every single day.

Stop learning syntax. Start learning architecture. The agent has all the answers. You are the only one who knows which questions to ask.

Which path are you on, Operator or Kolboynik? And what’s the last thing the agent taught you that you couldn’t have Googled? Find me on X, Telegram, or LinkedIn. I’d genuinely like to hear it.

Disclaimer: This article references specific studies, surveys, and public commentary for illustrative and educational purposes, including work from Anthropic, METR, MIT Media Lab, Microsoft Research, arXiv preprints, Andrej Karpathy, and industry analyses available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies or tools mentioned. This is commentary, not investment, legal, career, or business advice.

AI Didn't Replace Software Engineering. It Made Bad Engineering Easier to Ship.

Sun, 22 Mar 2026 00:00:00 +0000

Something shifted in the last year and I don’t think enough people are talking about it honestly.

“Ship fast with AI” became the default expectation. Not just in one company. Everywhere. I hear it in conversations with other engineering leaders, I see it in open source repos, I notice it in how people talk about engineering work online. The assumption is that if you’re not shipping faster with AI, you’re falling behind. And if you push back, if you slow down to ask whether anyone actually understands what shipped, you look like you’re blocking progress.

Engineering discipline became a career risk. That’s the shift.

Not because AI is bad. I’m pro-AI. I want teams using it aggressively. But the culture around it drifted somewhere dangerous: we started treating speed as proof of quality, and nobody corrected the mistake because the dashboards looked great.

How the rot works
#

Here’s the chain reaction I keep seeing play out.

It starts with the culture. Leadership sets the tone: adopt AI, move faster, ship more. That’s reasonable. AI does make the mechanical parts of software cheaper. Boilerplate, scaffolding, migrations, glue code, first-pass implementations. All dramatically cheaper now. One strong engineer with the right tools can burn through work that used to take days. That part is real, and teams that ignore it are choosing to be slower for no reason.

But then the culture starts rewarding output over understanding. The engineer who ships three features in a sprint looks more productive than the one who shipped one but thought deeply about failure modes, tested edge cases, and refactored the interface. The first engineer gets praised. The second one gets asked why they’re slower than their peers.

That’s where discipline starts to erode. Not because engineers are lazy. Because the system is telling them that slowing down to think is unproductive. The incentive points at speed, so speed is what you get.

And the quality problems follow, quietly. A January 2026 study on autonomous coding agents found static-analysis warnings rising 18% and cognitive complexity increasing 39%. The researchers called it “sustained agent-induced technical debt even when velocity advantages fade.” That maps exactly to what I see: the code looks fine on the surface, the PR gets approved, the feature ships, and the complexity accumulates in places nobody is watching.

On the security side, recent data shows AI-assisted commits leak secrets at about 2x the baseline rate. Not because the tool is broken. Because humans under time pressure make worse decisions. Speed without discipline creates exposure.

Meanwhile, nobody connects the dots. The velocity charts are green. The sprint burndown looks healthy. But the on-call rotation gets heavier. Rollbacks creep up. The feature that shipped in two days takes two weeks to debug. The Plandek 2026 benchmarks across 2,000+ teams confirmed the pattern at scale: as coding speeds up, the bottleneck just shifts downstream to review, testing, and integration. The slow teams are still slow. They’re just slow in different places now.

And the skill problem compounds it. Anthropic ran a randomized trial where developers learning a new library with AI scored 17 percentage points lower on mastery than those who learned without it. The largest gap was in debugging. The exact skill you need most when AI-generated code breaks. If your engineers aren’t building real understanding, you’re growing people who can ship fast but can’t fix what they shipped.

The whole chain is connected. Culture rewards speed. Speed without understanding produces fragile systems. Fragile systems produce incidents. Incidents expose the gap. But by then, the culture has already moved on to the next sprint.

The perception gap
#

Here’s what makes this so hard to catch from the inside.

Last year, METR ran a study where experienced developers using AI were measured at 19% slower, while believing they were 20% faster. When they tried to rerun it with better tools, developers refused to participate if it meant working without AI. They’re now redesigning the entire experiment because measuring this honestly is harder than anyone expected.

I don’t think the specific numbers matter as much as the pattern: people feel faster. The feeling is real. But feeling and measurement aren’t the same thing. And in a culture that rewards feeling fast, nobody wants to be the person who says “slow down, let’s check.”

Thoughtworks landed on something important in their February 2026 retreat: AI is actually increasing cognitive load, not reducing it. More output, more concurrent problems, more decisions to make. Same human judgment capacity.

Stack Overflow has been tracking what they call the AI trust gap: adoption keeps climbing, trust keeps falling, and the top developer frustration is “almost-right” code that takes longer to verify and fix than it saved to generate.

Everyone knows this. Nobody wants to be the one who says it out loud, because the culture has made saying it feel like resistance.

Most AI agendas are still theater
#

This is the part where I’m going to annoy some people.

A lot of company “AI strategies” aren’t strategies. They’re tool rollouts with executive branding. Buy licenses. Mandate adoption. Count prompts. Celebrate throughput. Post a screenshot in the all-hands. Hope quality survives.

That’s not transformation. That’s procurement.

If your AI agenda starts with “every engineer must use Tool X” and ends before you redesign review standards, testing expectations, security boundaries, knowledge capture, and learning paths for junior engineers, then all you did was change the keyboard.

You didn’t modernize engineering. You industrialized guesswork.

And if the KPI you’re showing upstairs is “percentage of code written by AI”?

That’s one of the dumbest vanity metrics engineering has ever produced.

I don’t care how much code the model wrote. I care whether we understand what we shipped. I care whether it survives production. I care whether the team is getting better, not just faster.

Simon Willison drew the right line between vibe coding and what he now calls “agentic engineering.” If you reviewed, tested, and understood the AI-written code, that’s still software development. The production-grade version of working with AI raises the bar for tests, planning, docs, automation, QA, and review. It doesn’t lower it.

The problem is that a lot of teams adopted the speed without adopting the bar.

What actually needs to change
#

I’ve written before about how the work sequence shifts and what to do about junior engineers in earlier articles. This piece is about the organizational layer, because that’s where the failure is concentrated right now.

Separate prototype mode from production mode. Loose AI prototyping is great for throwaway experiments. It doesn’t belong anywhere near money, customer data, security boundaries, or core workflows.

Make AI transparency normal. If a change was heavily AI-assisted, say so. Show the verification path. Reviewers should know whether they’re looking at a handcrafted change, an AI-assisted draft, or an agent-produced branch. Different creation paths deserve different scrutiny.

Review decisions, not just diffs. Ask why this approach exists. What breaks first. What alternatives were rejected. What do we monitor. If your review culture is still optimized for nit-picking while AI is generating whole subsystems, your process is in the wrong decade.

Measure what matters. Escaped defects. Rework rate. Rollback frequency. MTTR. Time-to-understand for someone new in the codebase. A green AI usage dashboard isn’t evidence that your architecture got better.

Stop rewarding speed without understanding. This is the culture change that matters more than any tool or process. If your system promotes the engineer who ships fastest and ignores the one who catches the architectural flaw before it ships, you’re building the wrong incentives for the AI era.

But honestly? The most important thing you can do isn’t on this list.

Sit down with your team and have an honest conversation about what you actually understand versus what you shipped. Not a retro. Not a metrics review. A real conversation. What did we ship this month that we could confidently debug at 2 AM without the AI? What would break if the model hallucinated something subtle? Where are we trusting output we haven’t verified?

If that conversation is uncomfortable, good. That’s the conversation that needed to happen three months ago.

The craft didn’t change
#

AI changed the toolkit. It changed the speed of first drafts. It changed the sequence of when work happens. It changed how much mechanical effort one good engineer can burn through in a day.

But it didn’t change the craft.

We’re still in the business of turning ambiguity into reliable systems. Still responsible for the trade-offs. Still accountable when the thing breaks. Still need people who understand architecture, testing, operations, failure modes, and human consequences.

The teams that win won’t be the ones that generate the most code. They’ll be the ones that still know what good engineering looks like when the machine gets loud. The ones where discipline isn’t a career risk. The ones where slowing down to think is treated as engineering, not obstruction.

The tool changed. The accountability didn’t.

What’s the worst AI-caused quality problem you’ve seen? Not a hypothetical. A real one. I’d genuinely like to hear it. Find me on X or Telegram.

Disclaimer: This article references specific companies, products, research studies, and industry analyses for illustrative and educational purposes. Information is based on publicly available sources including METR, Plandek, Anthropic, GitClear, GitGuardian, Stack Overflow, and Thoughtworks reporting, available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies mentioned. This is commentary, not investment, legal, or business advice.

Google Stitch Just Made UI Design a Developer Skill

Fri, 20 Mar 2026 10:00:00 +0200

Here’s a number that should make every engineering leader pay attention: 12 seconds.

That’s how long Google Stitch takes to generate a settings page. Complete UI. Interactive prototype. Production-ready React and Tailwind code. Twelve seconds.

The same page takes about 45 minutes in Figma if you know what you’re doing.

When Google announced the March 2026 Stitch updates, Figma’s stock dropped 8.8%. The headlines said “Figma is dead.” Twitter was full of designers updating their LinkedIn profiles. The panic was loud and immediate.

But the panicking people are asking the wrong question. Stitch doesn’t replace designers. It does something more interesting. It makes UI design a developer skill.

What Stitch actually is
#

Stitch is a free, browser-based tool from Google Labs that generates high-fidelity user interfaces from text prompts, voice descriptions, sketches, or uploaded images. It produces both visual designs and synced production code simultaneously. React with Tailwind CSS, HTML/CSS, or Flutter. It exports directly to Figma with proper Auto-Layout applied.

It’s powered by Gemini under the hood. The March 2026 update brought an infinite canvas, voice interaction, a design agent that reasons across your entire project, and something called “Vibe Design” where you describe the feeling you want instead of specifying components.

The GitHub repo has an open-source skills ecosystem for extending it. There’s MCP integration so your AI coding agents in Cursor, Claude Code, or Windsurf can call Stitch directly to generate UI without leaving the IDE.

And it’s completely free. No credits, no subscription. Just a Google account.

Here are some examples of what Stitch generates from simple text prompts. Dashboards, admin panels, e-commerce layouts, mobile feeds. All generated in seconds, all with production-ready React and Tailwind code behind them:

Scroll to see more. Each screen generated by Stitch from a text description.

These aren’t mockups I made in Figma. The code behind each screen is production-ready React with Tailwind CSS.

Why developers should care more than designers
#

The design community is having the wrong conversation. They’re debating whether Stitch replaces Figma. It doesn’t. Figma is where serious design collaboration, brand refinement, and complex design system work happens. That’s not going anywhere.

The real shift is on the developer side.

Think about the typical flow in most engineering orgs. A product manager writes requirements. A designer creates mockups in Figma. Those mockups go through review cycles. Eventually they land in front of a developer who translates them into code. That translation process is where things get lost. The spacing is wrong. The colors are close but not exact. The responsive behavior wasn’t specified. The developer interprets, the designer reviews, and the cycle repeats.

Stitch compresses that entire pipeline into a conversation with an AI. A developer can describe what they need, get an interactive prototype in seconds, iterate by talking to the canvas, and export production-ready code. No design tool proficiency required. No translation layer. No interpretation gap.

For engineering teams, this changes three things:

Prototyping becomes instant. When you’re evaluating an approach, testing a user flow, or building an internal tool, you don’t need a designer in the loop for the first draft. You describe what you want, get something real, and iterate from there. The feedback loop goes from days to minutes.

Internal tools stop looking terrible. Every engineering org has internal dashboards and admin panels that look like they were designed in 2008. Nobody allocates design resources to internal tools. With Stitch, a developer can generate a clean, professional UI for an internal tool in the time it used to take to write the boilerplate HTML.

The design-to-code gap shrinks. When the same tool produces both the visual design and the code, there’s no translation error. The code matches the design because they’re the same artifact. That alone saves hours of back-and-forth on every feature.

How it fits into the AI app builder landscape
#

Stitch is not the only tool in this space, and understanding where it sits matters.

Stitch is design-first. It generates polished UI and exports frontend code. It does not build backends, databases, authentication, or deploy anything. It’s the design and frontend layer only.

Lovable is app-first. It builds complete full-stack applications. Frontend, backend on Supabase, database, authentication, one-click deployment. If you want to go from idea to deployed MVP, Lovable does the whole thing. The UI won’t be as polished as Stitch, but you get a working app.

Bolt.new is code-first. A browser-based development environment from StackBlitz. It generates full projects with real-time preview and flexible framework choices. More control than Lovable, but you need developer skills for backend and deployment.

v0 (Vercel) is component-first. It generates clean React components that drop into existing codebases. Less about full-page design, more about generating specific UI components with good code quality.

Google AI Studio is prototype-first. It generates code and runs a preview you can share. More interactive than Stitch but less design-focused. It’s the middle ground between designing a UI and building a working app.

Firebase Studio is production-first. Full developer environment with terminal, dependencies, and deployment pipeline. The tool for when you’re past prototyping and building for real.

The pattern: Stitch handles the “zero to design” phase better than anything else. But it hands off before the “design to production” phase. For teams that already have a development pipeline, that handoff is natural. For solo builders who want everything in one tool, Lovable or Bolt are better fits.

The MCP integration is the sleeper feature
#

Most coverage of Stitch focuses on the canvas, the voice interaction, and the Figma export. The feature that matters most for developers gets buried in the docs.

Stitch has an MCP server. That means your AI coding agent in Cursor, Claude Code, Windsurf, or any MCP-compatible IDE can call Stitch directly to generate UI components as part of a coding workflow.

Think about what that means. You’re building a feature in Cursor. Your agent needs a dashboard layout. Instead of switching to a browser, opening Stitch, generating the design, and copying the code back, the agent calls Stitch as a tool, gets the component, and drops it into your codebase. All without leaving the IDE.

There’s also a “Design DNA” feature that extracts design context (colors, typography, structure) from generated screens and feeds it to the agent. So subsequent screens maintain visual consistency automatically. And DESIGN.md exports your design system as a portable file that can be imported into other projects.

For anyone already running AI agents in their development workflow (and you know I am), this is where Stitch stops being a design tool and starts being infrastructure.

Will it replace UI/UX designers?
#

No. But it will change what they spend their time on.

Stitch eliminates the blank canvas problem. The first draft, the initial layout, the “let me explore three different approaches” phase. That used to take hours or days. Now it takes seconds.

What Stitch can’t do is brand identity. Design systems that feel cohesive across an entire product. The subtle decisions about hierarchy, rhythm, and emotional response that make the difference between a functional interface and one that people love using. The output quality is good, sometimes surprisingly good, but it lacks the refined aesthetic that an experienced designer brings to high-end work.

The honest assessment: Stitch handles 0-to-1 better than any tool I’ve seen. But 1-to-100, the refinement that turns a prototype into a polished product, still needs a human designer. Probably in Figma.

The real shift for design teams is that the bar for “good enough” just moved dramatically. Internal tools, admin panels, MVPs, quick prototypes, landing pages. All of these used to need designer time. Now they don’t. That frees designers to focus on the work that actually needs their taste and judgment.

For managers, the question isn’t “should we fire our designers?” It’s “what should our designers stop doing so they can focus on what only they can do?”

The limitations nobody’s hyping
#

85% accuracy in standard mode. That means roughly 1 in 6 components won’t be quite right. The experimental mode hits 95% but takes 45 seconds instead of 12. For prototyping that’s fine. For production you’re editing either way.

No backend. Stitch generates beautiful frontends that don’t do anything. No API calls, no state management beyond the UI, no data persistence. You need a developer to wire it up.

Free comes with a question mark. It’s a Google Labs product. Google has a history of killing Labs experiments. If you build workflows around Stitch, you’re betting Google keeps investing in it. The free pricing is great today, but there’s no guarantee about tomorrow.

The “vibe design” concept has limits. Describing a feeling works for simple pages. For complex enterprise UIs with dozens of states, error handling, and edge cases, you still need to be specific. The AI can’t infer your business logic from a vibe.

What this means for engineering orgs
#

Every few years, a tool shifts the boundary between what developers can do without specialist help and what requires a dedicated team.

GitHub Copilot shifted the boundary on code generation. Terraform shifted it on infrastructure. CI/CD platforms shifted it on deployment. Each time, the specialists didn’t disappear. They moved up the stack to harder problems.

Stitch is shifting the boundary on UI design. Developers can now produce professional-quality interfaces without design training. That doesn’t eliminate designers. It eliminates the bottleneck where developers wait for design input on work that didn’t need a designer’s taste in the first place.

For engineering leaders, the practical implications are:

Evaluate Stitch for internal tooling. If your team builds admin panels, dashboards, or internal tools, Stitch can compress the UI phase from days to hours. The ROI is immediate.

Integrate through MCP. If you’re already running AI agents in your development workflow, add Stitch as a tool. Let your agents generate UI components as part of the coding flow. The context switching savings alone are worth it.

Rethink the designer-to-developer ratio. If developers can handle the first 80% of UI work, your designers can focus on the 20% that actually needs their expertise. That’s a better use of everyone’s time.

Don’t bet everything on it. It’s a Google Labs product. It’s free. It’s excellent. And it could get shut down, pivoted, or monetized at any point. Use it as a tool in your toolkit, not the foundation of your process.

The wall between design and code has been getting thinner for years. Stitch didn’t remove it. But it put a very large door in it. And for engineering teams, that door is wide open.

Using Stitch in your development workflow? Integrating it with AI coding agents? I’d love to hear how you’re using it. Find me on X or Telegram.

Your AI Agents Are Flying Blind. Here's How to Fix That.

Sun, 15 Mar 2026 10:00:00 +0200

Your AI agent just rewrote the authentication flow. The code is clean. Tests pass. The PR looks great.

One problem: it broke the SSO integration with three enterprise customers because it didn’t know the auth service has a contract with the identity provider that requires a specific token format. That contract lives in a Slack thread from 2023 and one engineer’s head.

The agent didn’t make a mistake. It made a perfectly reasonable decision with the information it had. The information it had was almost nothing.

This is happening across your codebase right now. Not just with authentication. With everything. Business rules, API contracts, deployment constraints, database conventions, service boundaries. Your agents write code that compiles, passes tests, and violates assumptions that live nowhere except in people’s heads and scattered documents nobody maintains.

I’ve written about why context is the fundamental problem in AI. I’ve written about putting AI agents on the org chart and managing them like team members. But none of that matters if the agents start every session blind.

If you’re running agents in production, this is the problem you need to solve next.

Two teams, same agents, wildly different results
#

Let me describe what I’m seeing.

Team A has agents embedded in their development workflow. An agent picks up a ticket to add a new validation rule to the user registration flow. Before writing a line of code, it queries a knowledge base and gets back: the existing validation rules, the reason the email format check is stricter than RFC 5322 (because of a legacy migration), the API contract with the notification service, and the team’s convention for error handling. The agent writes code that fits. The PR gets approved on the first review.

Team B has the exact same agents, same models, same IDE. Their agent picks up a similar ticket. It reads the code in the repo, sees patterns, generates a solution. The solution uses a different error handling pattern than the rest of the codebase. It changes the validation response format, which breaks the mobile client. It adds a database column without following the team’s migration conventions. The PR gets three rounds of review comments and a refactor.

Same AI. Same capability. Completely different outcomes.

The difference isn’t the model. It’s that Team A solved the knowledge problem and Team B didn’t.

Where knowledge actually lives (and why that’s broken)
#

In most engineering organizations, critical knowledge is scattered across:

People’s heads. The worst possible storage medium.
Slack threads. Searchable in theory, buried in practice.
Confluence pages. Written once, updated never.
Code comments. Spotty at best, misleading at worst.
Tribal knowledge. “Ask Daniel, he built that service.”

None of this is accessible to AI agents. None of it is structured for retrieval. None of it stays current.

And here’s the compounding problem: as AI agents do more work, the knowledge gap matters more, not less. When humans wrote all the code, at least the person writing it carried the context. When agents write the code, the context has to come from somewhere else. Or it doesn’t come at all.

Think about it this way: a senior developer who’s been on your team for three years carries hundreds of micro-decisions in their head. Why the payment service retries exactly three times. Why the user permissions check happens at the API gateway, not the service layer. Why that database query uses a specific index hint. Now imagine replacing that developer with an agent that knows none of this. That’s what you’re doing every time an agent starts a session.

The wrong way to fix this
#

The instinct is to throw more code at the agent. Bigger context windows. More files in the prompt. RAG over the entire codebase.

I’ve seen teams try this. Here’s what happens:

They dump the entire repo into the context. The agent drowns in irrelevant code and can’t find the signal, and every token costs money, so you’re paying premium rates to confuse your own agents. They build RAG over Confluence. The retrieval returns pages from 2021 that contradict how things actually work. They write massive README files. Nobody maintains them. Within three months they’re more misleading than helpful.

And the costs compound. More tokens in the context means higher API bills on every single request. Bad context leads to wrong code, which leads to longer review cycles, which leads to rework, which means more agent sessions with the same bad context. It’s compound interest working against you. Every layer of waste multiplies the next.

The problem isn’t volume of information. It’s the right information, maintained, structured, and delivered at the moment the agent needs it. Get this wrong and you’re not just getting bad code. You’re paying more for it with every iteration.

What actually works: a developer knowledge hub
#

After months of thinking about this problem and looking at how every available solution falls short, I believe the answer is a system with three components that work together.

Layer 1

Source of Truth

📁

Knowledge Repo (Git)
Developers author markdown: product rules, system docs, architecture specs, skills

▼ CI/CD syncs on every merge ▼

Layer 2

Index & Push

🔍

Vector Store + Embeddings
Chunk, embed, index → semantic search

📄

AGENTS.md + Skills per repo
Generated context + reusable workflows

▼ Serves queries at dev time ▼

Layer 3

Universal Bridge

🔌

MCP Server
One server → every IDE & agent can query knowledge

▼

Consumers

All tools

💻

Cursor Claude Code Copilot Codex Kiro + any future MCP-compatible tool

Git for authoring
#

Not Confluence. Not Notion. Not some SaaS product with its own editing UI.

A Git repository. Markdown files. Pull requests for review. CI/CD for automation. The same workflow developers already use for code.

Why Git? Because the adoption problem kills every knowledge initiative that requires developers to learn a different tool. PRs already have review workflows. Blame shows who wrote what. History shows when things changed. CODEOWNERS controls who can approve what. Your developers already know all of this. Zero adoption friction.

The repo holds four types of knowledge:

Product knowledge. Business rules, domain logic, edge cases, validation requirements. Why the user registration flow requires that specific email format. Why the discount calculation has a different rounding rule for enterprise customers. This changes every sprint.

System knowledge. Build commands, repo structure, coding conventions, database patterns, module boundaries. Why you always run migrations before the test suite. Why the cache invalidation uses event sourcing instead of TTL. This changes when code changes.

Architecture knowledge. API contracts, data flows, service boundaries, system invariants. Why the payment service is the only service allowed to write to the transactions table. Why the notification queue has exactly-once delivery semantics. This changes rarely but matters enormously.

Operational skills. Code review checklists, debugging guides, feature scaffolding patterns, cross-repo change workflows. How to add a new API endpoint. How to set up a feature flag. How to run a database migration across services. How the CI/CD pipeline works, which checks run on PR, which run on merge, what gates production. How linting and formatting are enforced and what to do when a check fails. How to roll back a deployment. How to triage a failing build. These are reusable agent workflows that encode how your team actually works. Not just the code, but the entire delivery process around it.

One thing you’ll notice is missing from this list: the code itself. That’s intentional. AI IDEs and coding agents like Cursor, Copilot, and Claude Code already do a solid job indexing your codebase. They understand file structure, imports, function signatures. You don’t need to duplicate that work. What they can’t index is everything around the code. The why, the rules, the decisions. That’s what the knowledge hub is for. That said, the system is designed to be agile. If you want to add code indexing, documentation from other sources, or any other category of data, the architecture supports it. Same Git authoring, same search layer, same MCP delivery.

Semantic search for retrieval
#

Raw markdown is great for humans. Useless for agents that need to find the right three paragraphs out of thousands for a specific task.

This layer chunks the markdown by section, embeds it into vectors, and indexes it for semantic retrieval. When an agent asks “what are the validation rules for the registration flow?” it gets the relevant sections, with citations back to the source documents.

AWS Bedrock Knowledge Bases does this out of the box. So does Pinecone, Weaviate, or any vector store with a decent chunking strategy. The specific tool doesn’t matter. What matters is that knowledge becomes semantically searchable, not just keyword-matchable.

CI/CD syncs markdown to the search index on every merge. Knowledge stays current automatically. No manual re-indexing. No stale embeddings.

MCP for delivery
#

Here’s where it comes together.

Your developers use Cursor, Claude Code, Copilot, Codex, Kiro. Probably several of them. Each one is an island. Each one starts every session without context.

Model Context Protocol (MCP) is the open standard that connects all of them. I wrote a deep dive on MCP earlier. If you haven’t read it, start there.

One MCP server wraps your knowledge base and exposes it to every IDE and agent through a standard interface. Build one server. Every tool connects natively. New tools that support MCP work automatically. Zero per-tool maintenance.

The server exposes three tools: search_knowledge for semantic search across all knowledge, get_document to fetch a specific doc by path, and list_knowledge_bases to discover available sources. Simple interface, massive impact.

Without MCP: You build a separate integration for each IDE. Maintain six connectors. Each tool gets knowledge differently. Every new tool means new work.

With MCP: You build one server. Everything connects. When the next AI coding tool launches next month, it just works.

The loop that makes it compound
#

Here’s where this gets really powerful. The system doesn’t just serve knowledge. It grows.

🔍

Read

Agent queries KB
via MCP

→

💻

Work

Develops with
full context

→

📝

Write Back

Opens PR to
knowledge repo

→

✅

Merge

Dev reviews
CI re-indexes

↩

🔄

Updated

Next session
starts smarter

Fully automated. No manual curation. Knowledge grows as the team develops.

The workflow in detail:

Agent reads. Before starting work, queries the knowledge base via MCP. Gets business rules, conventions, architecture constraints relevant to the task.
Agent works. Develops with full context. The code actually follows the patterns and rules.
Agent writes back. A built-in skill instructs the agent to capture what it learned during development and open a PR to the knowledge repo.
Developer reviews. Standard PR review. Approves or refines the knowledge doc.
CI syncs. Merged knowledge is automatically indexed. Next agent session starts smarter.

Knowledge capture becomes part of development, not a separate chore. The developer just reviews. No separate authoring step.

There’s a sixth step that takes this even further. When new knowledge merges, a CI step can run an LLM over the diff and ask: “What else in the entire knowledge base might be affected by this change?” Remember, this is a centralized system across all your repos. A change to how one service handles authentication could affect product knowledge for three other services, architecture docs for the API gateway, and operational skills for the deployment pipeline. The system uses embeddings to find related documents across every domain, checks for contradictions or staleness, and opens follow-up issues flagging what might need updating. Ripple effect detection across your entire engineering knowledge. You update the validation rules for user registration, and the system flags that the API contract doc, the mobile client integration guide, and the error handling conventions might all need a second look. It’s cheap to run and catches the kind of cross-cutting knowledge drift that humans miss because nobody has visibility into every document across every team.

Every feature built makes the next feature easier. Every agent session makes the next session smarter. The knowledge compounds.

The AGENTS.md safety net
#

Not every agent session has MCP access. Sometimes developers work offline. Sometimes a new tool doesn’t support MCP yet. Sometimes the knowledge server is down.

For these cases, CI generates a lightweight AGENTS.md in each repo. It’s a table of contents for the agent: what this repo does, how to build and test it, architecture boundaries, conventions and constraints, and where to find the full knowledge base.

Think of it as the offline fallback. Agents get essential context even without network access. Push model (always in-repo) complementing the pull model (on-demand via MCP).

Why nothing on the market solves this
#

I looked at many solutions out there. Each solves a piece, and the approach I’m describing borrows the best parts from all of them.

Meta-repos (centralized Git docs). Git-native authoring, but no semantic search. Agents can’t find what they need.

Wiki + RAG (Confluence/Notion with retrieval). Searchable, but not Git-native. Developers won’t update it. Knowledge rots within months.

Code wikis (auto-generated from code). Clever, but usually tied to one AI tool. Not universal.

Cloud RAG services (Bedrock KB, Vertex). Managed search, but no authoring story. Where does the content come from?

Agent memory (Copilot memory, Letta). Per-tool, per-session. Not centralized. Not shared across the team.

You need all five capabilities in one system. That’s what this approach delivers.

How to start (without boiling the ocean)
#

Day 1: Create the knowledge repo. Sit with your two or three most senior engineers, the ones who carry the most context in their heads. Ask them: “What do you find yourself explaining over and over?” That’s your first knowledge document.

Day 2-3: Set up semantic search. Connect your markdown to a vector store. Get retrieval working. This is not a multi-week project. The tooling exists. Use it.

Day 4-5: Deploy the MCP server. Configure it in your team’s primary IDE. Have a developer pair with an agent on a real task and compare the output to what they’d get without the knowledge base. That’s your first signal.

Week 2: Add the write-back loop. Build the skill that instructs agents to capture knowledge after completing work. Train your developers on how to review knowledge PRs, not just code PRs. This is where it starts compounding.

The technology side of this is days of work. The harder part is getting your team to treat knowledge as a first-class deliverable, not an afterthought. That’s a leadership problem, not a tooling problem. But once developers see their agents producing better code because someone took 20 minutes to document business rules, the culture shift happens on its own.

We’re in the AI era. If the infrastructure takes you months, you’re overengineering it. Get something working in days, iterate from there. The humans will make it great.

The key insight: start with the knowledge that hurts most when it’s missing. That’s usually the domain logic, the business rules that experienced developers carry in their heads and that agents get wrong in ways that look correct until they hit production.

The uncomfortable question
#

If your AI agents are generating code without context, how much of that code is actually correct?

Not “does it compile” correct. Not “does it pass the tests you wrote” correct. Actually correct. Follows the business rules, respects the architecture, uses the conventions, handles the edge cases that burned you last quarter.

If you can’t answer that confidently, your agents aren’t helping as much as you think. They’re generating plausible-looking code that somebody has to review against all the unwritten knowledge that exists only in people’s heads. And you’re paying for every token of that wrong output, then paying again for the review, again for the rework, and again when the agent generates the same mistake tomorrow because nothing changed.

That’s not an AI problem. That’s a knowledge management problem. And it’s solvable.

The organizations that figure this out first will have AI agents that don’t just write code. They write the right code. Every time. From session one.

That’s the difference between AI as a novelty and AI as a genuine multiplier. And it’s what separates teams that are actually shipping with agents from teams that are just generating code and hoping for the best.

Building knowledge systems for AI agents? Thinking about MCP? I’d love to hear how you’re approaching it. Find me on X or Telegram.

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.

Ship Faster Without Breaking Things: DORA 2025 in Real Life

Sat, 04 Oct 2025 00:00:00 +0000

Last year, teams using AI shipped slower and broke more things. This year, they’re shipping faster, but they’re still breaking things. The difference between those outcomes isn’t the AI tool you picked—it’s what you built around it.

The 2025 DORA State of AI-assisted Software Development Report introduces an AI Capabilities Model based on interviews, expert input, and survey data from thousands of teams. Seven organizational capabilities consistently determine whether AI amplifies your effectiveness or just amplifies your problems.

This isn’t about whether to use AI. It’s about how to use it without making everything worse.

First, what DORA actually measures
#

DORA is a long-running research program studying how software teams ship and run software. It measures outcomes across multiple dimensions:

Organizational performance – business-level impact
Delivery throughput – how fast features ship
Delivery instability – how often things break
Team performance – collaboration and effectiveness
Product performance – user-facing quality
Code quality – maintainability and technical debt
Friction – blockers and waste in the development process
Burnout – team health and sustainability
Valuable work – time spent on meaningful tasks
Individual effectiveness – personal productivity

These aren’t vanity metrics. They’re the lenses DORA uses to determine whether practices help or hurt.

What changed in 2025
#

Last year: AI use correlated with slower delivery and more instability.

This year: Throughput ticks up while instability still hangs around.

In short, teams are getting faster. The bumps haven’t disappeared. Environment and habits matter a lot.

The big idea: capabilities beat tools
#

DORA’s 2025 research introduces an AI Capabilities Model. Seven organizational capabilities consistently amplify the upside from AI while mitigating the risks:

Clear and communicated AI stance – everyone knows the policy
Healthy data ecosystems – clean, accessible, well-managed data
AI-accessible internal data – tools can see your context safely
Strong version control practices – commit often, rollback fluently
Working in small batches – fewer lines, fewer changes, shorter tasks
User-centric focus – outcomes trump output
Quality internal platforms – golden paths and secure defaults

These aren’t theoretical. They’re patterns that emerged from real teams shipping real software with AI in the loop.

Below are the parts you can apply on Monday morning.

1. Write down your AI stance
#

Teams perform better when the policy is clear, visible, and encourages thoughtful experimentation. A clear stance improves individual effectiveness, reduces friction, and even lifts organizational performance.

Many developers still report policy confusion, which leads to underuse or risky workarounds. Fixing clarity pays back quickly.

Leader move
#

Publish the allowed tools and uses, where data can and cannot go, and who to ask when something is unclear. Then socialize it in the places people actually read—not just a wiki page nobody visits.

Make it a short document:

What’s allowed: Which AI tools are approved for what use cases
What’s not allowed: Where the boundaries are and why
Where data can go: Which contexts are safe for which types of information
Who to ask: A real person or channel for edge cases

Post it in Slack, email it, put it in onboarding. Make not knowing harder than knowing.

2. Give AI your company context
#

The single biggest multiplier is letting AI use your internal data in a safe way. When tools can see the right repos, docs, tickets, and decision logs, individual effectiveness and code quality improve dramatically.

Licenses alone don’t cut it. Wiring matters.

Developer move
#

Include relevant snippets from internal docs or tickets in your prompts when policy allows. Ask for refactoring that matches your codebase, not generic patterns.

Instead of:

Write a function to validate user input

Try:

Write a validation function that matches our pattern in
docs/validators/base.md. It should use the same error
handling structure we use elsewhere and return ValidationResult.

Context makes the difference between generic code and code that fits.

Leader move
#

Prioritize the plumbing. Improve data quality and access, then connect AI tools to approved internal sources. Treat this like a platform feature, not a side quest.

This means:

Audit your data: What’s scattered? What’s duplicated? What’s wrong?
Make it accessible: Can tools reach the right information safely?
Build integrations: Connect approved AI tools to your repos, docs, and systems
Measure impact: Track whether context improves code quality and reduces rework

This is infrastructure work. It’s not glamorous. It pays off massively.

3. Make version control your safety net
#

Two simple habits change the payoff curve:

Commit more often
Be fluent with rollback and revert

Frequent commits amplify AI’s positive effect on individual effectiveness. Frequent rollbacks amplify AI’s effect on team performance. That safety net lowers fear and keeps speed sane.

Developer move
#

Keep PRs small, practice fast reverts, and do review passes that focus on risk hot spots. Larger AI-generated diffs are harder to review, so small batches matter even more.

Make this your default workflow:

Commit after every meaningful change, not just when you’re “done”
Know your rollback commands by heart: git revert, git reset, git checkout
Break big AI-generated changes into reviewable chunks before opening a PR
Flag risky sections explicitly in PR descriptions

When AI suggests a 300-line refactor, don’t merge it as one commit. Break it into logical pieces you can review and revert independently.

4. Work in smaller batches
#

Small batches correlate with better product performance for AI-assisted teams. They turn AI’s neutral effect on friction into a reduction. You might feel a smaller bump in personal effectiveness, which is fine—outcomes beat output.

Team move
#

Make “fewer lines per change, fewer changes per release, shorter tasks” your default.

Concretely:

Set a soft limit on PR size (150-200 lines max)
Break features into smaller increments that ship value
Deploy more frequently, even if each deploy does less
Measure cycle time from commit to production, not just individual velocity

Small batches reduce review burden, lower deployment risk, and make rollbacks less scary. When AI is writing code, this discipline matters more, not less.

5. Keep the user in the room
#

User-centric focus is a strong moderator. With it, AI maps to better team performance. Without it, you move quickly in the wrong direction.

Speed without direction is just thrashing.

Leader move
#

Tie AI usage to user outcomes in planning and review. Ask how a suggestion helps a user goal before you celebrate a speedup.

In practice:

Start feature discussions with the user problem, not the implementation
When reviewing AI-generated code, ask “Does this serve the user need?”
Measure user-facing outcomes (performance, success rates, satisfaction) alongside velocity
Reject optimizations that don’t trace back to user value

AI is good at generating code. It’s terrible at understanding what your users actually need. Keep humans in the loop for that judgment.

6. Invest in platform quality
#

Quality internal platforms amplify AI’s positive effect on organizational performance. They also raise friction a bit, likely because guardrails block unsafe patterns.

That’s not necessarily bad. That’s governance doing its job.

Leader move
#

Treat the platform as a product. Focus on golden paths, paved roads, and secure defaults. Measure adoption and developer satisfaction.

What this looks like:

Golden paths: Make the secure, reliable, approved way also the easiest way
Good defaults: Bake observability, security, and reliability into templates
Clear boundaries: Make it obvious when someone’s about to do something risky
Fast feedback: Catch issues in development, not in production

When AI suggests code, a good platform will catch problems early. It’s the difference between “this breaks in production” and “this won’t even compile without the right config.”

7. Use value stream management so local wins become company wins
#

Without value stream visibility, AI creates local pockets of speed that get swallowed by downstream bottlenecks. With VSM, the impact on organizational performance is dramatically amplified.

If you can’t draw your value stream on a whiteboard, start there.

Leader move
#

Map your value stream from idea to production. Identify bottlenecks. Measure flow time, not just individual productivity.

Questions to answer:

How long does it take an idea to reach users?
Where do handoffs slow things down?
Which stages have the longest wait times?
Is faster coding making a difference at the business layer?

When one team doubles their velocity but deployment still takes three weeks, you haven’t improved the system. You’ve just made the queue longer.

VSM makes the whole system visible. It’s how you turn local improvements into company-level wins.

Quick playbooks
#

For developers
#

Commit smaller, commit more, and know your rollback shortcut.
Add internal context to prompts when allowed. Ask for diffs that match your codebase.
Prefer five tiny PRs over one big one. Your reviewers and your on-call rotation will thank you.
Challenge AI suggestions that don’t trace back to user value. Speed without direction is waste.

For engineering leaders
#

Publish and socialize an AI policy that people can actually find and understand.
Fund the data plumbing so AI can use internal context safely. This is infrastructure work that pays compound returns.
Strengthen the platform. Measure adoption and expect a bit of healthy friction from guardrails.
Run regular value stream reviews so improvements show up at the business layer, not just in the IDE.
Tie AI adoption to outcomes, not just activity. Measure user-facing results alongside velocity.

The takeaway
#

AI is an amplifier. With weak flow and unclear goals, it magnifies the mess. With good safety nets, small batches, user focus, and value stream visibility, it magnifies the good.

The 2025 DORA report is very clear on that point, and it matches what many teams feel day to day: the tool doesn’t determine the outcome. The system around it does.

You can start on Monday. Pick one capability, make it better, measure the result. Then pick the next one.

That’s how you ship faster without breaking things.

Want the full data? Download the complete 2025 DORA State of AI-assisted Software Development Report.

Build Your First AI Agent This Week: A Practical Guide

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

In my previous article, I covered what makes AI agents different and which platforms are worth using. Now it’s time to actually build one.

This isn’t theory. This is the practical path to shipping your first useful agent in seven days. Real steps, real code patterns, real deployment.

Day 1: Pick a problem that won’t waste your time
#

The most common mistake is picking the wrong first problem. Too ambitious, too vague, or too risky. You want something that teaches you how agents work without creating a disaster if it fails.

The criteria that matter:

Repetitive and annoying. Something you or your team does regularly and wish you didn’t. The kind of task where you know you’ll use the agent because the manual version is painful.

Multi-step with clear logic. It needs to check multiple sources or make decisions based on what it finds. Otherwise, you don’t need an agent, you need a function.

Low stakes. Mistakes are annoying but not catastrophic. No customer-facing systems, no data deletion, no money movement.

Well-defined success. You can describe what “done” looks like in concrete terms. Vague goals produce vague agents.

Good first problems:

Weekly engineering status report. Query your project management tool for completed tickets, check Git for merged PRs, pull highlights from meeting notes, and generate a summary. Multiple data sources, clear output format, low risk.

Pull request pre-review. Check new PRs for common issues before human review: missing tests, documentation gaps, security patterns, code style. Clear checks, actionable output, saves reviewer time.

Production health check. Monitor key metrics across your services, check error rates and latency, identify anomalies, and escalate only when thresholds are crossed. Defined logic, measurable impact.

Support ticket triage. Read incoming tickets, categorize by type, check for similar past issues, route to the right team, and flag urgent cases. Clear workflow, easy to validate.

Bad first problems:

Autonomous customer support. Too high stakes. Customers see the output directly. Requires judgment and empathy that agents don’t have.

Writing production code without review. You’re trusting an agent with your system’s reliability before you understand how agents fail. That’s backwards.

Making architectural decisions. Agents can gather information, but they can’t make taste-based trade-offs or understand your business context deeply enough.

Pick your problem now. Write down the specific task, the data sources it needs, and what the output should look like. Be concrete.

Day 2: Set up your environment and tools
#

You have two main paths: managed platforms (fast but less control) or open-source frameworks (more work, more flexibility).

Path A: OpenAI Agents SDK (fastest start)
#

When to choose this: You want to build something working today and don’t mind vendor lock-in.

Setup:

pip install openai

Create an API key from OpenAI’s platform, set it as an environment variable:

export OPENAI_API_KEY='your-key-here'

First test:

from openai import OpenAI

client = OpenAI()

# Simple function calling example
def get_ticket_count(status):
 # Your actual logic here
 return {"status": status, "count": 42}

response = client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": "How many open tickets?"}],
 tools=[{
 "type": "function",
 "function": {
 "name": "get_ticket_count",
 "description": "Get count of tickets by status",
 "parameters": {
 "type": "object",
 "properties": {
 "status": {"type": "string", "enum": ["open", "closed", "pending"]}
 },
 "required": ["status"]
 }
 }
 }]
)

print(response)

If that runs without errors, you’re ready.

Path B: LangGraph (maximum control)
#

When to choose this: You want to understand how agents work at a deeper level, need to avoid vendor lock-in, or have requirements that managed platforms can’t meet.

Setup:

pip install langgraph langchain-openai langsmith

You’ll still need an OpenAI API key (or use Anthropic, Gemini, or local models). Set up LangSmith for observability (free tier is fine):

export LANGCHAIN_API_KEY='your-langsmith-key'
export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_PROJECT='my-first-agent'

First test:

from langgraph.graph import StateGraph, END
from typing import TypedDict

class State(TypedDict):
 messages: list
 next_step: str

def analyze(state):
 return {"next_step": "complete"}

graph = StateGraph(State)
graph.add_node("analyze", analyze)
graph.set_entry_point("analyze")
graph.add_edge("analyze", END)

app = graph.compile()

result = app.invoke({"messages": [], "next_step": ""})
print(result)

If that runs, you’re good.

Connect to your actual data
#

Don’t build against mock data. Use real systems from day one, but safely.

Use MCP servers (covered in my MCP article) to connect to:

Your filesystem (code, documentation)
Your databases (read-only credentials on development instances)
Your Git repository
Your project management tools

Install basic MCP servers:

# Filesystem access
npm install -g @modelcontextprotocol/server-filesystem

# PostgreSQL access
npm install -g @modelcontextprotocol/server-postgres

# Git repository access
npm install -g @modelcontextprotocol/server-git

Configure them in your Claude Desktop or connect them programmatically in your agent code.

Day 3-4: Build the minimal viable agent
#

Start simple. Don’t try to handle every edge case or build the perfect architecture. Build something that works for the happy path.

Define your tools clearly
#

Each tool should do one thing well. Clear inputs, clear outputs, clear purpose.

Example: Status report agent tools

def get_completed_tickets(days=7):
 """Get tickets completed in the last N days"""
 # Query your project management API
 # Return: list of {id, title, assignee, completed_date}
 pass

def get_merged_prs(days=7):
 """Get PRs merged in the last N days"""
 # Query GitHub API or use Git MCP server
 # Return: list of {pr_number, title, author, merged_date}
 pass

def get_meeting_highlights(days=7):
 """Extract highlights from meeting notes"""
 # Read meeting notes from your docs system
 # Return: list of highlight strings
 pass

Keep them focused. One tool shouldn’t try to do everything.

Write explicit prompts
#

Tell the agent exactly what you want. Agents don’t read between the lines well.

Bad prompt:

"Generate a status report"

Good prompt:

You are a status report generator for the engineering team.
Your task:
1. Get all tickets completed in the last 7 days
2. Get all PRs merged in the last 7 days
3. Get highlights from team meetings
4. Generate a summary in this format:
## Completed This Week
- [Ticket list with assignees]
## Shipped Features
- [PR list with authors]
## Team Updates
- [Meeting highlights]
Be concise. Focus on user-visible impact.

Specificity matters enormously.

Wire it together: OpenAI example
#

from openai import OpenAI

client = OpenAI()

tools = [
 {
 "type": "function",
 "function": {
 "name": "get_completed_tickets",
 "description": "Get tickets completed in the last N days",
 "parameters": {
 "type": "object",
 "properties": {
 "days": {"type": "integer", "default": 7}
 }
 }
 }
 },
 # Define other tools similarly
]

messages = [
 {
 "role": "system",
 "content": "You are a status report generator..." # Full prompt here
 },
 {
 "role": "user",
 "content": "Generate this week's status report"
 }
]

response = client.chat.completions.create(
 model="gpt-4o",
 messages=messages,
 tools=tools
)

# Handle tool calls
while response.choices[0].finish_reason == "tool_calls":
 tool_call = response.choices[0].message.tool_calls[0]

 # Execute the requested tool
 if tool_call.function.name == "get_completed_tickets":
 result = get_completed_tickets()

 messages.append(response.choices[0].message)
 messages.append({
 "role": "tool",
 "tool_call_id": tool_call.id,
 "content": str(result)
 })

 response = client.chat.completions.create(
 model="gpt-4o",
 messages=messages,
 tools=tools
 )

print(response.choices[0].message.content)

Wire it together: LangGraph example
#

from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolExecutor
from langchain_openai import ChatOpenAI
from langchain.tools import tool

@tool
def get_completed_tickets(days: int = 7) -> list:
 """Get tickets completed in the last N days"""
 # Your implementation
 return []

tools = [get_completed_tickets]
tool_executor = ToolExecutor(tools)

class State(TypedDict):
 messages: list
 next_action: str

def call_agent(state):
 llm = ChatOpenAI(model="gpt-4o")
 llm_with_tools = llm.bind_tools(tools)
 response = llm_with_tools.invoke(state["messages"])
 return {"messages": state["messages"] + [response]}

def execute_tools(state):
 last_message = state["messages"][-1]
 tool_calls = last_message.tool_calls
 results = [tool_executor.invoke(call) for call in tool_calls]
 return {"messages": state["messages"] + results}

def should_continue(state):
 last_message = state["messages"][-1]
 if hasattr(last_message, 'tool_calls') and last_message.tool_calls:
 return "execute_tools"
 return "end"

graph = StateGraph(State)
graph.add_node("agent", call_agent)
graph.add_node("execute_tools", execute_tools)
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue, {
 "execute_tools": "execute_tools",
 "end": END
})
graph.add_edge("execute_tools", "agent")

app = graph.compile()

Add guardrails immediately
#

Rate limits: Don’t let the agent make unlimited API calls.

import time
from functools import wraps

def rate_limit(max_calls, period):
 calls = []
 def decorator(func):
 @wraps(func)
 def wrapper(*args, **kwargs):
 now = time.time()
 calls[:] = [c for c in calls if c > now - period]
 if len(calls) >= max_calls:
 raise Exception(f"Rate limit: {max_calls} calls per {period}s")
 calls.append(now)
 return func(*args, **kwargs)
 return wrapper
 return decorator

@rate_limit(max_calls=10, period=60)
def expensive_api_call():
 pass

Read-only access: Start with read-only database credentials and API tokens. No write permissions until you’re confident.

Timeouts: Every tool should have a timeout. Agents can get stuck waiting.

from concurrent.futures import TimeoutError
import signal

def timeout(seconds):
 def decorator(func):
 def handler(signum, frame):
 raise TimeoutError()
 def wrapper(*args, **kwargs):
 signal.signal(signal.SIGALRM, handler)
 signal.alarm(seconds)
 try:
 result = func(*args, **kwargs)
 finally:
 signal.alarm(0)
 return result
 return wrapper
 return decorator

@timeout(30)
def slow_operation():
 pass

Day 5-6: Test, break, fix, iterate
#

Now use it for real work. Not a demo. Actual tasks.

Test with real scenarios
#

Run your agent on actual data from the past week. Compare its output to what you would have produced manually.

What to check:

Accuracy: Is the information correct? No hallucinated data?

Completeness: Did it find everything it should have?

Format: Is the output actually useful? Does it need reformatting?

Efficiency: How many API calls did it make? How long did it take?

Watch what it does
#

Use LangSmith (works with both OpenAI and LangGraph) to see traces of every step.

In LangSmith’s interface, you’ll see:

Every message sent to the LLM
Every tool call with parameters
Every tool response
The final output
Time and token costs for each step

Look for:

Unnecessary tool calls (calling the same thing twice)
Wrong tool choices (using the wrong tool for a task)
Poor reasoning (making bad decisions about what to do next)
Missing error handling (crashes instead of graceful failures)

Iterate on prompts and tools
#

Improve the prompt when the agent:

Makes the right tool calls but draws wrong conclusions
Doesn’t understand what you’re asking for
Produces output in the wrong format

Improve the tools when the agent:

Can’t find the information it needs
Gets errors from tool calls
Needs more granular control over what it can do

Add more guardrails when you see:

Excessive API calls
Attempts to access things it shouldn’t
Operations that take too long

Common issues and fixes
#

Issue: Agent keeps calling the same tool repeatedly

Fix: Add memory of what it’s tried. Or be more explicit in the prompt: “Call each tool exactly once, then synthesize results.”

Issue: Output format is inconsistent

Fix: Use structured output. OpenAI supports response_format with JSON schema. LangChain has structured output parsers.

Issue: Agent gives up too easily on errors

Fix: Add retry logic to tools. Return helpful error messages the agent can act on.

Issue: Too slow

Fix: Reduce model calls by better prompt design. Cache results. Use cheaper models for simple decisions.

Day 7: Package it for others to use
#

Your agent works for you. Now make it work for your team.

Turn it into a CLI tool
#

Simple wrapper for command-line use:

import argparse

def main():
 parser = argparse.ArgumentParser(description='Generate status report')
 parser.add_argument('--days', type=int, default=7, help='Days to report')
 parser.add_argument('--output', type=str, help='Output file (optional)')
 args = parser.parse_args()

 report = generate_report(days=args.days)

 if args.output:
 with open(args.output, 'w') as f:
 f.write(report)
 else:
 print(report)

if __name__ == "__main__":
 main()

Now anyone can run: python agent.py --days 7 --output report.md

Or turn it into an API
#

from fastapi import FastAPI

app = FastAPI()

@app.post("/generate-report")
async def generate_report_endpoint(days: int = 7):
 report = generate_report(days=days)
 return {"report": report}

Deploy with: uvicorn agent:app --host 0.0.0.0 --port 8000

Document how to use it
#

Write a README that covers:

What it does (specific description)

When to use it (and when not to)

How to run it (exact commands)

What it needs (API keys, permissions, data access)

What to do if it fails (common errors and fixes)

How to improve it (where to file issues or make changes)

Add observability for team use
#

Connect to LangSmith or another observability platform so you can see:

Who’s using it
Success rate
Common errors
Cost per run

This tells you if it’s actually providing value or if people hit problems.

Patterns that work
#

After building several agents, certain patterns consistently work better than others.

Pattern: Small focused agents with clear hand-offs
#

Don’t build one agent that does everything. Build multiple small agents, each with a specific job, that hand off to each other explicitly.

Example: Instead of a single “incident response agent,” build:

Detection agent: Monitors metrics and logs, identifies anomalies
Triage agent: Categorizes incidents, determines severity
Diagnosis agent: Analyzes logs and code, identifies root cause
Communication agent: Updates status page, notifies team

Each agent has clear inputs and outputs. The orchestration layer coordinates hand-offs.

Why this works:

Easier to debug (small surface area)
Easier to test (focused scope)
Easier to improve (change one without affecting others)
Easier to understand (clear responsibilities)

Pattern: Human-in-the-loop for consequential actions
#

Agents should recommend, not execute, anything with real consequences.

For actions that:

Change production systems
Spend money
Contact customers
Modify data

Show the plan first. Get approval. Then act.

Implementation:

def execute_with_approval(action, description):
 print(f"Agent wants to: {description}")
 print(f"Command: {action}")
 approval = input("Approve? (yes/no): ")

 if approval.lower() == 'yes':
 return execute(action)
 else:
 return {"status": "cancelled", "reason": "User rejected"}

Or for async workflows, write the proposed action to a queue and wait for approval before executing.

Pattern: Explicit memory and state
#

Stateless agents repeat mistakes. Give them memory so they learn from experience.

What to remember:

Past conversations and context
What worked and what failed
User preferences and corrections
Domain-specific knowledge learned over time

Simple implementation:

class AgentMemory:
 def __init__(self):
 self.conversation_history = []
 self.learned_patterns = {}

 def remember_interaction(self, input, output, feedback):
 self.conversation_history.append({
 "input": input,
 "output": output,
 "feedback": feedback,
 "timestamp": time.time()
 })

 def get_relevant_history(self, current_input):
 # Return similar past interactions
 pass

Use vector databases (Pinecone, Weaviate, Chroma) for semantic search over past interactions.

Traps that waste time
#

Trap: Building without understanding the workflow
#

Don’t automate what you don’t understand. If the manual process is unclear, the automated version will be worse.

Before building, document:

What exactly happens at each step
What decisions get made and why
What exceptions occur and how they’re handled
What the output should look like

Then build the agent.

Trap: No guardrails until something breaks
#

Every agent needs boundaries. Define them before you need them.

Minimum guardrails:

Rate limits on expensive operations
Timeouts on all tools
Read-only access by default
Explicit approval for risky actions
Input validation on all tool parameters

Trap: Ignoring observability
#

You can’t improve what you can’t see. Instrument from day one.

At minimum, log:

Every agent invocation
Every tool call with parameters and results
Every error with context
Final output and user feedback

Use LangSmith, Arize Phoenix, or W&B Weave. The free tiers are sufficient for starting out.

Trap: Optimizing too early
#

Your first version should work, not be perfect. Get it running, use it for real work, then optimize based on actual bottlenecks.

Don’t spend time on:

Complex caching before you know what’s slow
Multi-agent orchestration before single-agent works
Advanced error handling before you know what errors occur

Do spend time on:

Clear problem definition
Simple working implementation
Basic guardrails
Real usage and feedback

The 90-day rollout plan
#

You’ve built an agent that works for you. Now scale it to your team.

Weeks 1-2: Pilot with willing participants
#

Pick 2-3 people who:

Have the same pain point your agent solves
Are willing to give feedback
Won’t be upset if it fails occasionally

Have them use it for real work but with oversight. Check outputs before they’re used in important contexts.

Gather feedback systematically:

What worked well?
What produced wrong results?
What was confusing?
What took too long?
What would make them use it more?

Weeks 3-6: Refine based on reality
#

Fix the issues that came up in the pilot:

Accuracy problems: Improve prompts, add better tools, fix data quality issues.

Usability problems: Better documentation, clearer error messages, simpler interface.

Performance problems: Reduce latency, cache results, optimize tool calls.

Coverage problems: Handle edge cases that came up, add missing functionality.

Track metrics:

Success rate (tasks completed correctly)
Usage frequency (how often people actually use it)
Time saved (measured, not guessed)
User satisfaction (ask directly)

Weeks 7-10: Expand to more users
#

Open it up to the broader team, but with good documentation and support.

What people need to start:

Clear explanation of what it does
Exact setup instructions
Example usage for common cases
Who to ask when it breaks
How to give feedback

Set expectations:

What it’s good at
What it’s not good at
When to trust the output
When to double-check manually

Weeks 11-12: Measure and decide
#

Look at actual data:

Usage: Are people using it voluntarily? How often?

Value: Time saved, quality of output, impact on workflow.

Cost: API expenses, maintenance time, support burden.

Sustainability: Can you maintain this? Does it keep working as things change?

Decision time:

If it’s working: Commit to maintaining it. Document it properly. Plan the next agent.

If it’s marginal: Figure out what would make it valuable. Fix those things or kill it.

If it’s failing: Kill it cleanly. Document why so you learn for next time.

Don’t let zombie agents accumulate. Half-working automation that people route around is worse than no automation.

What to measure
#

Focus on metrics that matter for real productivity.

Time to complete workflows: Full end-to-end time, not individual steps. This captures actual impact.

Quality of output: Accuracy, completeness, usefulness. Sample outputs regularly and compare to manual work.

Adoption rate: Percentage of team using it voluntarily after the pilot ends.

Trust level: Do people use the output directly or always double-check everything?

Cost per task: API calls, compute time, maintenance effort.

Failure modes: What breaks? How often? How bad are the failures?

What’s next
#

You’ve built one agent. That’s the hard part. The second one is easier. The third one is easier still.

Build a portfolio of focused agents:

Each solving a specific problem. Each well-understood and properly bounded. Each delivering clear value.

The compounding effect is real: agents that handle routine work free you for higher-leverage problems. Which lets you build better agents. Which free up more time.

Key principles to keep:

Start with clear, specific problems
Build focused agents with explicit boundaries
Add guardrails and observability from day one
Test with real work, not demos
Measure actual value, not vanity metrics
Iterate based on usage, not assumptions
Kill what doesn’t work

The teams pulling ahead aren’t the ones with the most sophisticated agents. They’re the ones who started building simple agents months ago and never stopped learning.

Your first agent doesn’t need to be impressive. It needs to be useful. Pick a problem that annoys you, build something that solves it, and use it until it works reliably.

Then build the next one.

Resources:

LangGraph tutorials for step-by-step guidance
OpenAI Agents examples for practical patterns
LangSmith for observability and debugging
MCP servers to connect to your data
NVIDIA NeMo Guardrails for safety controls

The gap between reading about agents and building them is execution. Start today.

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.

GitHub's Double CLI Release: How Two AI Tools Are Reshaping Development Workflows

Fri, 26 Sep 2025 00:00:00 +0000

This week, GitHub released not one but two different CLI tools for AI development. Most people are focusing on the individual features. I’m seeing something bigger: a significant step toward AI becoming development infrastructure rather than just an assistant.

Here’s what actually happened: GitHub released both an update to their regular CLI (version 2.80.0) and a completely separate standalone Copilot CLI tool. Together, they represent two different but complementary approaches to AI-powered development.

This represents a meaningful shift in how we can build and maintain software.

Two Different Tools, One Big Vision
#

Let me break down what GitHub actually released:

Tool 1: GitHub CLI 2.80.0 with Agent Tasks
#

This updates the regular gh CLI you already know with new agent-task commands:

# Start a coding agent task and track it
gh agent-task create "refactor the authentication flow"

# List all your running tasks 
gh agent-task list

# Watch it work in real-time
gh agent-task view 1234 --log --follow

This solves the “black box” problem I had with the GitHub MCP server. Before, you could trigger the coding agent but had zero visibility into what it was doing. Now you can actually see the work happening and integrate it into scripts.

For the full command reference, see GitHub CLI 2.80.0 release notes.

Tool 2: Standalone Copilot CLI
#

This is completely separate. You install it with npm install -g @github/copilot and it becomes an interactive AI partner in your terminal:

# Interactive mode - have a conversation
$ copilot
> Help me find all the CSV files in this directory recursively
AI suggests: find . -name "*.csv" -type f

# Autonomous mode - one-shot commands 
$ copilot -p "create a Python script to parse log files"
# AI writes the script, asks permission, then creates the file

The Key Difference
#

GitHub CLI agent-tasks = manage long-running coding projects (like delegating work to a team member)

Copilot CLI = interactive terminal assistance (like pair programming with AI)

Here’s where it gets interesting. You can combine both:

# Use Copilot CLI to craft the perfect task description
$ copilot -p "help me write a task description for refactoring our auth system"

# Then delegate it to the coding agent
$ gh agent-task create "$(copilot -p 'write task: refactor auth system')"

# Monitor it while doing other work
$ gh agent-task view $TASK_ID --log --follow

We just went from “AI helps me code” to “AI runs my entire development process.” That’s not an incremental improvement. That’s a category shift.

The Missing Piece: Context-Aware AI That Runs Everywhere
#

To understand why this matters, you have to think about what makes these CLI releases fundamentally different from other AI development tools. It’s not that GitHub suddenly built smarter AI. OpenAI and Anthropic probably have better raw models. What’s different is that GitHub’s AI already knows your codebase.

When you call OpenAI’s API or use Claude directly, you’re starting fresh every time. You have to explain your architecture, your patterns, your naming conventions. You’re basically teaching the AI about your project from scratch with every interaction. It’s powerful, but it’s also exhausting.

GitHub’s coding agent is different because it lives in your repository. It already understands your issues, your pull requests, your workflow patterns. It knows how your team writes code. And now, with CLI access, that context-aware intelligence can work automatically in your production workflows.

Here’s what that means practically: when your monitoring system detects a performance issue, the GitHub coding agent doesn’t just get the error message. It gets your entire codebase context, recent deployments, related issues, and team patterns. When you trigger an agent-task from your CI pipeline, it’s not running generic analysis - it’s applying intelligence that already knows your specific architecture, coding standards, and business logic.

The Model Selection Catch
#

Here’s something important I discovered while testing these tools: you can only choose which AI model to use with the standalone Copilot CLI, not with the agent-task commands.

The agent-task commands are locked to whatever model GitHub has configured for their coding agent - currently Claude 4 Sonnet as of September 2025. There’s no way to switch it to GPT-5 or any other model. The standalone Copilot CLI, on the other hand, lets you pick your model by setting an environment variable before running commands.

This creates an interesting tradeoff. The agent-tasks give you AI that truly understands your specific project context, but you’re stuck with GitHub’s model choice. The standalone CLI lets you choose between Claude or GPT-5, but each conversation starts fresh without deep knowledge of your codebase.

In practice, this means you get context or you get control, but not both. For most workflows, I’d choose context over control - having AI that knows your repository is more valuable than being able to switch models. But for complex reasoning tasks where you need GPT-5’s capabilities, the standalone CLI becomes the better choice.

What the Web Interface Doesn’t Want You to Know
#

If you read GitHub’s official documentation about Copilot coding agent limitations, you’ll see statements like “You cannot change the AI model” and “You cannot integrate with external systems.” Reading this, you’d think these are fundamental technical constraints.

But the CLI releases expose these as design choices, not technical limitations. The agent-task commands let you script everything, monitor progress in real-time, and integrate with any tool that can run shell commands. The standalone Copilot CLI gives you model selection that the web interface deliberately hides.

This reveals something important about how developer tools get designed. When companies build “user-friendly” interfaces, they often hide capabilities to avoid overwhelming users. The problem is that hiding complexity also hides possibility. The web interface trains you to think of AI as a black box you occasionally visit, rather than as programmable infrastructure you can integrate into your workflows.

The CLI approach is different - it makes AI composable. Instead of protecting you from complexity, it gives you the tools to manage complexity. That’s the difference between convenient shortcuts and real automation.

Real Examples: What You Can Build When Both Tools Work Together
#

Once you have both an interactive AI assistant and a way to manage long-running coding tasks, the possibilities get wild. Here are some workflows, from beginner to advanced:

Simple Debug Session (Beginner-Friendly)
#

#!/bin/bash
# Use both tools to debug a failing test

# First, get quick guidance from Copilot CLI
copilot -p "My test is failing with 'connection timeout'. What should I check first?"

# Based on the advice, let the agent investigate and fix
gh agent-task create "Test 'user-login-test' is failing with connection timeout. \
 Check database connection, network config, and timeout settings. \
 Fix any obvious issues you find."

# Monitor the progress
gh agent-task list

Smart Performance Monitoring (Using Both Tools)
#

#!/bin/bash
# When servers get slow, use both AIs to investigate and fix
# Note: Assumes get_cpu_usage() function is defined elsewhere

while true; do
 if [ $(get_cpu_usage) -gt 80 ]; then
 echo "CPU usage high, investigating..."

 # First, use Copilot CLI to quickly analyze what's happening
 ANALYSIS=$(copilot -p "Help me understand what might cause CPU usage of $(get_cpu_usage)% in a web app")

 # Then delegate the actual investigation to the coding agent
 TASK_ID=$(gh agent-task create "CPU is at $(get_cpu_usage)%. \
 Analysis suggests: $ANALYSIS \
 Investigate recent deployments and create a fix." \
 --model gpt-5)

 echo "Created task $TASK_ID to investigate. Monitoring progress..."

 # Watch for completion and take action
 gh agent-task view $TASK_ID --log --follow | \
 grep -i "pull request" | \
 while read pr_line; do
 echo "Performance fix ready: $pr_line"
 notify-team "AI created performance fix: $pr_line"
 done
 fi
 sleep 300
done

Intelligent Code Review Pipeline
#

#!/bin/bash
# Use both tools for comprehensive code reviews

# When a new PR is created (webhook trigger)
PR_NUMBER=$1

# First, get quick insights from Copilot CLI
REVIEW_FOCUS=$(copilot -p "What should I look for when reviewing a PR for $PR_TITLE? Give me 3 key areas to focus on.")

# Then delegate the actual review to the coding agent
gh agent-task create "Review PR #$PR_NUMBER. Focus on: $REVIEW_FOCUS. \
 Look for bugs, security issues, and maintainability problems. \
 Add review comments and create follow-up tasks for any issues." \
 --model gpt-5

Development Workflow Orchestration
#

#!/bin/bash
# Complete development workflow using both tools

# Daily maintenance routine
daily_maintenance() {
 # Use Copilot CLI to plan what needs attention
 PRIORITIES=$(copilot -p "Look at our recent commits and issues. What are the top 3 maintenance tasks I should focus on today?")

 echo "Today's AI-suggested priorities: $PRIORITIES"

 # Create agent tasks for each priority
 echo "$PRIORITIES" | while IFS= read -r task; do
 if [[ -n "$task" ]]; then
 gh agent-task create "$task - make it production ready"
 fi
 done
}

# Smart test generation from failures 
monitor_production_errors() {
 tail -f /var/log/app.log | grep ERROR | while read error; do
 # Quick analysis with Copilot CLI
 TEST_STRATEGY=$(copilot -p "How should I test for this error: '$error'?")

 # Create comprehensive tests with coding agent
 gh agent-task create "Production error: '$error'. \
 Testing strategy: $TEST_STRATEGY \
 Write comprehensive tests to prevent this." \
 --model gpt-5
 done
}

The common pattern here? We’re moving from reactive to proactive. Instead of fixing problems after they happen, we’re building systems that think ahead and improve continuously.

More importantly, we’re combining quick AI assistance with deep AI work. Copilot CLI helps you think through problems fast. The coding agent executes the actual work. Together, they create workflows that are both intelligent and thorough.

The Economics Make Sense for Both Tools
#

Here’s something interesting about the pricing: both tools use your existing Copilot subscription and count against your monthly premium request quota. The specifics matter:

Agent-task commands: Each task counts as one premium request, regardless of complexity:

# These all cost the same: 1 request each
gh agent-task create "fix typo in README"
gh agent-task create "migrate our entire codebase to Python 3.12"
gh agent-task create "do a full security audit and fix everything"

Copilot CLI: Each interaction (prompt) counts as one premium request:

# Each of these is 1 request
copilot -p "help me write a regex"
copilot -p "explain this error and suggest fixes"
copilot -p "create a complete monitoring dashboard"

Important pricing details:

Premium request quotas vary by plan (check GitHub Copilot billing docs)
You’re not charged per API call or line of code generated
Complex tasks cost the same as simple ones within each tool

This pricing model encourages ambitious automation. Don’t ration your AI usage. Don’t optimize for fewer requests. Build the automation you actually want.

Strategic insight: Use Copilot CLI for quick decisions and planning. Use agent-tasks for substantial work. This optimizes your premium request budget.

Important Limitations and Security Considerations
#

While these tools are powerful, they come with important limitations and security considerations:

Security Risks:

Copilot CLI can modify files and execute commands - only use in trusted directories
Always review AI-generated code before running it, especially in production
Agent-task outputs should be reviewed for security vulnerabilities before merging

Current Limitations:

No external integrations yet (tools work within GitHub ecosystem only)
Agent-tasks are repo-bound (no cross-repository context)
Both tools are in preview and may change significantly
Limited to GitHub’s model selection (you can’t use your own AI models)

Responsible Use:

Don’t blindly trust AI outputs - human oversight is essential
Start with non-critical tasks while you learn the tools’ behavior
Monitor your premium request quota to avoid service interruptions
Be mindful of sensitive data in prompts (logs may be retained)

We Just Crossed Multiple Lines We Can’t Uncross
#

Think about how AI coding tools have evolved, and what GitHub just delivered:

Phase 1: Autocomplete (AI suggests the next few characters)
Phase 2: Chat (AI answers questions and helps with tasks)
Phase 3: Interactive partnership (Copilot CLI becomes your terminal buddy)
Phase 4: Autonomous delegation (agent-tasks work independently on projects)

Most companies are still figuring out Phase 2. GitHub just delivered both Phase 3 and 4 at the same time.

That’s not incremental progress. That’s the difference between using AI tools and having AI colleagues.

# Interactive partnership
$ copilot
> I'm getting a weird database error. Help me debug it.
AI walks you through debugging step by step...

# Autonomous delegation 
$ gh agent-task create "Fix the database performance issues we just found"
AI goes away and comes back with a solution...

The combination is what makes this significant. You can brainstorm with one AI and delegate work to another. You can get instant feedback and long-term project execution. You can think fast and build thoroughly.

How Teams Will Actually Work
#

The most successful engineering teams are going to figure out how to split work between humans and AI effectively, and I think the division is becoming clearer.

Humans will still own the strategic decisions - architecture choices, priority setting, customer conversations. We’re also better at the ethical considerations and creative problem-solving when systems behave in unexpected ways. These require judgment, empathy, and the ability to see broader business context.

AI, on the other hand, is already excellent at maintaining consistency. It can keep code quality standards across a large codebase, write comprehensive test suites, monitor for security issues, and update documentation as code changes. These tasks require attention to detail and pattern recognition, but not creativity or judgment.

The interesting middle ground is where human expertise combines with AI execution. Code reviews will likely split this way: AI handles the mechanical checks for style violations and obvious bugs, while humans focus on logic, design decisions, and architectural implications. Planning becomes collaborative too - AI can suggest tasks based on codebase analysis, but humans decide priorities based on business needs.

Where This Is Really Heading
#

Here’s the part that gets me excited: we’re building systems that can improve themselves. Once AI can write code, test it, deploy it, monitor how it performs, and learn from the results, we’re not talking about tools anymore. We’re talking about software that evolves on its own.

# Imagine AI analyzing its own work
gh agent-task create "Look at all the code changes I've made this month. \
 Which ones worked well? Which ones caused problems? \
 Update your approach based on what you learned."

That’s a feedback loop that gets better over time. The AI learns from its successes and failures, just like a human developer would.

What You Should Do Right Now
#

Both tools are available today, though they’re still in preview status. Before you can use them, you’ll need a GitHub Copilot Pro+ subscription, and if you’re in an organization, make sure the CLI policy is enabled. Keep in mind that since these are preview features, they may change significantly without notice.

Getting started is straightforward - update your GitHub CLI to version 2.80.0 with gh --upgrade and install the standalone Copilot CLI with npm install -g @github/copilot. But the real strategy is in how you use them together.

Start with quick wins rather than trying to automate everything at once. Use the Copilot CLI for those daily terminal tasks you’re always googling - you’ll be surprised how much faster it is than switching to a browser. For agent-tasks, pick one annoying maintenance job you do weekly and delegate that first.

As you get comfortable, you’ll start to notice a natural rhythm emerging. The Copilot CLI becomes your thinking partner for quick questions and planning, while agent-tasks handle anything that takes more than fifteen minutes of sustained work. The real breakthrough happens when you start chaining them together - using insights from the interactive CLI to inform the work you delegate to the coding agent.

The teams that figure out this combination first are going to operate at a completely different level. They won’t just ship faster. They’ll build intelligent systems that improve themselves while the team focuses on innovation and strategy rather than maintenance and routine tasks.

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.

RAG for Developers: A No-BS Introduction

Sun, 21 Sep 2025 00:00:00 +0000

I’m being asked by developers from time to time to explain what RAG is. Usually, it’s because they’ve heard the term thrown around in AI circles, or their company is evaluating whether to build a RAG system, or they’re trying to figure out if it’s just another AI buzzword.

Here’s the straightforward answer: RAG stands for Retrieval-Augmented Generation, and it’s the difference between an AI that makes stuff up and one that actually knows your company’s data.

Think of an LLM like a brilliant new hire who has read the entire internet up to a certain date. They know a ton, but their knowledge is frozen in time, and they don’t know anything about your company’s private data; your internal wiki, your codebase, your support tickets, your processes.

You have two ways to get this new hire up to speed:

Fine-Tuning: Send them to an intense, months-long training program. You retrain the model on your specific data. It’s powerful, but it’s slow, expensive, and you have to do it all over again every time your data changes.
RAG: Give them access to your company’s internal search engine. When they get a question, they first search for the most relevant documents and then use their intelligence to formulate an answer based on what they found.

RAG is the second approach. It’s a surprisingly simple way to make LLMs smarter, more accurate, and more useful by connecting them to live, external data sources.

How RAG Actually Works
#

At its core, RAG is a two-step process. When you ask a question, the system doesn’t just pass it directly to the LLM.

Step 1: Retrieval (The “R”)
#

First, the system takes your question and searches for relevant information. This isn’t keyword search, it’s semantic search that looks for meaning and context, not just matching words.

Here’s where the magic happens:

Embeddings: An embedding model converts your text (documents, sentences, your question) into a vector, a list of numbers that represents the text’s meaning. Think of it like GPS coordinates for information. Texts with similar meanings get similar vectors and end up “close” to each other in high-dimensional space.

Vector Database: This is where you store and search through these vectors incredibly fast. When your question comes in, the system creates an embedding of the question and uses the vector database to find the text chunks whose vectors are closest to your question’s vector. Popular options include Pinecone, Chroma, and Weaviate.

Chunking: You don’t dump entire documents into the database. You break them down into logical pieces or “chunks.” This makes search results more precise and relevant.

The retrieval step finds the most relevant chunks of text from your knowledge base and passes them to the next step.

Step 2: Augmentation and Generation (The “AG”)
#

This part is straightforward. The system takes your original question and “augments” it by stuffing the relevant text chunks right into the prompt.

The final prompt sent to the LLM looks like this:

Context: [Here are the relevant text chunks we found...]
Based on the context above, answer this question: [Your original question...]

The LLM uses its reasoning ability to synthesize an answer based only on the provided context. This simple trick dramatically improves the quality and accuracy of the output.

Why You Should Care
#

Okay, so the tech is interesting. But what does it actually mean for you as a developer?

It fights hallucinations. The biggest problem with LLMs is that they sometimes make stuff up with incredible confidence. RAG grounds the LLM in facts. By forcing it to base answers on documents you provide, you drastically reduce hallucination.

Your data stays yours. With RAG, you’re not retraining a model or sending sensitive data to third parties. The knowledge base lives in your infrastructure. You’re just pulling relevant pieces at query time.

It’s always up-to-date. Company wiki updated? New support ticket? Just create an embedding and add it to your vector database. The LLM can use this information instantly. Compare that to the pain of constantly fine-tuning a model.

You can cite sources. Because you know exactly which chunks were used to generate the answer, you can easily add citations. This builds trust in your application, whether it’s an internal chatbot or public-facing support system.

RAG vs. Fine-Tuning: When to Use What
#

Here’s the practical breakdown:

Use RAG when:
#

You need to ground the LLM in specific, factual, changing information
You need to prevent hallucinations and cite sources
Your application is knowledge-based (Q&A on documents, custom support bot)
You want your AI to know about recent information

Use Fine-Tuning when:
#

You need to change the LLM’s behavior, style, or tone
You want it to learn specific domain language or formats
You need it to always respond in a particular way (like generating code in a niche programming language)

They aren’t mutually exclusive. You can use RAG on a fine-tuned model for the best of both worlds. But for most developers starting out, RAG is the most direct, cheapest, and effective way to build powerful, fact-based AI applications.

The Real-World Impact
#

Here are some quick wins for teams looking to implement RAG:

Support teams should build chatbots that can answer customer questions using the actual documentation, not hallucinated answers that sound plausible but are wrong.

Engineering teams should create internal assistants that can explain legacy codebases, find relevant examples, and help onboard new developers using actual project documentation and code comments.

Product teams should build recommendation systems that use real product data, user feedback, and business context rather than generic suggestions.

The pattern is consistent: RAG turns general-purpose AI into domain-specific expertise. And that’s where the real value lives.

The Bottom Line
#

RAG isn’t magic, it’s engineering. It’s a straightforward pattern that solves a real problem: how to make AI systems that are both intelligent and accurate.

If you’re building AI applications that need to be grounded in facts, cite sources, or work with private data, RAG should be on your radar. The infrastructure is mature, the patterns are proven, and the results speak for themselves.

The future belongs to AI systems that combine the reasoning power of large language models with the accuracy of real data. RAG is how you get there.

The Context Engine: What Comes After We've Solved Code Generation

Fri, 19 Sep 2025 00:00:00 +0000

We’ve largely won the context war. RAG systems seamlessly ingest our documentation. Tools like Cursor and GitHub Copilot understand entire codebases. Error monitoring platforms like Sentry now provide AI-powered root cause analysis. The basic infrastructure for AI-powered development is here, deployed, and working.

But here’s what I’m seeing in organizations that have moved beyond the “wow, AI can write code” phase: the real opportunity isn’t building better context engines—it’s using them to fundamentally reshape how we approach software development.

The question is no longer “How do we make AI understand our code?” It’s “Now that AI understands our code better than most humans, what becomes possible?”

The answer is a shift from reactive to predictive development. From managing technical debt to preventing it. From architectural drift to architectural evolution. Let me show you what this looks like.

The Architectural Evolution Engine
#

With context engines in place, we can now tackle something that’s been impossible until now: real-time architectural evolution. Instead of letting architecture drift and then scrambling to fix it, AI can now guide architectural decisions as they happen.

The New Reality: Your AI assistant doesn’t just understand your current architecture—it understands the intent behind it. When a developer is about to introduce a new dependency or pattern, the AI can say: “This breaks the bounded context principle we established for the payment service. Here are three alternatives that maintain architectural integrity.”

Beyond Code Review: Traditional code review catches syntax and logic errors. AI-powered architectural review catches conceptual errors. It can detect when a change violates domain boundaries, introduces circular dependencies, or creates coupling that will cause problems six months from now.

The Impact: Architecture becomes a living, enforced discipline rather than a document that gets outdated. Teams can move fast while maintaining long-term system health.

The Technical Debt Prevention System
#

Here’s where it gets interesting. With full codebase understanding, AI can now predict technical debt before it accumulates. Instead of paying down debt, we can prevent it from accruing in the first place.

Debt Pattern Recognition: AI systems can now identify the early warning signs of technical debt: duplicated logic patterns, growing function complexity, increasing coupling between modules. But more importantly, they can suggest refactoring before the debt becomes painful.

The Compound Interest Problem: Technical debt compounds like financial debt. A small architectural inconsistency today becomes a major refactoring effort next year. AI can now calculate the “interest rate” of technical decisions and surface this to developers in real-time.

Proactive Refactoring: Instead of waiting for code to become unmaintainable, AI can suggest micro-refactorings during normal development. “I notice this function is growing complex and similar logic exists in three other places. Would you like me to extract a shared utility?”

The Impact: Teams spend less time fighting legacy code and more time building new features. Technical debt becomes a managed, predictable cost rather than a surprise that derails projects.

The Predictive Operations Layer
#

This is where the future gets really exciting. With operational data flowing back into our context engines, we can move from reactive incident response to predictive system health management.

Performance Regression Prevention: AI can now analyze code changes against historical performance data and predict: “This database query pattern caused a 40% slowdown in the user service last month. The current change introduces a similar pattern in the payment service.”

Failure Pattern Recognition: Instead of waiting for systems to fail, AI can recognize the precursor patterns. “CPU usage is trending upward in a pattern that preceded the last three outages. The common factor appears to be this background job that was modified two weeks ago.”

Capacity Planning as Code: AI can now predict resource needs based on code complexity and usage patterns. “The new feature you’re building will likely increase database load by 30% based on similar features. Here’s the infrastructure scaling plan.”

The Impact: Operations becomes predictive rather than reactive. Teams prevent incidents instead of responding to them. System reliability improves while operational overhead decreases.

The Development Paradigm Shift
#

We’re standing at an inflection point. The basic infrastructure for AI-powered development is largely solved. The question now is: what do we do with this unprecedented capability?

The organizations that will thrive in the next phase are those that use AI not just to write code faster, but to fundamentally rethink how software is built and maintained:

From reactive to predictive: Instead of fixing problems, prevent them.
From debt management to debt prevention: Instead of paying down technical debt, avoid accruing it.
From architectural drift to architectural evolution: Instead of letting systems decay, guide their growth.
From incident response to system health: Instead of reacting to failures, predict and prevent them.

This isn’t about better tools—it’s about better practices enabled by AI that understands our systems as well as we do.

The future of software development isn’t just AI that can code. It’s AI that can think architecturally, predict operationally, and evolve systematically. The context engine was just the beginning.

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.

Developer Productivity · PiniShv

Stop Reviewing Code. Start Reviewing Evidence.

The bottleneck moved downstream and put on a disguise #

The human GIL is a correct diagnosis and a terrible strategy #

The review gate becomes an evidence gate #

If your best engineers are your validation layer, you built the system backwards #

Verification is a system you build, not a virtue you demand #

What to do Monday morning #

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 #

The Vibe Coding Backlash Is Right. Seniors Are Losing the Argument Anyway.

What the seniors are right about #

What the vibe coders are also right about #

Why the seniors are losing anyway #

What “legible judgment” actually means #

The bigger reframe #

What senior engineers should do right now #

The End of Courses: Learn From AI Like a Toddler, Or Become Obsolete

What actually died #

Learn like a toddler #

The crossroads: Operator vs. Kolboynik Architect #

Path 1: The Operator (accept and ship) #

Path 2: The Kolboynik Architect (critical learning) #

The cost of skipping the conversation #

What critical learning looks like in practice #

The big picture #

The good news is better than the bad news #

AI Didn't Replace Software Engineering. It Made Bad Engineering Easier to Ship.

How the rot works #

The perception gap #

Most AI agendas are still theater #

What actually needs to change #

The craft didn’t change #

Google Stitch Just Made UI Design a Developer Skill

What Stitch actually is #

Why developers should care more than designers #

How it fits into the AI app builder landscape #

The MCP integration is the sleeper feature #

Will it replace UI/UX designers? #

The limitations nobody’s hyping #

What this means for engineering orgs #

Your AI Agents Are Flying Blind. Here's How to Fix That.

Two teams, same agents, wildly different results #

Where knowledge actually lives (and why that’s broken) #

The wrong way to fix this #

What actually works: a developer knowledge hub #

Git for authoring #

Semantic search for retrieval #

MCP for delivery #

The loop that makes it compound #

The AGENTS.md safety net #

Why nothing on the market solves this #

How to start (without boiling the ocean) #

The uncomfortable question #

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 bottleneck moved downstream and put on a disguise
#

The human GIL is a correct diagnosis and a terrible strategy
#

The review gate becomes an evidence gate
#

If your best engineers are your validation layer, you built the system backwards
#

Verification is a system you build, not a virtue you demand
#

What to do Monday morning
#

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
#

What the seniors are right about
#

What the vibe coders are also right about
#

Why the seniors are losing anyway
#

What “legible judgment” actually means
#

The bigger reframe
#

What senior engineers should do right now
#

What actually died
#

Learn like a toddler
#

The crossroads: Operator vs. Kolboynik Architect
#

Path 1: The Operator (accept and ship)
#

Path 2: The Kolboynik Architect (critical learning)
#

The cost of skipping the conversation
#

What critical learning looks like in practice
#

The big picture
#

The good news is better than the bad news
#

How the rot works
#

The perception gap
#

Most AI agendas are still theater
#

What actually needs to change
#

The craft didn’t change
#

What Stitch actually is
#

Why developers should care more than designers
#

How it fits into the AI app builder landscape
#

The MCP integration is the sleeper feature
#

Will it replace UI/UX designers?
#

The limitations nobody’s hyping
#

What this means for engineering orgs
#

Two teams, same agents, wildly different results
#

Where knowledge actually lives (and why that’s broken)
#

The wrong way to fix this
#

What actually works: a developer knowledge hub
#

Git for authoring
#

Semantic search for retrieval
#

MCP for delivery
#

The loop that makes it compound
#

The AGENTS.md safety net
#

Why nothing on the market solves this
#

How to start (without boiling the ocean)
#

The uncomfortable question
#

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
#

First, what DORA actually measures
#

What changed in 2025
#