The Secret Life of Claude Code — The Language You Don't Know
.jpeg)
The Secret Life of Claude Code — The Language You Don't Know
How to work in an unfamiliar language with Claude Code — and where the limits of that partnership actually lie
#ClaudeCode #CodingWithAI #SoftwareEngineering #DeveloperLife
Margaret is a senior software engineer. Timothy is her junior colleague. They work in a grand Victorian library in London — the kind of place where no one is expected to know everything, but everyone is expected to know what they don't know. Timothy has arrived today carrying a file he has never seen the like of before.
Episode 7
The File
He set the laptop on the table and turned it toward her without preamble. This, Margaret had learned, meant he wanted her to see something before he had fully decided what he thought about it.
She looked.
The file was Go. Thirty-eight lines, clean structure, a concurrency pattern using goroutines and channels. Well written, by the look of it.
"Yours?" she said.
"The platform team's. They want me to add retry logic to this service. Apparently I'm the only one available who isn't already overloaded." He paused. "I don't know Go."
Margaret looked at the file again. Then she looked at him.
"How much don't you know?"
"I mean — I can read the broad shape of it. It's clearly doing something with concurrent workers. But the channel syntax, the goroutine lifecycle, what happens when something panics — I don't know any of that with any confidence."
"And what did you do first?"
"I asked Claude Code to explain it to me."
"Good," Margaret said. "And what did it tell you?"
He turned the laptop back toward himself. "It explained the pattern clearly. Worker pool, jobs channel, results channel, WaitGroup for synchronisation. It said the retry logic should probably wrap the worker function and use a loop with a backoff." He looked up. "It made sense when I read it. But I don't know if I trust myself to implement it correctly in a language I've never written."
"That," Margaret said, "is exactly the right concern to have."
What Claude Code Can Do in a Language You Don't Know
"Let me be precise about what you have," Margaret said. "When you used Claude Code to explain that file, it gave you something genuinely valuable — a model of what the code does. The concepts, the pattern, the intent. That is real. You now understand the worker pool pattern in a way you didn't thirty minutes ago."
"It felt reliable," Timothy said. "The explanation matched what I could read."
"For well-established patterns in mature languages, Claude Code is very good at this. Go's concurrency model is not obscure — it is well documented, widely used, extensively written about. The explanation you received is likely accurate." She paused. "But there is a difference between understanding a pattern and being able to implement it correctly in a language you have never written. And that difference matters."
"Because I don't have the instincts yet."
"Because you don't have the instincts yet," she confirmed. "In your own language, when something feels wrong, you feel it. A variable name that's off. A pattern that doesn't fit. A return value being silently ignored. You have developed a sensitivity to the grain of the language over years of use. In Go, you have none of that. Everything feels equally plausible."
Timothy was quiet for a moment. Outside, London was doing what it does on a grey Tuesday — carrying on regardless.
"So Claude Code's output in Go looks the same to me whether it's right or wrong."
"Precisely," Margaret said. "That is the core problem of working in a language you don't know. You cannot calibrate confidence. In your own language, you review code and catch things. In an unfamiliar language, you review code and see shapes."
The Three Things You Actually Have
"You are not without resources," Margaret said. "Let me tell you what you actually have."
She picked up her pen.
"First — you have the compiler. Go is a statically typed, compiled language. It will not run code that is structurally wrong. If Claude Code produces something that gets a type wrong, misuses a channel in ways the type system can detect, or makes a structural error — the compiler will tell you." She looked at him carefully. "But I want to be precise about what the compiler does and does not catch. It catches type errors. It catches certain misuses of channels. What it does not catch is a goroutine that is started and never terminates — a leak that compiles cleanly, runs without complaint, and quietly consumes memory until something in production starts behaving strangely under load. The compiler is a safety net for structural errors. It is not a safety net for lifecycle errors. Keep that distinction."
She paused. "Go gives you two more tools that are worth knowing. The first is go vet — a static analyser that catches a class of common mistakes the compiler deliberately ignores, including certain channel misuses and suspicious constructs. Run it as a matter of habit. The second is the race detector — run your tests with go test -race and Go's runtime will instrument your code and flag concurrent access patterns that could produce race conditions. It will not catch every possible race, but it catches many of the common ones, and in a concurrency-heavy codebase you are not yet fluent in, it is an invaluable second pair of eyes."
Timothy wrote both down carefully.
"Run the compiler constantly. Every small addition. Don't accumulate unverified changes — you have no instinct for which ones are safe." She wrote on the notepad. "Second — you have the tests. The platform team has tests for this service, I assume?"
"They do."
"Then you have a specification in executable form. Before you write a line of retry logic, run the existing tests. They should all pass. After every change, run them again. The tests are your early warning system in territory where your own judgment cannot yet be trusted."
"And the third thing?"
"The third thing," Margaret said, "is the most important, and the most commonly skipped." She set down her pen. "Before you write anything, ask Claude Code to teach you the language feature you are about to use. Not to write the code. To explain the concept."
Timothy looked at her.
"For the retry logic — before you touch the worker function, ask: how does error handling work in Go, and what are the common mistakes developers make when implementing retry logic with goroutines? Show me a minimal, executable example. You are not asking for the full solution. You are asking to be taught. A working snippet you can run immediately is worth more than a paragraph of theory — it gives you something to observe, something to break deliberately, something to learn from before you touch the real code." She paused. "Then, when you do ask for the full implementation, you have enough vocabulary to evaluate what you receive."
The Honest Limits
"I want to be honest with you about something," Margaret said. "There are limits to what Claude Code can do for you here, and they are worth knowing."
"Tell me."
"Claude Code can give you correct Go. It can explain patterns, generate idiomatic implementations, catch common mistakes before you make them. For well-documented features of a mature language, it is a reliable guide." She looked at him steadily. "But it cannot give you judgment. And in a language you don't know, judgment is precisely what you are missing."
"What kind of judgment?"
"The kind that says — this implementation is technically correct, but it is not how Go programmers actually write this. The kind that says — this pattern works in a small service but will cause problems at scale. The kind that says — the platform team has conventions I haven't seen yet, and this solution will be rejected in code review not because it is wrong but because it doesn't fit." She paused. "Claude Code does not know your platform team's conventions. It does not know the unwritten rules of the codebase you are entering. It produces good Go. It does not produce their Go."
Timothy was writing quickly.
"There is one more limit," Margaret said. "Concurrency is hard. Not hard in the sense of complex syntax — hard in the sense that the mistakes it produces are subtle, timing-dependent, and sometimes invisible until production. A race condition in a worker pool does not always manifest in tests. It manifests when load increases, when timing shifts, when two goroutines reach the same point at the same moment for the first time." She looked at him. "For concurrency specifically — in a language you don't know — I would ask Claude Code to review the implementation for race conditions explicitly. Not as part of a general review. As a specific, targeted question: are there any race conditions in this implementation, and have I handled channel closure and goroutine lifecycle correctly?"
"Ask about the hard thing directly."
"Always ask about the hard thing directly," Margaret said. "Vague review requests get vague answers. Specific concerns get specific analysis."
The Right Way to Ask
"Show me how you would ask for the retry implementation," Margaret said. "Not the message you would send — the thinking behind it."
Timothy considered. "I need to tell it what the worker function currently does. What retry means in this context — how many attempts, what kind of backoff, what counts as a retriable error versus a permanent failure."
"Good. And on the backoff — be specific about what you need. A simple exponential backoff doubles the wait on each attempt, which is correct as far as it goes. But if you have many workers all failing and retrying simultaneously, they will all back off by the same intervals and hit the downstream service in waves. Production retry logic almost always adds jitter — a small random variation to the backoff interval — so the retries spread out rather than synchronise. Ask Claude Code about jitter explicitly if this service runs at any meaningful scale."
Timothy looked up. "I wouldn't have known to ask that."
"Which is precisely why you ask about the hard thing directly," Margaret said, "and why you tell Claude Code the context — how many workers, what the downstream service is, what the expected load looks like. The right implementation depends on the answers."
"And I should ask it to explain the retry implementation as it writes it — not just give me code, but tell me what each part does and why, so I can actually learn the language while I'm solving the problem."
Margaret set down her pen. "That last part," she said, "is the thing most developers never think to ask. They want the solution. They accept the code, they paste it in, the tests pass, they move on. They have learned nothing about Go. The next time they encounter a goroutine they are in exactly the same position." She looked at him. "You are going to be in Go codebases again. The platform team is not going away. Use this as the first lesson, not a one-time workaround."
He nodded slowly. "Ask it to teach while it solves."
"Ask it to teach while it solves," she said. "That is a different relationship with the tool than most people have. Most people use Claude Code as a vending machine. Put in a problem, receive a solution. You can use it as something closer to a patient tutor who happens to also write the code."
Before He Left
The library had settled into its late afternoon quiet. Somewhere in the stacks, a trolley moved unhurriedly between shelves.
"One more thing," Margaret said. "When you submit this to the platform team for review — tell them you're not a Go developer. Don't hide it."
Timothy looked surprised. "Won't that undermine confidence in the implementation?"
"It will invite the right kind of review," Margaret said. "A reviewer who knows you're unfamiliar with the language will look at the concurrency carefully. A reviewer who assumes you know Go will skim it. You want the careful review. You want someone who knows the codebase to tell you what you got wrong." She paused. "This assumes, of course, that you are working in a team where honesty about what you don't know is treated as professionalism rather than weakness. In a healthy engineering culture, it is. If yours isn't — that is a different problem, and a more serious one." She looked at him steadily. "But pretending to expertise you don't have is how subtle bugs survive code review. It is not a career strategy. It is a liability."
He closed the laptop.
Outside, London had shifted almost imperceptibly toward evening. Inside the library, a developer had just understood something that would stay with him — that working in a language you don't know is not a problem to be hidden. It is a condition to be managed. Honestly, carefully, and with the right help.
Claude Code could give him the Go. Only time and attention would give him the instincts.
And knowing the difference was how you stayed out of trouble until they arrived.
Next episode: Margaret and Timothy explore context — why Claude Code's output changes dramatically depending on what you tell it, and how to build the habit of providing the right information before you ask the question.
If this series is useful to you, share it with a developer who's ever been handed a codebase in a language they've never written.
Aaron Rose is a software engineer and technology writer at tech-reader.blog. For explainer videos and podcasts, check out Tech-Reader YouTube channel.
Comments
Post a Comment