New Skills

Vibe code and a curse for this field

There's been a lot of talk lately about how we build up new developers in the age of LLMs and AI-driven coding. I'll be honest, I barely write code anymore. All of the code for this standard.site blog was written by Kimi Code with K2.7. At work, I almost exclusively use the internal version of Antigravity 2.0 or Antigravity CLI. I have it create a changelist and I review the automatic AI reviewers' comments. Or I just have my agent review the comments and fix things. I'll look it over myself before I send it out to another developer for review. Mostly, I don't care about the details - especially in the internal monorepo, there's usually enough examples or documentation or just direct source code access that API calls etc are fine. What I do care about is the architecture and the unit tests.

Godspeed, architecture at dawn

Increasingly, what I find I have to care about the most isn't the specifics of code, but overall architecture and interface. I want this to be a type with functions defined on it. I want this to run in a goroutine, with two channels for input and output. I want this to be separated into its own module. I want the request protobuf to look like this and the response to include that. Sometimes, I'll include a line that the agent can feel free to make additions, or ask it explicitly to push back if it disagrees, but I define the general shape.

If I leave out these kinds of directives, that's when I find the agents are most likely to produce the dreaded slop. Giant files with horrible interfaces and random functions. Doing everything blocking in a single thread. Using random libraries or API interfaces that aren't acceptable. That sort of thing. So, if you ask me what I think we need to be training our junior engineers on, it's architecture and interface design. Of course, the question then becomes y'know… how.

To some degree, I think a lot of this means a return to computer science basics. It's important to notice that an agent has produced a lookup that runs in O(n) on a large, unsorted list. It's important to understand threading models and concurrency. But system architecture and API design are something I think is sorely lacking - or at least it was mumblemumble years ago when I was in school. Of course, part of the problem is that these things are a matter of taste. On our part, there's the API Improvement Proposals, which are handy for me to reach for at work, considering, but I don't think they're perfect by any stretch of the imagination. Maybe a good place to start a discussion, though.

Am I too dumb to refine?

Yes. This is basically just a braindump of the things I've been thinking about lately. They aren't groundbreaking and they probably aren't even specific enough to be actionable, nor is anybody who matters going to read them and restructure the junior software developer pipeline. But, the next time I mentor a junior developer, these are the things I'm going to try to focus on, because they're the skills I think are the most important right now. I'll leave it to better minds to figure out the specifics. Or maybe RSI is real and AGI is just around the corner to solve all these problems for us. I doubt it, though.

All of the opinions in this article are mine and not my implied employer's. All of the Shins references are because I titled this "New Skills" and then got New Slang stuck in my head. I promise I won't do it again.