I've been evaluating various AI code assistants for integration into our team's CI/CD and developer workflow, with a particular focus on their ability to handle infrastructure-as-code and cloud architecture tasks. As part of this, I've been putting Gemini (specifically via the API and the IDE plugins) through its paces for several weeks.
My primary use case is generating and modifying Terraform modules for AWS, along with writing Kubernetes manifests and Python-based Lambda functions. While I've found its reasoning on architectural decisions to be reasonably sound, the actual *interface* for building these artifacts—what I'm calling the "email builder" pattern—feels fundamentally sluggish and unreliable. By this, I mean the iterative process of prompting, receiving a code block, requesting refinements, and then having the context break down.
The latency is my first major complaint. When working in a dedicated IDE plugin (VS Code), the time between a well-structured prompt (e.g., "Refactor this Terraform module to use a for_each for the security group rules and add tags") and the beginning of the streamed response is often 5-7 seconds. For a developer in a flow state, this is disruptive. More critically, the stream itself is frequently interrupted or stops prematurely, requiring a manual regeneration. This doesn't happen with nearly the same frequency using other local or cloud-based assistants I'm testing.
The "bugginess" manifests in several consistent ways:
* **Context Collapse:** After 3-4 iterations on a single file, Gemini will often start ignoring specific instructions from earlier in the conversation. For example, I'll have established a pattern of using `local.` values for naming, and a subsequent request to "add another S3 bucket following the same pattern" will produce a resource block with hardcoded names.
* **Formatting Degradation:** Code blocks, especially for HCL (Terraform) or YAML (K8s), will occasionally be returned with broken indentation or, in one notable case, with Markdown escaping inside the code fence itself, rendering it useless for copy-paste.
* **Hallucination of Non-Existent Features:** When asked to correct an error, it will sometimes suggest API properties or Terraform resource arguments that simply do not exist in the provider version I've specified. While common to all LLMs, the frequency here feels higher when under a sustained, complex task.
Here's a trivial but symptomatic example from a recent session. I started with a prompt to create a basic AWS VPC module.
```hcl
# Initial prompt: "Create a Terraform module for a VPC with public and private subnets in two AZs."
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = "my-vpc"
cidr = "10.0.0.0/16"
azs = ["us-east-1a", "us-east-1b"]
public_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
private_subnets = ["10.0.101.0/24", "10.0.102.0/24"]
enable_nat_gateway = true
single_nat_gateway = true
}
```
My follow-up prompt was: "Good. Now modify it to use a `for_each` for the AZs and calculate the subnet CIDRs using `cidrsubnet`. Also make the NAT gateway choice variable-driven."
The response took ~8 seconds to start streaming, and the resulting code had several syntax errors in the `for_each` loop and used a `cidrsubnet` function call with the wrong number of arguments. A request to "fix the `cidrsubnet` error" resulted in a corrected function but the `for_each` logic was now completely dropped, reverting to the original list format.
This kind of interaction makes it impossible to trust the tool for any progressive, multi-step development without constant, meticulous verification at each step—which defeats the purpose of augmented coding.
Is this aligned with others' experiences, particularly those working on structured config generation? I'm trying to isolate if this is:
* An inherent limitation of the underlying model for this type of task.
* A performance issue with the serving infrastructure/API endpoints I'm hitting.
* Or a problem with the IDE integration layer specifically.
For comparison, my baseline for "responsiveness" is sub-2 second for a first token and a coherent, continuous stream. For "context stability," I expect to be able to iterate on a single file through at least 10-12 turns without the model losing the thread. I'm not seeing that here.
From a cloud cost perspective, this latency also translates directly to developer idle time, which is far more expensive than the API call cost itself. I want to justify a team-wide license, but the current performance makes a compelling business case difficult.