AI coding agents have made engineers like Miki Tebeka more productive than he was two years ago. They have also introduced entirely new ways to create bugs, security issues, and architectural mistakes.
After thirty years of software engineering, his conclusion is simple: AI agents are valuable, but only when experienced engineers understand exactly where they fail. For Go developers, that distinction matters more than ever.
The conversation around AI assisted software development often swings between extremes. Some see coding agents as a revolution that will replace software engineers. Others dismiss them as sophisticated autocomplete.
The reality is far more practical.
Modern AI coding agents such as Claude Code, Cursor, and similar tools can accelerate development dramatically. They can write code, generate tests, explore implementation options, and review existing systems. But they still require something that has become even more valuable in an agentic development environment: engineering judgment.
The Five Stages of Working With AI Agents
Most engineers experimenting with AI coding agents will recognize this progression:
- Denial: It’s just an overhyped Markov chain.
- Anger: Why did it invent a library that doesn’t exist?
- Bargaining: If I tweak the prompt enough, it will behave.
- Depression: I am a highly paid copy and paste clerk.
- Acceptance: It’s my tireless, idiot savant assistant.

That last stage is not blind enthusiasm. It is realism. Miki came out the other side of all five stages more productive, still writing lean and idiomatic Go code, but with a very clear understanding of what these tools are and what they are not.
What AI Coding Agents Actually Are
The most important thing to understand about AI coding agents is also the thing many engineers resist accepting: they are not reasoning about your codebase the way you are. They are predicting the most likely next token based on patterns learned from vast amounts of training data.
That distinction matters because it creates two persistent behaviors:
- The agent will always produce an answer, even when it should say “I don’t know”.
- Incorrect answers can look completely correct.
A simple example: Ask an agent to write a Go function that concatenates two string slices, and it will probably produce code that compiles, runs, and passes basic tests. It may also introduce a subtle bug related to slice capacity management that only appears under specific conditions. The code looks reasonable. The failure mode is hidden.
The agents are improving. They increasingly recommend standard library solutions instead of unnecessary custom implementations. But the fundamental reality remains unchanged, AI agents still generate convincing mistakes. Understanding that reality is the first step toward using them effectively.

Where AI Coding Agents Excel
The conversation often focuses on what AI agents get wrong. It is equally important to recognize what they do well.
Modern coding agents are exceptionally useful for:
- Generating boilerplate code
- Writing unit tests
- Refactoring repetitive implementations
- Exploring multiple design approaches
- Reviewing code against requirements
- Explaining unfamiliar systems
- Accelerating documentation
In many situations, they eliminate hours of repetitive work. The challenge is no longer generating code, it now becomes determining whether generated code should ship.
Why Go Works So Well for Agentic Development
Go turns out to be particularly well suited for AI assisted software development. Several characteristics make it easier for agents to work effectively:
- Small Language Surface Area: Go does not require large amounts of context to explain language behavior. That leaves more room inside the context window for the actual problem being solved.
- Strong Types: The type system provides useful constraints and signals that help agents generate more reliable implementations.
- Predictable Tooling: Fast builds, consistent formatting, straightforward dependency management, and single binary deployment all reduce complexity.
Those characteristics matter even more when an agent is producing code than when a human is writing it. The engineers who understand Go deeply are not becoming less valuable because of AI. They are becoming the people who can quickly identify when an agent has produced something that is technically correct but operationally dangerous.
Context Engineering Is the New Senior Engineering Skill
One of the biggest misconceptions about AI coding agents is that success comes from prompt engineering. In practice, context engineering matters far more.
Every AI coding agent operates within a context window. Everything it knows about your system exists inside that window. When context becomes bloated, unfocused, or polluted with unrelated information, output quality declines. This is why experienced engineers often get dramatically better results from the same models. They understand what information matters.
Effective context engineering often means:
- Pointing the agent at specific files instead of an entire repository
- Starting fresh sessions when switching tasks. Carrying old context into a new problem confuses the agent.
- Providing architecture decisions and constraints up front
- Removing irrelevant information from the working context
Context engineering, deciding what information the agent needs and what to leave out, matters more than prompt cleverness. The model still matters. The prompt still matters. But context often matters most. It is the skill most people underestimate.
Design Before Implementation
One of the highest leveraged habits in AI assisted development is planning before coding. Most modern agents support some form of planning mode where the goal is not implementation but exploration.
Planning mode tells the agent not to write code yet, just to think through the problem. What are the objectives? What are the constraints? What does the data model look like? Where are the edge cases? This is a modern version of rubber-duck debugging. Except the duck can generate alternatives, challenge assumptions, and explore scenarios on demand.
Getting the design right before implementation pays off twice. First, the resulting code is usually better; it has clearer direction and less room to wander. Second, it is cheaper. Fixing a design mistake before code exists is trivial. Fixing it after the agent has produced a large, interconnected implementation means sending the whole file back and forth multiple times, burning tokens and time.
One area where this matters especially is observability. If the code goes to production and the logs are not meaningful, you cannot understand what happens when something breaks. Think about what you need to see before writing a line. That is a design decision. Logging, metrics, tracing, and operational visibility should be considered during design, not after implementation.

Encoding Engineering Standards
Most AI coding agents support project level instruction files such as CLAUDE.md or AGENTS.md. These files become a permanent source of context that guides future sessions to tell the agent how you expect it to work.
Think of them as a written record of engineering decisions and standards:
- Prefer the standard library over third-party packages where possible
- Choose simple solutions first
- Minimize unnecessary dependencies
- Avoid overengineering
- Use git worktrees for parallel development
- Follow team testing conventions
The benefit compounds over time. Instead of repeating instructions, you document them once. The agent will not follow these perfectly, expect it to drift once a week or so. When it does, you do not re-explain. You tell it to add a rule to the file. It writes the rule itself, the document gets more specific over time, and each session starts from a better baseline. The agent then begins every session with a clearer understanding of how your team builds software.
The same logic applies to skills, markdown files that encode repeated workflows. If you find yourself giving the same instructions over and over, write them down once. Name it something meaningful. Point the agent at it when you need it. One command, and the agent knows exactly what to do.

Verification Is Becoming More Valuable Than Generation
AI agents dramatically reduce the cost of generating code. As code generation becomes cheaper, verification becomes more valuable. The bottleneck shifts. The challenge is no longer writing software as quickly as possible. The challenge is validating correctness, architecture, performance, security, reliability, and maintainability.
This is why experienced engineers continue to outperform less experienced engineers in agentic workflows. The ability to verify output quickly and accurately becomes a force multiplier. The engineers creating the most value are often not the fastest typists, they are the fastest validators.
Code Quality Still Matters
There is a line of thinking in some developer circles right now that code quality no longer matters. Give the agent the specs, watch the tests pass, ship it.
The argument goes something like this:
If the tests pass and the software ships, why care what the implementation looks like?
The honest answer… we are not there yet. The engineers who think they are have not found the right bugs yet.
Modern society operates on systems centered around trust. For example, you drive a car assembled by people you will never meet. But the people building the cars still need to know how to build cars. Software engineering is no different.
Engineers using AI agents are the ones building the cars. Those systems depend on engineering discipline. Understanding the code matters. An AI agent may generate code that passes tests today and still fail under load next month. It may create hidden complexity that slows future development. It may introduce subtle operational risks that only appear in production. Recognizing when the agent has produced something that will break under load still requires a human who knows what they are looking at.
The engineers who understand the underlying system remain responsible for what ships. The agent is not going to be on call when the slice bug surfaces in production at 2am. You are.
Security Is Still a Human Responsibility
AI agents do not automatically write production ready secure software. They write software that appears to solve the problem. Those are not always the same thing.
A pattern that comes up constantly: the agent produces a function that makes a network call, handles errors, looks clean, but does not limit the response body size. A sufficiently large response exhausts memory and crashes the application. The code is not wrong, exactly. It is incomplete in a way that matters.
Consider a common Go example:
An agent generates code that performs an HTTP request and uses io.ReadAll on the response body. The code works. The tests pass. A sufficiently large response can still exhaust memory and create a denial of service risk.
A useful practice that helps: after tests pass, explicitly tell the agent to perform a dedicated security audit after implementation is complete. It will find things it introduced. This feels strange, agents are often better at finding security issues than they are at avoiding them during initial generation.
Other common issues include:
- Missing request timeouts
- Unbounded memory allocation
- Goroutine leaks
- Improper channel handling
- Database connection exhaustion
Permission management matters too. On permissions, grant the minimum access required, read-only credentials where possible, and scoped permissions instead of production level access. This is not hypothetical caution. Agents have deleted production databases. The same speed and capability that makes them useful makes unconstrained access dangerous and mistakes more expensive.
What Comes Next
The engineers who get the most value from AI coding agents are not the ones who trust them blindly. They are the ones who understand their strengths, limitations, and failure modes.
Miki came through all five stages more productive. Still writing Go. Still responsible for what ships. Still applying engineering judgment. But now working alongside a collaborator that never sleeps, never gets tired, and can explore solutions at extraordinary speed.
That is meaningful progress. It is also not magic.
AI coding agents reward engineers who understand them clearly. And right now, the engineers who understand Go deeply enough to guide, review, validate, and occasionally override those agents are the ones separating productive systems from production incidents.

Featured · 2-Day · Online Workshop
Practical Go Development with AI Agents
with Miki Tebeka
Preview the workshop
See what two days of live training looks like
This webinar is a preview of the hands-on Go and AI agent work you will do across both sessions. This includes planning, context engineering, skills, MCPs, and building real services with solid engineering practices.
- Live instruction with Miki Tebeka — June 24th & 25th, 2026
- 2 sessions · 4 hours each · Online · Live Training
- Full session recordings included after the workshop
Frequently Asked Questions
An AI coding agent is a software tool that can generate code, review implementations, write tests, refactor existing systems, and perform development tasks using large language models. Examples include Claude Code, Cursor, and other agent based development tools.
Context engineering is the practice of controlling what information an AI agent receives while solving a problem. Providing focused, relevant context often has a larger impact on output quality than prompt wording alone.
Yes. Go's relatively small language surface area, strong type system, predictable tooling, and emphasis on simplicity make it particularly effective for agent based development workflows.
Not today. AI agents can accelerate implementation, but they still require engineers to validate correctness, evaluate architecture, identify security risks, and make business and technical decisions.
Only when their output is reviewed and validated. AI generated code can contain security vulnerabilities, performance issues, and architectural mistakes that may not be obvious during initial implementation.
Common risks include hallucinated dependencies, incorrect assumptions, security vulnerabilities, hidden performance issues, excessive complexity, and overreliance on generated code without proper review.
Because the hardest problems in software engineering are not generating code. They involve architecture, tradeoffs, validation, security, reliability, and operational decision making. Those responsibilities still belong to engineers.



