DEV Community: Muthali Ganesh

What is specification driven development with coding agents? Lessons from 40+ successful builds

Muthali Ganesh — Sat, 26 Sep 2026 03:51:31 +0000

The velocity that AI agents bring to virtually any use case can never be overstated. One prime use case is its utility as coding agents. With one prompt and a general sense of direction, anybody anywhere can generate working code - but for it to work meaningfully within a codebase is a different matter altogether. Piecing together chunks of code requires careful oversight and rarely works in the first go. Specification driven development is the way to make sure you get it right the first time, all the time.

In the year 2026 alone, we at GoML have deployed 40+ AI systems into production using specification driven development with Claude Code, so here’s a distilled guide with all of our learnings and insight.

Where vibe coding starts to faulter

Vibe coding is the term for when building software is done by assembling prompt-generated code, rather than thorough system-design level thinking.

Conversational coding depends on the engineer to hold the entire system design in mind while patching different bits of code together. As changes cascade across the variety of modules, iterative patching often produces friction that makes the codebase clunky.

Why AI coding agents need more than prompts

The conventional loop of AI-assisted engineering is pretty straightforward:

Write a prompt
Receive generated code
Review the difference
Apply a correction. And then repeat.

For isolated scripts, single-function utilities or CSS adjustments, this dynamic works reasonably well. This mechanism falls apart once an agent transitions from autocompleting functions to implementing multi-tiered features.

In real-world codebases for important software functions, features almost always span multiple files and alter shared abstractions while demanding precise error handling. When you rely solely on natural-language prompts, context gradually degrades as the conversational history grows.

The fundamental issue in modern AI-assisted engineering/coding is how do you manage to preserve intent throughout the session. Without a persistent anchor, the model makes micro-decisions based on immediate context windows rather than overall architecture.

This- causes the implementation to drift away from the system's actual requirements.

How specification driven development works

SDD reorganizes an AI coding session around three documents instead of one verbose conversation:

A spec: A plain language document to describe what a change should do and what it should explicitly not do. This is written before any code is generated. Call this file SPEC.md.
A plan: The spec broken into a numbered, ordered sequence of implementation tasks, naming the files involved. (PLAN.md)
The code: Generated by your AI assistant against the plan, one task at a time, with a human checkpoint between phases.

The exact form of a specification varies across the industry and context. Some organizations adopt strict JSON schemas, while others rely on GitHub Spec Kit or similar tooling.

In practice, SDD requires no specialized framework or heavy toolchain. The discipline functions reliably using standard Markdown documents committed directly to the project repository alongside the source code. The core premise remains the same, which is you externalize the intent into persistent files such that it isn’t reliant on the temporary memory of each chat session. This is its winning differentiator.

Specification driven development v/s vibe coding

SDD verifies that the feature does what the requirement says, across files and services that no unit test records. Vibe coding misses out on this

Dimension	TDD	BDD	Vibe coding	Spec driven development
Primary artifact	Unit tests	Given-When-Then scenarios	Natural language prompts	A written spec on disk
Scope	One function	Cross-functional behaviour	Whatever the prompt covers	Feature-wide architectural intent
Where truth lives	The test suite	Workshop notes	Chat history	The versioned spec file
Validation	Automated test run	Human reference	Manual review, if any	Review gate per phase, plus tests
Survives a session restart	Yes	Partly	No	Yes

The three levels of specification rigour

It is not necessary that every spec needs to be a permanent artifact. Although, you must decide upfront where a given piece of work sits.

Spec First: The specification is drafted to guide the initial build and is allowed to go stale once the feature merges. This minimizes overhead in case you need isolated feature additions
Spec Anchored: The specification is actively maintained and updated throughout the system lifecycle. This provides documentation for long-lived systems, regulatory audits and in if your code base will need additional developer onboarding.
Spec-as-Source: The specification is the primary artifact engineers edit, while application code is regenerated programmatically via automated pipelines. This requires reasonably mature compiler infrastructure and is suited to strict, API-first environments.

Claude Code points you toward specification driven development (SDD)

SDD is not a workaround you are bolting onto Claude Code. In fact, Anthropic's own team recommends similar workflows. They themselves recommend the EPIC pattern which stands for Explore, Plan, Implement and Commit.

Enter Plan Mode on Claude Code so Claude can read files and answer questions without touching anything yet.
Ask it to turn that exploration into a concrete implementation plan.
Review and edit that plan directly.
Switch out of Plan Mode to let it write code and open a PR.

While Anthropic’s EPIC pattern helps lay the groundwork, true specification driven development takes that logic one step further. Plan Mode operates entirely inside active session memory - which basically means it vanishes the moment you clear the prompt history or restart your terminal. It offers a single review checkpoint before code generation begins.

Specification driven development takes the intent of Plan Mode and turns it into persistent batch of repository files - enabling longer context work. By writing the specification and plan directly to disk, the work survives resets and also introduces distinct review checkpoints between all stages of execution.

You do not need external orchestration frameworks or complex tooling to run this workflow. Claude Code natively supports persistent specification driven engineering through four built-in extension points.

How to get started with specification driven development

First, your project configuration file serves as the anchor. Placing references to active specifications and global design standards directly inside this configuration ensures that any new agent instance immediately respects existing architectural patterns.

Second, Plan Mode allows the agent to inspect dependencies, verify file trees and draft the implementation plan without generating any code.

Third, the agent can spawn dedicated subagents to review generated diffs or execute discrete tasks from a clean context window - and thus, totally preventing conversational drift and hallucinating.

Finally, automated hooks tend to enfoce deterministic “completion” criteria.

Read-only planning in Claude Code

Claude first explores the codebase in read-only mode, gathers the relevant context, and only then drafts the implementation plan.

The plan then turns that exploration into a concrete sequence of steps, files, and verification checks.

This keeps the work 'grounded' before any code changes happen. This is the key difference between guessing and planning. Claude inspects the codebase first, then converts that understanding into an implementation roadmap.

Plan Mode separates discovery from implementation, helping Claude build a grounded plan before any files change.

The route to mastery in SDD for GoML

The progression toward specification driven development was forged directly through our production builds over the past three years. Early in 2025, before native planning features existed in Claude Code, we engineered an end-to-end report generation engine that orchestrated data ingestion, context retrieval, synthesis and final document assembly. Mostly because the platform lacked innate ways to pause and structure execution, we had to enforce planning through manual conventions.

Then, as native planning features arrived, we relied heavily on SDD to build Proxure’s spend analytics platform - where the application required translating freeform prompts into reliable SQL and complex data exports, all while maintaining state across iterative queries. Plan Mode gave the agent the operational pause it needed to map out multi-step logic safely within an active session.

The real inflection point came with GoML’s work for HealthOrbit, where we automated clinical documentation pipelines encompassing template creation, entity extraction, data validation and compliance governance. Given the zero-tolerance necessity for workflow disruption in healthcare/clinical environments, conversational prompting and in-memory planning were insufficient. Anchoring Claude Code to repository-native specifications gave the agent immutable boundaries for every regulatory requirement and data contract.

Looking back across these systems, the takeaway is quite clear - every one of them would be built with full specification driven development today. When an architecture demands cross-stage validation, strict domain governance and persistent operational intent, early coding velocity matters far less than systemic control.

Takeaway

The prime value of specification driven development lies in prioritizing system design over perpetual debugging. Contrary to popular belief, software engineering with AI does not remove the need for technical mastery, if anything it elevates it’s significance if the goal is to deliver dependable systems that work at scale.
`

Amazon Nova 2: A Developer's Guide to Lite, Pro, and Omni

Muthali Ganesh — Mon, 14 Sep 2026 20:31:34 +0000

Amazon Nova 2: A Developer's Guide to Lite, Pro, and Omni

Amazon's Nova model family has evolved significantly since its launch in 2024.

With Nova 2, AWS is positioning the family as a more capable alternative for developers building AI applications on Amazon Bedrock, particularly when cost, throughput, reasoning, and multimodal capabilities matter.

The interesting part isn't simply that Nova 2 is "more powerful."

It's that AWS has expanded the family into different models designed for different workloads:

Nova 2 Lite — optimized for high-volume, lower-cost workloads
Nova 2 Pro — designed for deeper reasoning and complex multimodal tasks
Nova 2 Omni — designed for broader multimodal, Any-to-Any workflows

So which one should developers use?

Let's break it down.

What is Amazon Nova 2?

Amazon Nova 2 is the second generation of Amazon's foundation models available through AWS.

Compared with the original Nova family, Nova 2 focuses on several areas:

Better reasoning
Longer context
Improved multilingual capabilities
Higher throughput
Lower inference costs
Multimodal processing
Speech understanding
More control over reasoning depth

The goal is to make the models more practical for production AI applications rather than limiting them to simple chat or content-generation tasks.

The Nova 2 model family

The easiest way to understand Nova 2 is to think about the three models as different points on a cost-versus-capability spectrum.

Model	Best for	Reasoning	Multimodal	Key advantage
Nova 2 Lite	High-volume AI workloads	Moderate	Yes	Cost and speed
Nova 2 Pro	Complex AI workloads	High	Yes	Reasoning and context
Nova 2 Omni	Advanced multimodal workflows	High	Very high	Any-to-Any processing

Let's look at each model.

Nova 2 Lite

Nova 2 Lite is the model I'd look at first for applications where inference volume matters.

It is designed for workloads such as:

Customer support
Chatbots
Classification
Document processing
Summarization
Content generation
Automation
Agent workflows

One of the biggest changes from the previous Nova Lite is the addition of extended thinking.

Developers can control how much reasoning the model performs, effectively allowing a trade-off between:

More reasoning → potentially better results

and

Less reasoning → faster and cheaper responses

Nova 2 Lite also supports more than 200 languages, making it useful for applications serving international users.

Nova 2 Lite benchmarks

According to Amazon's benchmark comparisons, Nova 2 Lite was equal to or better than:

Claude Haiku 4.5 on 13 of 15 benchmarks
GPT-5 Mini on 11 of 17 benchmarks
Gemini Flash 2.5 on 14 of 18 benchmarks

These results shouldn't be interpreted as meaning Nova 2 Lite is universally better.

Benchmarks depend heavily on the task, evaluation methodology, prompting and model configuration.

But they do indicate that Nova 2 Lite is targeting the same general category as other efficient frontier models.

Nova 2 Pro

Nova 2 Pro sits at the higher end of the Nova 2 family.

It is designed for applications that require more sophisticated reasoning and multimodal processing.

The model can work with:

Text
Images
Video
Speech

One of its most notable capabilities is a 1-million-token context window.

That can be particularly useful for applications involving large amounts of information, such as:

Long documents
Enterprise knowledge bases
Large codebases
Research workflows
Complex analysis
Multi-step agents
Large multimodal inputs

Nova 2 Pro can also be used as a teacher model for knowledge distillation, allowing developers to use a more capable model to help create smaller specialized models.

Nova 2 Pro benchmarks

According to Amazon's comparisons, Nova 2 Pro was equal to or better than:

Claude Sonnet 4.5 on 10 of 16 benchmarks
GPT-5.1 on 8 of 16 benchmarks
Gemini 2.5 Pro on 15 of 19 benchmarks
Gemini 3 Pro Preview on 8 of 18 benchmarks

Again, benchmark results are useful for comparison, but developers should test models against their own workloads before making a production decision.

Nova 2 Omni

Nova 2 Omni takes a different approach.

Instead of simply being a more powerful reasoning model, Omni is designed as an Any-to-Any multimodal model.

That means it is intended for workflows where multiple input and output modalities need to work together.

For example:

Text
  ↓
Nova 2 Omni
  ↓
Text / Image / Speech / Video

This opens up possibilities for applications involving:

Visual understanding
Speech
Video analysis
Image editing
Multimodal agents
Media workflows
Conversational applications

Omni isn't necessarily the model every application needs.

If your application is primarily text-based and requires inexpensive inference, Nova 2 Lite may make more sense.

If you need complex reasoning and large context, Nova 2 Pro may be the better choice.

Omni becomes more interesting when multiple modalities are central to the application.

Nova 2 pricing

One of the strongest arguments for Nova 2 is cost efficiency.

The original comparison published by GoML lists approximately:

Model	Input / 1M tokens	Output / 1M tokens
Nova 2 Lite	$0.30	$2.50
Nova 2 Pro	~$1.25	~$10
Claude 4.5 Sonnet	~$12+	~$12+
GPT-5 Mini / 5.1	~$8–10	~$8–10
Gemini 3 Pro	~$18	~$18

Pricing can change, so developers should always verify current Amazon Bedrock pricing before building a cost model.

The important point is that raw token price isn't the only metric that matters.

For production systems, you should also measure:

Latency
Throughput
Output quality
Retry rate
Context requirements
Reasoning requirements
Tool-call reliability
Cost per successful task

A cheaper model that requires multiple retries may ultimately cost more than a slightly more expensive model that completes the task correctly on the first attempt.

Nova 2 vs the original Nova

If you're already using Nova, the upgrade is more than just a model refresh.

Capability	Nova 1	Nova 2
Reasoning	Limited	Extended thinking
Languages	More limited	200+ languages
Context	Smaller	Up to 1M tokens
Multimodal	More fragmented	More unified
Speech	Limited/none	Supported
Throughput	Lower	Higher
Cost efficiency	Higher baseline	Improved
Image/video capabilities	More limited	Expanded

The biggest practical improvement is that developers can build more sophisticated workflows without having to stitch together as many different models.

Which Nova 2 model should you use?

Here's the simple decision tree I'd use.

Choose Nova 2 Lite if:

You care about:

High request volume
Low latency
Low cost
Chat applications
Classification
Summarization
Document automation
Straightforward agents

Start with Lite unless your application has a specific reason to require a more capable model.

Choose Nova 2 Pro if:

You need:

Complex reasoning
Large context
Multimodal reasoning
Long documents
Complex agents
Advanced planning
More sophisticated analysis

The 1M-token context window can also make Pro particularly interesting for applications where context size is a bottleneck.

Choose Nova 2 Omni if:

Your application fundamentally depends on:

Text
Images
Video
Speech
Multimodal inputs and outputs

Omni is less about simply getting "better text responses" and more about building applications around multiple modalities.

Nova 2 for AI agents

One of the more interesting use cases for Nova 2 is agentic AI.

A typical agent might need to:

Understand a user request
Retrieve information
Reason about the results
Call external tools
Inspect documents or images
Decide what to do next
Generate a response

Older or smaller models can struggle when several of these steps need to happen reliably.

Nova 2's reasoning capabilities make it more suitable for these multi-step workflows.

A simplified architecture could look like:

User
  ↓
Agent
  ↓
Nova 2
  ↓
┌───────────────┐
│ Tool calls    │
│ RAG           │
│ APIs          │
│ Databases     │
│ Documents     │
└───────────────┘
  ↓
Final response

The important thing is not to automatically use the most powerful model for every step.

A better architecture may use different models for different parts of the workflow.

For example:

Simple classification
        ↓
   Nova 2 Lite

Complex reasoning
        ↓
    Nova 2 Pro

Multimodal analysis
        ↓
   Nova 2 Omni

This can help control inference costs while maintaining quality where it matters.

Is Nova 2 better than GPT, Claude or Gemini?

There isn't a universal winner.

Different models perform differently depending on the task.

For developers, the better question is:

Which model gives me the best cost-adjusted performance for my workload?

For example, you might compare models using:

Cost per successful task
        +
Latency
        +
Accuracy
        +
Reliability
        +
Context requirements

A model that wins a benchmark but performs poorly on your application's real data isn't necessarily the right model.

If you're deploying on AWS already, Nova 2 has another advantage: it fits naturally into the Amazon Bedrock ecosystem.

That can simplify infrastructure, security, access control and model management for AWS-based applications.

What should developers test?

Before choosing Nova 2 for production, build a small evaluation set.

Include real examples from your application rather than generic benchmark questions.

For each model, measure:

Metric	What to measure
Accuracy	Does it produce the correct answer?
Latency	How quickly does it respond?
Cost	Cost per request/task
Reliability	How often does it fail?
Reasoning	Can it complete multi-step tasks?
Context	How much information can it handle?
Multimodal quality	How well does it understand images/video/audio?

Then calculate the cost per successful task, not just the cost per million tokens.

That's usually a much more useful metric for production AI.

Final thoughts

Nova 2 makes Amazon's model lineup considerably more interesting for developers building on AWS.

The biggest change isn't simply better benchmark scores.

It's the combination of:

More capable reasoning
Longer context
Better multimodal support
Lower inference costs
Higher throughput
More control over reasoning

For most high-volume applications, Nova 2 Lite is a logical starting point.

For complex reasoning and large-context applications, Nova 2 Pro is more compelling.

And for applications where text, image, video and speech need to work together, Nova 2 Omni is the model worth exploring.

The best approach, however, is still the same one developers should use with any LLM:

Benchmark the model against your actual workload before committing to it.

Your application—not a leaderboard—should determine which model wins.

This article is adapted from GoML's original Nova 2 analysis and rewritten for a developer-focused audience.

Original: GoML — Nova 2 Guide

Schema tester

Muthali Ganesh — Sat, 06 Apr 2024 19:12:04 +0000

<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Article", "name": "All-weather road gives a strategic fillip to Ladakh", "author": [ { "@type": "Person", "name": "Peerzada Ashiq" }, { "@type": "Person", "name": "Peerzada Ashiq" } ], "datePublished": "2024-04-07T00:15", "image": "https://th-i.thgim.com/public/incoming/lns9r3/article68037534.ece/alternates/LANDSCAPE_1200/PTI03_27_2024_000017A.jpg", "articleBody": "The Border Roads Organisation’s (BRO) latest feat in Ladakh, connecting Himachal Pradesh and Leh through the Nimmu-Padam-Darcha road, has come as a shot in the arm for security forces stationed in the region, and added significantly to India’s strategic depth in the hostile border neighbourhood. </P><DIV class=\"article-ad\"><DIV class=\"dfp-ad articleinlinead\" id=\"Desktop_AT_Mid01\" style=\"min-height: 90px;\"></DIV></DIV><P>The BRO’s breakthrough, achieved on March 27 this year, has paved the way to open up the far-off Zanskar Valley for the safest ordnance depot, away from the prying eyes of China and Pakistan, officials privy to the development told <I>The Hindu" } </script>

How to scrape google search results in Google sheets ?

Muthali Ganesh — Wed, 08 Sep 2021 09:59:10 +0000

I had written this original article on my website aozata.com . Wanted to share this method with the dev community here at Dev.to.

Here are steps to scrape google search results in google sheets. It only gets 10 results per search query.

Create a google sheet in your google drive.
Create a google custom search engine.
Enable search the entire web.
Copy your google custom search engine id.
Get your google custom search api key from here
Formulate your api key in this format.

https://www.googleapis.com/customsearch/v1?key={YOUR_API_KEY}&cx={CUSTOM_SEARCH_ENGINE_ID}&q={KEYWORD}

key is your API key,
cx is your google custom search id.

In your google sheets, go to tools-> script editor-> paste the following code->save the file as ImportJSON.gs. The ImportJSON.gs can be downloaded from here https://www.aozata.com/importjson-gs/
Enter the cx, key, search query (q), API URL in different cells.
Use the concatenate function to join all these 4 variables to get your final API URL. For example

=concatenate(D4,D2,"&cx=",D1,"&q=",D3)

Use the ImportJSON function to import the google search results. for example to get the title of the search results

=ImportJSON($D$5,"/items/title","noHeaders")

You can buy this google sheet from here.