Agentic coding is getting fast enough that writing the code is no longer the hard part. The hard part is deciding what to build, judging whether the AI's output is any good, and not burning out from making a hundred small calls a day. That is the tension underneath a recent Stack Overflow Podcast episode, "Developers who move fast still need to do it together", recorded at Microsoft Build 2026.
The guest is Cassidy Williams, Senior Director of Developer Advocacy at GitHub and a former host of that same podcast. Her argument is simple and, I think, correct: as AI takes over the routine typing, the parts of the job that stay human — taste, community feedback, mentorship — get more valuable, not less. For a solo builder or a small team in Sri Lanka, that reframes what you should actually be practising.
When an agent can scaffold a feature in one prompt, your day stops being about how do I write this and becomes is this the right thing, and is this output correct. The podcast frames this as a shift toward higher-level strategy. The part people undersell is the price tag attached: decision fatigue.
Every generated diff is a decision. Accept, reject, or reprompt. Do that 80 times before lunch and your judgment gets worse, not because you're lazy but because deciding is metabolically expensive.
Key takeaway:The bottleneck moved from typing speed to decision quality. If you don't manage your decisions, the AI just helps you make bad calls faster.
A few concrete habits that help:
Williams points at three things that AI doesn't replace: human taste, community feedback, and mentorship. That sounds soft until you notice it's exactly the stuff a code model can't give you.
| Skill | Can an agent do it? | Why it stays human |
|---|---|---|
| Generate a CRUD endpoint | Yes, in seconds | It's a solved, patterned problem |
| Decide the endpoint is even needed | No | Requires product and user context |
| Tell you your API design is confusing | Rarely, honestly | Needs a peer who'll disagree with you |
| Help you grow past your current level | No | Mentorship is relational, not generated |
Taste is what tells you the generated solution is technically fine but wrong for your users. You build taste by reviewing other people's work, reading real codebases, and shipping things that get feedback. None of that is downloadable.
The title's point — moving fast still needs to be done together — lands harder when you're far from the big tech hubs. If you're a student in Colombo or a two-person shop in Kandy, the AI is the same one a San Francisco engineer uses. The gap is no longer tooling. It's the network around the tooling.
The playing field for
writing codejust flattened. The playing field fortaste and feedbackdid not. That gap is now the whole game.
Practical, free ways to close it from here:
The episode also references new GitHub Copilot announcements from Microsoft Build 2026, including a new GitHub Copilot app. The podcast doesn't publish the full spec — it points to GitHub's own product news for details — so I'm not going to invent version numbers or features it didn't state.
What I'd tell any Sri Lankan builder is this: before you standardise on any AI coding assistant, run the numbers in LKR and compare the actual limits, not the marketing.
If you want to compare the options side by side, I built two small tools for exactly this: an [AI coding assistant comparison](https://induwara.lk/tools/ai-coding-assistant-comparison) for features and limits, and an [AI coding assistant cost calculator](https://induwara.lk/tools/ai-coding-assistant-cost-calculator) to see the monthly bill in rupees before you subscribe.
If you take one thing from the episode, take this: the skill that used to define a good developer — writing correct code quickly — is now partly automated, and that's fine. It frees you to compete on the things that were always harder to teach.
The tools got faster. That's not the story. The story is that speed is now cheap and judgment is expensive, and judgment is the one thing you still build the old way: slowly, with other people, by caring whether the thing you shipped was actually good.