I teach programmers for a living. Three years ago that mostly meant formal classes. OTP. Elixir. LiveView. A curriculum with modules and exercises and something you could put on a resume at the end. That work is shrinking, and what’s replacing it is training for agentic coding, which looks almost nothing like what came before.

Less vocabulary. Less syntax. Less of the material the agent is already excellent at. More oversight, which turns out to be the only word broad enough to cover what’s left for the human.

The clearest way I can describe the shift is that I used to be an assistant coach. I taught technique and positioning. Where to put your feet, how to hold your hands, how to run the same drill until it stopped requiring thought. I don’t do much of that anymore. The developer is the assistant coach now, and the agent is the one on the field. So I coach the coaches. I train the people who spend their days correcting technique that isn’t theirs.

The shape of the teaching changed with it. The three day class is shrinking. What works now is ongoing sessions, an hour or two at a time, spread across months. The work these people do is continuous, their mistakes arrive on their own schedule, and a firehose in March doesn’t help anybody in June.

The calls I don’t get any more

Someone stood up a database-backed form last Tuesday. A few tables, authentication, a deploy. It took an afternoon. It works, it will keep working, and nobody will ever need to reason about it again.

They didn’t call me. They were right not to.

There’s a whole category of software that should be vibed, and vibing it is the correct engineering decision. Proofs of concept. A prototype built to show someone an idea in a meeting. Simple sites. Internal tools with one user. In those conditions the agent is genuinely good, the stakes are low, and hiring guidance would be overhead on a problem that doesn’t have one.

I should say what I mean by vibing, because the word has gotten sloppy. Vibing is agentic coding without guidance. Not speed. Not using AI. Accepting output without judgment and shipping without understanding.

The calls do still come. They’ve just changed shape.

Two kinds of engagement

Groxio’s work has split into small team and founder engagements on one side, and large team engagements on the other. Three years ago those were the same job with a different invoice. They aren’t anymore. The failure modes differ, the fix differs, and a week of the work looks different.

This article is about the first one. Teams of one and two. Founders. The person actually doing the work, with no organization around them and nobody to review anything.

Two types of small teams

The first type looked at what they were about to build and decided not to vibe it. Something in it was load-bearing. Real scale, or long-running processes, or data flowing through enough hands that the flow is the hard part, or a domain model with actual structure. Sometimes it’s just novel enough that there’s no prior art for the agent to lean on.

If you’ve spent a day chasing a race condition before discovering the agent picked the wrong approach in the first hour, or found six versions of find_user scattered through a codebase you thought you understood, you know the recognition I mean.

The second type already tried. It broke, it’s getting worse, and fixing it is taking longer than building it did. This engagement is just another version of the first. We only decide whether to rescue the code or treat the codebase as a requirements document and throw it away. We almost always do what we do with a short prompt that fails: prompt better, throw it away. It’s a skill we work hard on in Groxio sessions, and this is the same move at the scale of a system. Anyone who has closed a bad PR of their own knows the feeling.

Both of them need the same thing. What I teach now is layering: how to layer code, and how to layer prompts. Those turn out to be the same skill wearing different clothes, and almost nobody arrives knowing either one. Sometimes these calls aren’t even about Elixir, because the mechanisms might change but the prompting and verification strategies don’t. Here’s what that covers.

How agents work, and how they break

You cannot oversee a thing you don’t understand the shape of.

Agents run ahead. Ask for an interface and you get an implementation. Ask for an outline and you get a module. It’s trying to help, and left alone it will make architectural decisions you never knew were on the table. The skill is breaking work into pieces small enough to evaluate and moving forward when you decide to, not when the machine does.

The more dangerous property is quieter. An agent’s confidence does not drop when its competence does. The database-backed form has ten million examples in the training data. Your particular concurrency model has none. The output arrives in the same tone either way, fluent and assured, and that gap is where the wheels come off. Nobody I’ve worked with went wrong because they weren’t careful. They went wrong because the signal that should have told them to slow down was missing.

How the language works

I still work mostly in Elixir, because it helps agents build accurate, concurrent, reliable software for the same reasons it helps humans.

Inside the language, the teaching moved up. Less vocabulary. More architecture.

Where are the lifecycle seams, the places where the system calls your code instead of the other way around? What belongs in the functional core, where data flows through pipes and nothing surprising happens? What belongs in the imperative shell, where the outside world gets to be disappointing? What’s supervised, and what happens when it isn’t?

Those questions decide whether a codebase survives. The agent will not ask them. It will happily generate code on either side of a boundary it doesn’t know exists.

Prompting is writing code that writes code

This is the part that surprises experienced developers, and it’s the reframe I most want to land.

People talk about prompting as a new discipline nobody has experience with. It isn’t. A prompt chain is a program written in English. Compose small units that do one thing well. Give them clean interfaces. Layer them so each layer has one responsibility. Don’t let the boundaries blur. A developer who has spent fifteen years designing decent modules already knows most of this and hasn’t noticed the transfer.

So we build it the way we’d build code. Skills for the units of capability. AGENTS.md for the conventions that should never have to be re-explained. Subagents for work that deserves its own context and its own instructions. Verification techniques layered in so correctness gets checked by something other than the author’s optimism at hour six.

The medium is fuzzier than code. Natural language is ambiguous in ways a function signature isn’t, and compositions leak across boundaries you thought were clean. But it’s a familiar discipline on unfamiliar material, not an alien one. The prompt architecture lives in the source tree, versioned and reviewed, not in a chat window that closes.

That last part is what makes a team of one viable. There’s no senior to review you. The substitute isn’t more discipline. It’s judgment you’ve written down somewhere the agent can read it.

Git tells the story

Short commits inside a pull request, so a change reads as a narrative instead of arriving as a result. That matters even with no reviewer, because the first reader of your PR next month is you, with none of the context you have today.

But git has to do more work now than it used to, and this is the piece almost nobody is doing.

Your history is the best training data you have about your own team. Read the last three months of it. Find the things reviews kept correcting, the same misshapen pattern caught four times by four different readers. Every one of those corrections is a lesson that stayed trapped in a comment thread. Some of them belong in AGENTS.md, where the agent reads them before making the mistake instead of after. That pass takes an afternoon and it changes what the agent produces for the next quarter.

Git is also where durable memory belongs. Architecture decisions, the roadmap, system requirements, the reasons behind the deals with the devil every codebase eventually makes. Those things should be in the repository, versioned and reviewable, not living in an LLM’s memory. Model memory is convenient and it is not yours. It isn’t versioned, it doesn’t survive a tool change, and you can’t diff it. Anything you’d be unhappy to lose should be anchored in the tree.

One last split, because most people blend these. Verification flows are deterministic, cheap, and always on: format, Credo, tests, types. Review flows are judgment, and they cost real money. Launching an agent to read a diff for specific concerns is a different activity than running a linter, and mixing them gets you a process too expensive to run often and too shallow to catch anything.

One more thing

I build furniture when I’m not doing this. Last month I asked Gemini about a piece I was working on, and the question was narrow: color, and the dimension ratios I was weighing.

It gave me a cut list. Material sourcing. A finishing schedule. A confident pile of things I hadn’t asked about and didn’t need.

So I slowed the conversation down and asked for one thing at a time. Then it gave me exactly what I wanted.

That’s the entire skill, demonstrated at a scale where being wrong costs a board. The move doesn’t change when the thing running ahead of you is generating a system you’ll maintain for two years. Slow it down. Ask for less. Go forward when you decide to.

Same failure. Same fix. Wildly different price.

I don’t want this series to turn into a sales pitch, so I’ll leave it here. This is what we’re seeing.

Does any of this resonate with you? Reach out to us at grox.io. It starts with a conversation, not a pitch. And if you’d like to see a similar article on how our large team engagements are changing, leave a comment. We read them all.

— Bruce