Copilot Is Coming (And It Will Change How We Code)

I've been following OpenAI's Codex work closely, and what I'm seeing is going to reshape how developers work within the next 18 months. GitHub's about to announce something that most engineering teams aren't ready for—and by "ready," I mean they haven't thought about the implications yet.

The capability is straightforward: an AI that can write code by looking at what you've already written and what you're asking it to do. Not autocomplete on steroids. Actual code generation. Functions. Logic branches. Real stuff.

I know what the initial reaction is going to be. "AI writing code will produce garbage." "Security nightmare." "We'll spend more time reviewing generated code than writing it ourselves." All of those concerns are legitimate. But they're also the wrong frame for thinking about what's actually happening.

This Isn't About Replacing Developers

This is about shifting what developers spend their time on. Right now, developers spend roughly 25-30% of their time on boilerplate. Form validation. CRUD endpoints. Data transformation. Tests. The mechanical stuff that a junior developer could write but takes time even when senior developers do it because, well, it still takes time.

What if instead of writing that, you just described it? "Create an endpoint that validates this shape and returns JSON." And the AI wrote it. You'd review it. Maybe adjust it. Ship it.

The time saved isn't trivial. In a typical sprint, that's easily one to two days per developer spent on work that's necessary but not particularly creative or strategic. That's time that could go to architecture, edge cases, performance optimization, or just—and I know this sounds radical—thinking about whether the code is any good.

But here's where it gets interesting: this shifts the skill distribution in software development. Junior developers currently learn by writing a lot of boilerplate. They need that repetition. If AI handles the boilerplate, what do they learn? This isn't a flaw in the system—it's an indicator that how we train developers needs to change.

The companies I talk to are mostly not thinking about this yet. They're focused on "will this work?" and "is it secure?" Those are real questions. But they're tactical. The strategic question is "how do we use this to build better software faster?" and then "what does that mean for how we organize our teams?"

The Honest Problems

I'm not overselling this. Generated code will have bugs. It'll make questionable choices about naming and structure. It'll reflect the training data's biases and patterns. The first major hack using AI-generated code is probably already being written.

But here's what's wild about that: junior developers also produce code with bugs and questionable design choices. The difference is we've developed rigorous review processes for code. Linters. Type systems. Tests. Architectural patterns. These weren't created to handle AI-generated code specifically, but they actually handle it pretty well. Maybe better than they handle inconsistent human code because at least AI is consistent in its mistakes.

The real risk isn't the code itself. It's that teams use this as an excuse to stop thinking about architecture. "The AI will figure it out" is dangerous. The AI won't. It'll generate code that matches the patterns it sees in the codebase. If your codebase has bad patterns, the AI will multiply them at scale.

What Actually Changes

Here's what I think happens when this goes mainstream, probably by mid-2021 when GitHub officially announces it:

First, development velocity increases for teams that are already structured well. Badly organized teams might move faster but produce worse code because they're not creating the structures that make AI-generated code trustworthy.

Second, the market for junior developers flattens for a couple of years. Not eliminates—flattens. The 18-month runway of writing boilerplate that taught you how code actually works gets shorter. Companies will need to train developers differently or hire more experienced people.

Third, security focus intensifies. Every review process now includes "did the AI put a SQL injection vulnerability here?" Security teams are going to add AI-generated code to their threat model if they haven't already.

The teams that navigate this well will be the ones that were already good at code review and architectural standards. The ones that had weak processes? The AI amplifies their existing problems.

I'm not sure if GitHub's Copilot ships in the next few months or takes longer—their timeline is their timeline. But the technology is there. The capability is real. And the industry is going to shift faster than most people expect once this hits general availability.

The question for engineering leaders right now isn't whether your team will use AI-assisted coding. It's when, and whether you'll be prepared to actually benefit from it.