Skip to main content
Background Image

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

·679 words·4 mins·
Pini Shvartsman
Author
Pini Shvartsman
Architecting the future of software, cloud, and DevOps. I turn tech chaos into breakthrough innovation, leading teams to extraordinary results in our AI-powered world. Follow for game-changing insights on modern architecture and leadership.

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.