Evgeny Potapov, CEO, co-founder, (on LinkedIn, and on X.com)
AI-First Coding: Closing the Gap Between Skeptics and Practitioners in Dev Teams
Speaker: Evgeny Potapov, ApexData co-founder & CEO
I started my last company in 2008. We were two people. By 2022 we were 150. The thing about scaling like that is that until recently, doing more development meant hiring more developers. I'm half a manager and half an engineer — and at 150 people you don't code anymore. You troubleshoot people problems.
When I started ApexData, I didn't want 150 people again. I wanted a small team that could stay well-connected, have fun, and let me keep doing tech work. So we started coding, and I quickly saw that AI was a real leverage point for productivity per person — instead of hiring more and more developers, you scale the people you already have.
We're trying to build this company AI-first. I try to help my friends. We run a small Slack group where we share what we learn. And one of the biggest problems I see in many companies right now is this: in a team of 10, maybe 30% are doing daily AI coding, and the rest have either tried it once, been burned, and gave up — or never started. This talk is about closing that gap.
A lot of people now think that 90–100% of software developers use AI tools every day. The actual numbers from Stack Overflow's late-2025 developer survey are different.
Only 47% use AI tools daily. 17% use them weekly, 13% monthly, and 16% don't use them and don't plan to. So half the working developer population is either occasional or absent.
Why? In most cases the reason is the same: they tried AI coding in late 2022, or in 2023, or in early 2024 — got hallucinations, got burned, and never came back. But 2026 is a different world. Before talking about how to onboard those people, I want to walk through how we actually got here.
Here's the plan. First, what changed and why. Second, whether AI coding is actually reliable now. Third, the concerns people raise in practice. Fourth, how to share AI-coding adoption inside a team — and how not to do it.
Three years of practical work, four distinct eras.
Everything started with a single paper, "Attention Is All You Need," in 2017. OpenAI built GPT on top of it as an API, then figured out by 2021 that the same architecture, fine-tuned on code, was a business. They released Codex, gave the API to GitHub, and GitHub shipped Copilot.
Guillermo Rauch, the founder of Vercel, called Copilot "the future" on the day it launched. At the time it felt like magic — code that auto-completes itself. Looking back, that was the Stone Age.
November 2022, OpenAI shipped ChatGPT. One of the headline use cases was bug-finding: paste 10 lines of code, ask why it isn't working, get a fix. People were stunned. People were also exhausted by the hype, and most of the time the answers were unreliable — too many hallucinations, not enough reasoning.
By the end of 2023, Salvatore Sanfilippo — the creator of Redis — wrote that the level of LLM failure at systems programming was incredible, and that systems work probably needed advanced reasoning that the models just didn't have. Remember this quote. It comes back later.
June 2024, Anthropic shipped Claude 3.5 Sonnet — the first reasoning model that landed in coding tools. Reasoning is the simple idea that changes everything.
Pre-reasoning, the LLM took your prompt and started predicting the next token immediately. For natural text that's fine. For code, you get a regex that's almost right and quietly wrong — missing characters, broken patterns, the whole problem.
Reasoning inverts the flow. The model first thinks about what you asked, plans the steps, then writes the code. Hallucinations don't disappear — they probably never will — but a reasoning loop catches a lot of them before they hit you. One month after Claude 3.5 Sonnet, Cursor adopted it, and that's the moment most people heard of Cursor.
Then came the agents. Anthropic's definition is the cleanest one: "Agents are models using tools in a loop." Reasoning is step one; tools — file reads, edits, shell commands, test runs — are step two.
February 2025: Claude Code. Now the developer types a task, not a snippet. Let's walk through what happens.
"Add input validation to all API endpoints." The agent plans the work, calls list_directory to find the endpoints, reads the files, decides how to extend the existing validator, edits the code, runs the tests, and reports back. That's what makes 2026 different from 2024. The 2024 experience was "type a snippet, get a snippet back, hope it compiles." The 2026 experience is "describe a task, the agent does the task."
So, if AI coding is in such a different place now, why aren't all 100% of developers on board? Three concerns come up over and over.
Lack of trust. Security. And — the one that's most personal and hardest to solve — coding isn't fun anymore.
The trust problem is mostly an outdated impression. Most skeptics formed their opinion in 2024 or early 2025, on models that were genuinely not good enough. The right answer is to look at benchmarks over time.
On SWE-bench, GPT-4o sat around 21% task resolution. Claude 4.5 Opus, Gemini 3 Pro, and GPT-5 / Claude 4 Opus are all in the 66–74% range now. That's not a 10% improvement — it's roughly 3–4x. So when someone says "I tried it, it was bad," the right follow-up is: which model, and when?
Same story on LiveCodeBench. ~35% → ~55% → ~70% → ~80%. The previous generation is a previous era. Anyone whose opinion is based on tools from a year ago needs to retry.
Here's the same Sanfilippo I quoted earlier — the man who in December 2023 called LLMs at systems programming "incredible failures." In a recent post, working on Redis-level code, he wrote that for most projects, writing the code yourself is no longer sensible. Redis is low-level software. If reasoning agents work for Redis, they work for almost anything. That's the kind of update I show to skeptics.
Adam Wathan, the author of Tailwind CSS, is another good example. He said publicly that he used to be more skeptical, that he assumed it would be faster to write the code himself, and that he was wrong — agent mode actually lets him program more, not less. Find the people whose past skepticism matches your colleague's, then show them the same person changing their mind.
None of this means the hallucination problem is solved. It's not, and probably never will be. But there are now layers of mitigation that didn't exist a year ago.
Claude Code recently added skills — prepared prompts you load on demand. The open-source "Superpowers" plugin is a great example. It's a library of skills for brainstorming, planning, executing, security review, code review, and more. Each skill is a long, carefully written markdown file: guardrails that tell the model how to check itself, what to verify, what not to skip.
With skills loaded, the flow is no longer "ask, get code, hope." It's plan → design → TDD setup → implement → run tests → spec review → code review → next task. If tests fail, loop back. If review fails, loop back. In 60–70% of my runs the loop goes back at least once. The end result, after all those re-checks, is dramatically better than the equivalent single-shot output.
Concrete example: someone built JustHTML, a pure-Python HTML parser, by feeding the 9,200 browser HTML rendering tests to an agent and letting it iterate for about a week. It now hits 100% on those tests. Chromium is at 99%, WebKit at 98%, Firefox at 97%, BeautifulSoup at 4%. That kind of result is only possible because of the verify-then-fix loop.
Security comes in two flavours: who's training on your code, and whether the code the AI writes is safe.
For training and compliance, OpenAI's enterprise plan guarantees your data isn't used for training by default, gives you data-retention controls, regional hosting, and SAML SSO.
Anthropic has Claude for Work Enterprise with the same kind of controls, and you can also consume Anthropic models via AWS Bedrock or Google Vertex AI — both give you region-specific hosting and a compliance posture that's easier to defend to a security team than "we're talking to api.anthropic.com from a laptop." Worth knowing: Google's own coding teams use Claude Code. Gemini is great for research (1M-token context), but Claude Code is the day-to-day tool inside Google. Hard to top that as a reference.
If a regulator says "no cloud models," local models are now viable. GLM, Qwen3-Coder, Kimi K2 variants sit in the high 60s to low 70s on SWE-bench. That's roughly where the cloud frontier was a year ago. Tools like Claude Code Router let you point Claude Code at a self-hosted model. Qwen CLI is open source. The cloud frontier is still ahead, but local is no longer toy-grade.
The other half of security is the code itself. More AI-generated code means more code to review, faster than humans can review it. Generic "do a security review" prompts produce generic results. What actually works: pair the security engineer with the tool. They know the threat model; they can write the specific checks; the LLM applies them at scale. And remember — humans also write insecure code. The right comparison isn't AI vs. a perfect reviewer, it's AI-augmented review vs. the review you actually do today.
This one is the hardest. People got into software development for one of two reasons: they love to build, or they love to write code. Those are different motivations, and the AI shift hits them very differently.
If you're a builder, this is a golden age. JustHTML was a side project — one person, evenings, one week. I rewrote the kitty terminal's macOS UX to match Ghostty's in about three hours: "take this kitty code in C/Python, take this Ghostty code in Zig, port the UX patterns over." I built a personal Todoist clone in a Sunday. Open source becomes pliable — you grab a tool, you tailor it. If what you love is shipping things, the fun is still there. There's just more of it.
If what you love is the act of writing code, the problem is real. Probably 30% of developers fall into this bucket. The current best answer is to move them to mission-critical work where hand-written code still matters — billing, safety-critical systems, low-level core paths. It's a partial answer. There isn't a complete one yet, and the industry will have to figure it out. Be honest about it when you talk to your team.
The most common mistake managers make: "We'll buy 100 Cursor licenses, everyone must use Cursor by Q2."
There's a well-known body of research on this (an AMS Review paper from 2020 is a good entry point): roughly half of mandated enterprise innovations fail outright. Humans resist tools that arrive with a deadline and no story.
I know of a real example — a product company, about 100 developers, bought Cursor for everyone. 30 were already using it, 40 picked it up, the other 30 didn't have a path in and didn't move. Three months later, performance reviews fired those 30 in a single hour and the company replaced them with people who already used AI tools. Beyond the cruelty, this was strategically bad: the 70 who remained now know the company will fire you for not adopting fast enough. Trust collapses. "Humans can replace humans" is a much scarier message to your team than "AI is replacing humans," because the first one is plausible and the second one isn't.
What works better is the Champion Model — three phases, not one mandate.
Phase 1, the Sandbox: a small Tiger Team of senior developers who already want to do this. Their job is to break the tool, find what doesn't work, and write down the guardrails. Phase 2, the Expansion: roll out to teams with similar stacks, with the Tiger Team as mentors. Phase 3, the Holdouts: only after value is clear, work with resistant teams individually, with training that addresses their specific objections — security, fun, control, whatever it is. By Phase 3 you're not selling AI coding; the people next to them already use it daily, and the social pressure does the rest.
One ambitious version of Phase 1 + Phase 2: the sabbatical. Zach Wills posted about shutting down their entire 70-person engineering department for a week. No tickets, no feature work. Everyone learning AI tools. By the end of the week, mobile-naive engineers were shipping mobile apps; one developer built a working CRM (backend, frontend, auth) before lunch. Most companies can't or won't pause for a week — but if you can, the learning compounds faster than you'd believe, because the day-to-day pressure is the real blocker. Nobody has time to learn a new tool when the backlog won't stop.
A lighter-weight version of the same idea: a cross-company Slack channel. We run one with friends from different companies. People drop in tricks, gotchas, prompt patterns, new tools. Yesterday someone there asked whether they could really get Claude Code to configure BGP networking on a Linux server. The answer was: yes, give it SSH access in a non-prod environment and describe what you want. He resisted for half an hour — "I want to learn it myself" — and a few hours later messaged back that he was now doing all his ops with Claude Code. He's a strong engineer. The channel did the work of convincing him; we just gave him the room.
Four pieces of plumbing make all of this easier:
CLAUDE.md (or .cursorrules) per project. Encode your conventions: which language version, which package manager ("always use uv for Python"), which branch hygiene, which directories to ignore. The fewer constraints the model has to guess, the fewer hallucinations you get.
This is honest list time.
On refactoring large legacy codebases. Generic "do a code review" prompts are weak. Pointing at specific files or directories with explicit duplication concerns ("these three files have the same loading logic; consolidate") works much better. Indexing the whole repo with embeddings or RAG isn't something I rely on — I let the agent's own tooling search the codebase, and I scope it manually when it matters.
On English as a programming language. Yes, in a sense. Someone has already used Claude Code to design a new programming language end to end (with tests and an interpreter). That doesn't mean English replaces code — it means natural language is becoming the highest level of an existing stack.
On hiring when AI use is uneven. If your team adopts AI and one person doesn't, eventually they can't keep up. That's real. The answer isn't to fire them — it's to bring them in gradually, on their terms, with people they trust. Mass-firing 30% of your team to make a point is a guaranteed way to lose the other 70% to attrition.
The pace will keep accelerating. Pair the people who already do this with the ones who don't, give them air cover, write down what works, and re-evaluate every quarter. Anyone whose last try was a year ago is making decisions based on a previous era.
Share it:
Notes from an April 2026 release: the logs page redrawn with a collapsible filter sidebar and resizable columns, Lighthouse split onto its own tab in URL monitoring, an AI dashboard agent that reads its own rendered output and revises itself, and an observability agent that now records packet drops, DNS query shape, TCP round-trip time, and syslog alongside the application-protocol view.
Notes from a March 2026 release: more context around a slow query in the platform — concurrent HTTP requests matched by interval overlap, an offline SQL Explain analyzer, and a cross-pod comparison toggle — plus log deduplication, request profiling on the OTLP pipeline, and resilient handling of malformed spans in the agent.
Notes from a March 2026 release: AI-generated dashboards with a visualization linter and cross-provider model fallback, three hand-built dashboards for APM, pod restarts and deployments, and a hybrid full-text log search powered by Manticore.
