Last week, I built a small service in Go.
I don’t write Go.
I don’t know its idioms. I don’t have muscle memory for its syntax. I’ve never used it in production.
And yet, in a couple of hours, I had something working. Clean enough. Tested. Doing what it was supposed to do.
AI did most of the typing. That part isn’t surprising anymore.
What was surprising is that the bottleneck wasn’t the language.
It was me.
The part that feels like magic
If you haven’t tried this yet, it does feel like a superpower at first.
You describe what you want:
“Build a REST endpoint that processes X, stores Y, and returns Z.”
AI gives you:
- project structure
- handlers
- models
- tests
- even some documentation
You iterate a bit:
- “this should be async”
- “add retries”
- “separate this into a service layer”
And you end up with a working feature in a language you barely know.
No docs. No Stack Overflow. No long detours learning syntax.
It’s tempting to conclude:
“Languages don’t matter anymore.”
That’s not what’s happening.
What actually made it work
I didn’t know Go.
But I knew what I wanted the system to do.
I knew:
- this endpoint shouldn’t block on external calls
- this logic needed to be isolated from transport concerns
- this data access pattern would become a bottleneck if left naive
- this part would need caching if traffic increased
- this failure mode needed explicit handling
None of that is Go.
That’s architecture. That’s design. That’s experience.
AI was just translating those decisions into code.
And that translation layer is exactly what AI is incredibly good at.
AI is a universal translator for code — not a substitute for thinking.
Where things start to break
Here’s the part that’s easy to ignore when everything is working.
I could build the service.
I couldn’t own it.
If something subtle went wrong, I wasn’t operating from intuition. I was guessing.
- Is this idiomatic Go, or just something that compiles?
- Is this memory-safe under load?
- Is this concurrency model correct, or just “seems fine”?
- Is the performance acceptable, or accidentally terrible?
When I write in a language I know well, those questions don’t feel like questions. They feel like constraints I naturally design around.
Here, they were blind spots.
AI helped me move fast. It didn’t remove those blind spots.
It just made them easier to miss.
The real shift
Before AI, learning a new language had a steep upfront cost.
You had to:
- learn syntax
- understand standard libraries
- internalize patterns
- build enough context to be productive
Now, that cost is dramatically lower.
You can get to “working code” almost immediately.
But something important didn’t change:
The quality of the system still depends on the quality of the decisions behind it.
AI removed the friction of writing code.
It did not remove the need to decide:
- what code should exist
- how components should interact
- what trade-offs are acceptable
- what will break at scale
That’s still on you.
What this enables (and what it doesn’t)
This is genuinely powerful.
It means:
- you can explore new stacks without a huge upfront investment
- you can prototype across ecosystems quickly
- you can apply your knowledge in more places than before
But it does not mean:
- you understand the language
- you can debug deep issues
- you can reason about edge cases confidently
- you can make informed trade-offs inside that ecosystem
You can switch languages. You can’t switch fundamentals.
The uncomfortable implication
Two developers can now build the same feature in a language neither of them knows.
Both use AI. Both get working code.
The difference isn’t in how well they prompt.
It’s in what they know to care about.
One will ship something that works.
The other will ship something that keeps working.
From the outside, those look identical — at least at first.
What changed (and what didn’t)
AI didn’t make programming languages irrelevant.
It made them less of a bottleneck.
The bottleneck moved somewhere else:
- system design
- understanding trade-offs
- anticipating failure modes
- reviewing and validating code
In other words: fundamentals.
Not the kind you memorize.
The kind you only get by building, breaking, and fixing systems over time.
What I took away from this
Using AI in a language I barely know wasn’t impressive.
It was revealing.
It showed me very clearly what parts of my skillset are portable — and what parts aren’t.
- Syntax? Portable.
- Patterns? Mostly portable.
- Judgment? Not portable. Earned.
And AI amplifies all three.
What I’ll write about next
This might look like AI is leveling the playing field.
It’s not.
If anything, it’s making the differences between developers harder to see — and more important.
Two people can now produce similar-looking code at similar speed.
That doesn’t mean they built the same system.
I’ll dig into that in the next post.
I write about Git and engineering practice for working developers. My book Git in Depth is 658 pages of the fundamentals AI assumes you already know.
If you're trying to build stronger foundations — not just ship faster — you can check it out here: https://mdenda.gumroad.com/l/git-in-depth
Top comments (0)