I mean, for the past few years, the amount of code I write with my own hands has dropped drastically. In some cases, almost to zero.
Most times now, I am verifying output, reviewing generated code, checking if it actually solves the problem, catching hallucinations, and maintaining what comes out of the AI.
That is a big shift.
Years back, loose prototyping, implicit shortcuts, clever ways of doing things, all of that made sense. The developer was the one writing the code, so if it made sense in your head and saved you some time, fine.
But now, when a lot of the code is generated for you, the question becomes different.
Can I easily understand what this thing is doing?
Can I verify it?
Can I quickly spot when something is wrong?
This is one reason I keep liking Go more.
Of course, Go is my favorite programming language, so I may be biased.
But seriously, Go code written by a senior engineer, a junior engineer, or generated by an LLM can look almost the same when everyone follows idiomatic Go.
And I really like that.
With Go, I can usually spot hallucinated code very quickly. Something just looks off. The language gives you fewer places to hide strange ideas.
Even with LLMs, once you push them toward idiomatic Go, I have noticed that you normally need fewer shots before the generated code starts looking reasonable.
There is a quote I saw recently about Rust:
“Rust was accidentally designed for AI-assisted development 10 years before anyone knew that mattered.” — via X
It made me think about Go in a similar way.
Maybe:
Go was designed for humans to easily read each other’s code, before we knew one of those teammates would be AI.
That is really what I like about it.
The agentic coding loop also makes this more obvious. AI can generate, build, test, see the failure, change something, and try again very quickly. Steve Francia talks about this in Go: The Agentic Language, and Anthropic also describes coding agents working through repeated feedback loops.
The faster that loop becomes, the more I care about having clear guardrails.
I am honestly still in awe that I can have AI as a teammate.
But I do not want a teammate that can do anything in ten different clever ways.
I want one that works inside clear boundaries.
Because software engineering is becoming less about typing code and more about reviewing, verifying, and maintaining generated code.
And I think languages that were built around loose prototyping, implicit behavior, and too many clever shortcuts may have a harder time in that world.
Not because AI cannot write them.
It can.
The problem is me.
I still need to verify what it wrote.
If you want to get started with Go:
https://go.dev/doc/tutorial/getting-started
There is also this Go skill for coding agents:
https://github.com/spf13/go-skills
At Atop Web Technologies, we are also working around this same problem from another angle.
We recently released AXON — Spec-Driven AI Development, an open-source protocol for AI coding agents that helps teams plan, build, test, inspect, recover, and ship predictable software.
Because if AI is going to write more of the code, then we probably need to get much better at deciphering intent and verifying output.
If you are actively looking for your next opportunity, you can explore our open engineering roles at:
https://atopwebtech.com/careers
If you need help building an ATS-friendly resume using the STRONG framework, visit:
And if you are looking for free mentorship from working engineers, our beta mentorship platform is available at:
Comments
Post a Comment