How GeekyAnts Uses AI in Software Engineering: From Requirements to Release

Oct 16, 2026

How GeekyAnts Uses AI in Software Engineering: From Requirements to Release

This blog explains how GeekyAnts uses AI across software development while maintaining human oversight, quality checks, and engineering accountability.

AI coding agents can turn a feature request into screens, database changes, and tests. The risk begins with an unresolved business rule. Generated code may meet the written instructions while missing the intended behavior. Google's 2025 DORA research found that AI amplifies an organization's existing strengths and weaknesses. Across three GeekyAnts projects built with AI coding agents in 2026, engineers retained decision-making authority while agents handled substantial development work.

The projects were a clinical education platform developed over six months with around 1,500 commits, a family-records mobile and web app built in four weeks across 73 working sessions, and ga, an internal engineering assistant. A commit records a set of code changes. AI models appeared as co-authors on 429 of ga's 439 commits. These examples reflect the practices of the project teams involved.

Which Engineering Activities Use AI at GeekyAnts?

The teams assigned agents tasks with written inputs and defined stopping points. The responsibilities followed a shared pattern, with differences in tools and approvals across projects.

Activity

AI responsibility

Engineer responsibility

Requirements

Draft specifications and identify conflicts in source documents

Confirm scope and resolve open decisions

Planning

Divide approved requirements into tasks with acceptance criteria, the conditions for completion

Approve the plan and system design

Implementation

Produce application code, database changes, and system connections

Review changes against approved requirements

Testing

Create test cases and exercise application workflows

Judge failures and accept completed work

Review and debugging

Inspect code changes and trace defects

Assess findings and authorize fixes

Documentation

Draft technical guides, test reports, and release notes

Check claims against the delivered software

The clinical education team created task-specific commands for each stage. Its technical requirements document (TRD) described data, system connections, risks, and performance targets. Development commands followed linked designs in Figma, a screen-design tool, and used the project's existing components. Reviewer and debugger agents could inspect files but lacked permission to edit them.

For the family-records app, one engineer directed Claude Code, an AI coding tool, across a server application, mobile app, and website. The agent performed 534 actions in simulated iOS and Android devices, giving the engineer running screens to inspect for design and usability problems. ga took another approach: it organized client documents, designs, and existing code into a knowledge base with references to the original material. That record supplied context for implementation tasks.

Which Decisions Require an Engineer's Approval?

On the clinical education platform, a specification remained a draft until an engineer approved it. The implementation command checked the approval status and stopped on an unapproved document. Front-end planning required links to Figma designs. Missing designs triggered a request for input from the team.

In the family-records project, the agent raised 52 structured product and architecture questions, each with proposed answers. The engineer's responses became numbered decisions used throughout the build. During development, the engineer interrupted the agent 14 times and rejected eight proposed tool actions. Corrections addressed work outside the approved scope, hand edits to generated database schemas, and raw database errors appearing in user-facing responses.

The ga assistant enforced four rules beyond project configuration: permission before destructive actions, protection of secrets, permission before pushing code to a shared branch, and human approval of knowledge entries. A push transfers code to the shared project record. A merge combines a proposed change with the shared code. The clinical team kept proposed changes in feature branches, separate workspaces for changes pending review. Pushes, merges, and releases required engineer authorization. In the family-records app, merging an AI feature and enabling it were separate approval decisions. ga required a fresh approval for each outward-facing action, including release tags.

Six-step review of AI-generated code, with human approvals and a fix-and-retest loop for failed quality checks

What Quality Gates Must AI-Generated Work Pass?

Quality gates are checks that a change must pass during development or release. The projects used different combinations of automated checks and human review. The table groups their checks by purpose without treating every project rule as a company-wide standard.

Quality gate

Evidence required

Requirement coverage

Ticket identifiers, approved specifications, and tests linked to identified edge cases

Code and architecture

Formatting checks, TypeScript checks for data-type errors, and rules against prohibited dependencies

Security and data handling

OWASP Top 10 checks for common web security risks, scans for exposed secrets, and tests for restricted data in storage or logs

Accessibility and performance

Accessibility checks at 375, 768, and 1280 pixel widths, plus website scores and service response targets

Release readiness

Passing builds and tests, documented configuration, verified database changes, and application startup checks

On the clinical education platform, billing integration tests connected to PostgreSQL and Redis, with a payment provider in test mode. The project used Lighthouse, a website assessment tool, with minimum scores of 80 for performance and 90 for accessibility, best practices, and search-engine optimization. Its service targets required 95% of requests to finish within 200 milliseconds, 99% within 500 milliseconds, and an error rate below 1%. The pre-deployment check returned BLOCKED on failure.

The family-records project recorded about 1,230 test runs, 475 code-rule checks, and 214 direct database checks. Live application testing uncovered defects the smaller tests missed. Google Drive uploads failed because the total request size was submitted as the file size. A PDF viewer counted requests for individual pages as separate document views. A background worker failed to start because of a faulty connection between software components.

The team inspected its safeguards as well as the application. One audit found a misspelled command in a check that ran before commits. The error prevented a scanner for exposed secrets from running. ga applied a different safeguard: each task began with a failing test and finished with a passing one, followed by a run of the complete test suite. Its reviewers checked security, missing tests, and silent failures, while working application builds confirmed that generated templates could start and serve requests.

Who Owns AI-Generated Changes in Production?

The engineer who approves and merges a change takes responsibility for that code in production. AI co-authorship records tool involvement; a person remains accountable. The clinical education project's records connected approved specifications, ticket identifiers, and named reviewers to the delivered changes. Its repository retained technical rules and decisions for the next engineer to inspect. A repository is the shared location for project code and its change history.

The family-records team's numbered decision log preserved the reasoning behind product choices. For ga, engineers reviewed the final report before accepting the work. During one test run, an agent's draft report counted six tasks with tests written ahead of code; its correction identified seven. The discrepancy illustrates the need to verify generated progress reports against project evidence.

What Does This Mean for Engineering Delivery?

AI coding agents can handle a substantial share of software development, from preparing requirements to checking completed features. The three GeekyAnts projects show the controls supporting that work: recorded product decisions, tests against running systems, restricted tool permissions, and engineer-approved releases. For clients, those records offer a way to examine what the team built, which risks received review, and who accepted the production change. Explore GeekyAnts' engineering delivery approach for its broader delivery practices.

Subscribe to Our Newsletter

More from the engineering frontline.

Dive deep into our research and insights on design, development, and the impact of various trends to businesses.
Insight
How to Hire Fintech Software Developers: Skills, Costs, and Hiring Models
Oct 15, 2026

How to Hire Fintech Software Developers: Skills, Costs, and Hiring Models

This blog explains how to hire fintech software developers by evaluating domain expertise, technical skills, security, compliance, hiring models, costs, and production experience.

Insight
Which GeekyAnts Clients Can Provide References? How Our Client-Reference and NDA Process Works
Oct 14, 2026

Which GeekyAnts Clients Can Provide References? How Our Client-Reference and NDA Process Works

This blog explains how GeekyAnts handles client-reference requests, including client selection, consent, NDA restrictions, and alternatives when a reference call is unavailable.

Insight
How to Choose an AI Product Development Company: 20 Questions About Production Experience, Security, Data, and ROI
Oct 13, 2026

How to Choose an AI Product Development Company: 20 Questions About Production Experience, Security, Data, and ROI

A buyer's guide to choosing an AI product development company, built around 20 questions that separate production evidence from sales claims across architecture, security, data, cost, and ownership. It adds a 0 to 3 scoring method, a red-flag read, and a pre-signing checklist so a team can compare vendors on what they can actually prove.

Insight
How to Build a Payment Gateway: Cost, Architecture, Compliance, and Development Roadmap
Oct 12, 2026

How to Build a Payment Gateway: Cost, Architecture, Compliance, and Development Roadmap

Get insights on how to build a payment gateway with enterprise architecture, development costs, compliance requirements, security, and a practical development roadmap.

Insight
Frequently Asked Questions About Hiring GeekyAnts for AI Product Engineering and BFSI Modernization
Oct 12, 2026

Frequently Asked Questions About Hiring GeekyAnts for AI Product Engineering and BFSI Modernization

Get answers to common questions about hiring GeekyAnts for AI product engineering and BFSI modernization, including experience, team structure, security, costs, engagement models, IP ownership, and post-launch support.

Insight
From Test Failure to Root Cause: Building an AI-Assisted Playwright Failure Analysis Pipeline
Oct 9, 2026

From Test Failure to Root Cause: Building an AI-Assisted Playwright Failure Analysis Pipeline

This blog explains how an AI-assisted Playwright pipeline can analyze test failure evidence, identify probable root causes, and support human-validated debugging.

Insight
The Model Context Protocol: From First Call to Production
Oct 8, 2026

The Model Context Protocol: From First Call to Production

This blog explains how Model Context Protocol (MCP) works, from tool discovery and execution to OAuth authorization, security controls, and production deployment.

Footer

The Right Conversation Can

Save You Six Months.

Book a Call