Six Months Coding with Agents: Speed Gains and Sharp Limits

The Raw Data: What Actually Happened

The experiment was simple in design but radical in execution: write code exclusively through AI agents for six months. No direct file manipulation. No manual debugging loops. Just high-level intent fed to a machine, with the machine spitting out pull requests. The full post-mortem details the psychological and technical journey, but the metrics are what engineers care about.

The velocity spike was immediate and undeniable. Tasks that previously consumed 4-6 hours—boilerplate API scaffolding, database migrations, standard React component trees—collapsed into 15-minute review cycles. The author reported a 10x speedup on greenfield feature work. This wasn't a 20% efficiency gain; it was a phase shift.

However, the aggregate output metric masks a violent bimodal distribution. The median task time plummeted, but the tail-end latency exploded. Simple CRUD operations became near-instant. But tasks requiring deep architectural reasoning or complex state management often resulted in a "negative velocity" loop—code that looked correct at first glance but contained subtle race conditions or memory leaks that took longer to untangle than writing the solution from scratch.

The takeaway isn't that agents are flawed; it’s that they are brutally honest mirrors of your codebase’s complexity. If the agent fails, the architecture is likely too convoluted for a human to onboard quickly either.

The Physics of Agentic Speed

Why does this feel like cheating? Because it collapses the "translation layer" in software engineering. Historically, an engineer’s job was to translate a mental model of a solution into syntactically correct text. That translation step is pure cognitive overhead.

Agents remove the finger-to-keyboard latency. You think, "I need a rate limiter using a sliding window log," and the code appears. This shifts the bottleneck from typing to thinking. For Forward Deployed Engineers (FDEs) who often juggle high-stakes client integrations and rapid prototyping, this is a superpower. You stop being a typist and start being a conductor.

The speed manifests in three concrete areas:

1. Boilerplate Annihilation: Setting up a new microservice with auth, logging, and database connections is now a single prompt.
2. Test Generation: Writing unit tests is drudgery. Agents write them comprehensively, often catching edge cases you’d skip in a hurry.
3. Documentation Synthesis: Explaining a complex function is tedious. Agents do it instantly, keeping the bus factor low.

But this speed is addictive and dangerous. The source post notes a creeping atrophy of deep syntax knowledge. When you stop writing raw code, you lose the tactile feel for the language’s sharp edges. You become a reviewer, not a writer. This is fine for seniors who know what to look for, but it’s a potential career trap for juniors who might never learn the underlying mechanics.

The Sharp Limits: Where Agents Shatter

If greenfield is the happy path, legacy systems are the brick wall. The six-month experiment revealed a critical failure mode: context collapse. Agents operate on a limited window of tokens. A large, mature codebase with years of accumulated logic and indirect side effects cannot fit into that window.

The agent will generate code that passes unit tests but violates invisible invariants. It doesn’t know that a specific cron job relies on a side effect of a logging function. It doesn’t feel the fear of touching a 10,000-line utils.js file.

Specific failure modes observed:

• The "Good Enough" Fix: The agent suggests a workaround that introduces technical debt rather than fixing the root cause.
• Hallucinated APIs: It confidently calls functions that don't exist in your version of the library.
• Security Theater: It adds validation that looks secure but misses the actual attack vector because it doesn’t understand the threat model.

For FDEs, this limit is the demarcation line of value. An agent can build a dashboard to visualize customer data. It cannot navigate the political and technical minefield of why the customer’s data schema is broken in the first place. That requires the human skill of inquiry—something we cover deeply in our guide for freshers entering the field.

The FDE Edge: Why Context Matters More Than Code

Forward Deployed Engineering isn't just about writing code; it's about writing the right code under extreme uncertainty. You are deployed into a client’s chaos. The API is broken. The data is dirty. The deadline was yesterday.

Agents fail in this environment because they optimize for the prompt, not the outcome. An FDE listens to a client describe a problem, translates that into a technical scope, and then builds a solution that actually works in their broken environment. The agent can only do the third step, and only if the first two are perfectly defined.

This is why the "agentic" workflow is actually an "architectural" workflow. The six-month experiment forced the engineer to write extremely precise specifications. The code became a function of the spec. If the spec was ambiguous, the code was garbage. This aligns perfectly with the FDE skill set: defining the problem with such rigor that the solution becomes mechanical.

To handle the context collapse problem, engineers are starting to treat memory as an architectural component, not an afterthought. We’ve written extensively about this shift in our piece on agentic context management. The future belongs to engineers who can curate the input context for their agents, feeding them the exact files and constraints needed to succeed.

How to Actually Use This Today

You don’t need a complex framework. You need a disciplined workflow. Based on the six-month data, here is the high-signal process to start coding with agents without blowing up production.

1. The Spec-First Rule Never ask an agent to "fix the bug." Define the bug. Write a comment block that details:

• The expected behavior.
• The actual behavior.
• The exact files involved.
• The constraint (e.g., "Do not change the public interface").

2. The Scaffolding Loop Use agents for the heavy lifting of creating the skeleton. If you need a new endpoint, tell the agent to create the route, the controller, the validation schema, and the test file. Review this scaffold. Once you agree on the shape, you can iterate on the logic.

3. The "Explain It Back" Check Before merging, ask the agent to explain the code it wrote. If it hallucinates a reason for a complex regex or a weird state mutation, you’ve caught a bug. This is a cheap sanity check.

4. Automate the Boring, Guard the Critical This is where you can use tools like n8n and Gemini to build your own agent pipelines. You don’t need to be a machine learning engineer to automate your workflow. For example, you can build a YouTube-to-blog repurposing agent that captures technical talks and turns them into documentation. This is the essence of the FDE mindset: using low-code tools to solve high-value problems immediately.

5. Visual Feedback Loops One of the most powerful emerging patterns is visual-to-code generation. Imagine taking a screenshot of a client’s whiteboard sketch of a dashboard and having an agent generate the frontend code instantly. This isn't science fiction; you can build a screenshot-to-code agent using Qwen-VL on the Cloudflare Workers free tier right now. It collapses the feedback loop between the client’s vision and the prototype.

A Balanced Take: Augmentation, Not Replacement

The six-month experiment ends with a conclusion that resonates deeply with the FDE ethos: The engineer is not replaced; the engineer is promoted.

You are no longer the bricklayer; you are the architect and the inspector. The value moves up the stack. The market will no longer pay a premium for someone who can type syntax quickly. It will pay a premium for someone who can:

• Deconstruct a messy business problem into a clean technical specification.
• Rigorously review auto-generated code for security and performance flaws.
• Maintain the mental model of a complex system that an LLM cannot hold.

This is the trajectory we see in programs like Palantir’s Echo and Delta, where the emphasis is on navigating complexity and owning outcomes, not just shipping lines of code. The agent is just the latest tool in the belt, replacing the IDE autocomplete with something far more powerful, but equally dumb without the right hands guiding it.

FAQ

Will coding agents replace junior developers? They will replace the tasks of junior developers, but not the role. If a junior’s job was just to write boilerplate, that job is gone. But the job of learning the system, asking "why," and growing into a senior who can review agent output is still vital. The entry bar is just higher now.

How do I prevent agents from hallucinating packages? Lock your dependencies. Explicitly tell the agent, "You must only use imports from package.json." If it needs a new library, it must ask you first. Treat it like a very fast, occasionally dishonest mid-level engineer.

Is it safe to let an agent connect to a production database? Absolutely not. Agents should operate on read replicas or, ideally, on generated test data. Never give an agent a write connection string to production. The blast radius of a hallucinated DROP query is infinite.

What’s the best language for agentic coding? TypeScript and Python. The strict typing of TypeScript gives the agent guardrails, and the vast training data means it’s seen your bug before. Python’s readability makes the "explain it back" check very effective.

How do I start if I’m an FDE new to AI? Start small. Don’t try to build a monolith. Build a micro-tool that solves a specific pain point, like a Discord FAQ bot backed by your docs. It teaches you prompt engineering and output validation in a safe, stateless environment.