nishiohiroshi

Ran a broken link audit on our site and found 12 pages linking to URLs that 404. One was a settings path that moved months ago, another was a dynamic GitHub link rendering "null/null" when no repo was selected. Cleaned them all up - crawlers and users both deserve working links.

- Change base pricing from $3 to $4 per PR in config/pricing.ts - Calculate free credits dynamically as 3x per-PR price ($12) - Update all E2E test expectations for new pricing - Update blog posts with new pricing information - Update JSON-LD structured data for SEO - Update integration test data and expectations

- New case study: How we dogfooded GitAuto to reach 92% coverage - Include coverage growth chart showing all three metrics - Explain daily routine, results, and one downside (GitHub Actions costs) - Add test suite metrics: 242 files, 2,680 test cases, 3min runtime

GitAuto creates unit test PRs, runs the tests, and fixes failures if any, to boost your test coverage from 0% to 90% – and keeps it there. Runs on schedule or triggers from PRs.

## What's new:

- Schedule Trigger: Runs daily, targeting lowest coverage files first. Set once, forget about it. Perfect for teams starting from 0% coverage - PR Triggers: Add tests during PR creation or after merge. Choose based on your CI/CD requirements - Smart Rules: Configure best practices through UI - no more manual rule management - Coverage Analytics: Visual charts showing repository coverage trends over time

Built for teams serious about code quality. Try it: https://gitauto.ai

You can now schedule GitAuto to run up to 12 times per day at custom intervals (every 5-60 minutes). This means faster test coverage improvements without waiting for the next daily run.

Perfect for active development cycles where you want continuous test coverage improvements throughout the day. Set it to run every 30 minutes during work hours, or every hour throughout the day - whatever fits your team's workflow.

Configure it in Settings → Triggers → Schedule settings. Choose your execution count and interval, and GitAuto will automatically target the lowest-coverage files first, multiple times per day. https://gitauto.ai/settings/triggers

Configure your testing preferences once here https://gitauto.ai/settings/rules, then GitAuto automatically maintains your code quality.

Now with full feature access on free tier:

- Set up your testing rules and coverage standards - Choose which triggers work for your workflow (PR merges, schedules, labels) - GitAuto handles unit test generation based on your preferences - Your team focuses on features while tests get written automatically

The result: consistent test coverage without constant manual effort. Your testing standards get maintained automatically once you define what you want.

Free tier has usage limits but no feature restrictions.

GitAuto now runs on autopilot!

You can now schedule GitAuto to automatically create unit tests at specific times, ensuring your codebase maintains high test coverage without any manual intervention. https://gitauto.ai/settings/triggers

## What this means for you:

Set it and forget it - Configure once, get continuous test coverage improvements Consistent quality - Tests are generated daily at your preferred time Zero interruptions - No more manual triggers or remembering to run GitAuto Smart prioritization - Automatically targets files with the lowest coverage first

## Perfect for teams who want to:

- Maintain 90%+ test coverage effortlessly - Reduce technical debt continuously - Free up developer time for feature work - Ensure new code always has proper test coverage

## How it works:

1. Enable “On schedule” trigger in your repository settings 2. Set your preferred daily run time 3. Don't forget to review your coding style here https://gitauto.ai/settings/rules 4. GitAuto automatically creates test issues & PRs at scheduled times 5. Review and merge or leave review comments and GitAuto will make fix commits

No more excuses for low test coverage. GitAuto works around the clock so your team doesn’t have to. Start scheduling your automated testing today!

We've shipped a comprehensive rules engine that gives developers precise control over how GitAuto generates tests for their codebase.

## What's new:

- 20+ structured configuration options across coding standards, test file organization, and component testing - Language-specific test naming conventions (JS/TS, Python, Go, Java, Ruby) - Flexible test constants management with auto-detection - Component isolation controls for React/Vue applications - Custom integration test file patterns - Free-form rule descriptions alongside structured settings

## Why this matters:

Instead of one-size-fits-all test generation, teams can now align GitAuto with their existing conventions and coding standards. Whether you prefer `filename.test.js` or `test_filename.py`, centralized test constants or inline data, GitAuto adapts to your workflow rather than forcing you to adapt to ours.

## The outcome:

Developers spend less time fixing generated tests and more time shipping features. Tests feel native to your codebase because they follow the same patterns your team already uses. Perfect for teams who want AI-generated tests that don't feel like they were written by AI.

GitAuto can autonomously resolve test failures. In real-world development, a single workflow run can encounter multiple errors. For example, even after fixing one error, another might appear later in the same workflow. In such cases, GitAuto retries automatically. If separate workflows fail with different errors, GitAuto generates individual fixes for each. However, if the same error persists in the same workflow even after a fix commit – meaning the fix didn’t work – GitAuto stops to avoid an infinite loop.

Through observing our customers' behavior, we've noticed a common challenge when teams want to improve their test coverage: identifying which files to tackle first. Without a clear overview of low-coverage files, developers often resort to randomly selecting files or relying on gut feelings. This initial hurdle of "where do we even start?" can significantly slow down or even halt test coverage initiatives, often leading teams to abandon the task entirely.

That's why we're introducing this coverage dashboard. It provides an instant, clear view of which files need attention, eliminating the guesswork from test coverage improvement. In this guide, we'll show you how to set up automated test coverage reporting for your Flutter / Dart project and use GitAuto to improve coverage systematically.

GitAuto is a QA coding agent. The GitAuto's Coverage Dashboard is a new tool that displays test coverage data for repositories where GitAuto is installed. It helps users create GitHub issues for improving test coverage.

The help content outlines four main steps:

1. Select Repository: Users need to choose an Organization and Repository to begin.

2. Refresh Coverage: First-time users should click the "Refresh Coverage" button in the Actions menu.

3. Wait for Analysis: The system takes 5-10 minutes to: - Clone the repo - Install packages - Build the project - Run tests - Generate and analyze test reports - Show coverage data (This process doesn't use any credits)

4. Create Issues: Users can create GitHub issues for files that have low test coverage, particularly for important functions or classes. GitAuto can be assigned to these issues, and creating them doesn't consume credits.

## Default Model Update: Claude 3.5 Sonnet

We have updated our default model to Claude 3.5 Sonnet, prioritizing its superior coding capabilities, especially in handling edge cases for test scenarios. This decision was influenced by the model's effectiveness compared to OpenAI o3-mini.

While Claude 3.7 is available, feedback on platform X highlights its tendency to be overly opinionated and occasionally disregard user instructions, opting to avoid rather than solve problems. Consequently, we chose not to set it as the default.

A new feature will soon allow users to switch models individually, but based on current experience, Claude 3.5 remains our top recommendation. Despite occasional slowness when using Claude 3.5, its popularity and effectiveness are evident, as seen with its high usage in Cursor, unlike the less crowded Claude 3.7.

I'm sharing these use cases about reverse engineering specifications that I've heard directly from clients, but I deeply relate to them myself. Back when I was on the business side, I'd often ask engineers for documentation only to hear "the code is the documentation." That moment created a real disconnect—I felt completely shut out from understanding the products I was responsible for.

This solution isn't just about solving a technical problem—it's about bridging worlds that too often remain separate.

Background: When GitAuto rummages through files in a repository, it assumes the files are large and allows specifying line numbers to reduce noise. However, due to a quirk—possibly related to the o3-mini model GitAuto uses—it sometimes unnecessarily specifies the first line. In such cases, GitAuto should read all lines, just as it would when no line numbers are specified.

When a bug pops up, what do you do? Fix it? Ignore it? Does your logging tool catch it? Or do you only find out when a customer complains? But, hey, the stuff you gotta do this week doesn't change, right? Wouldn't it be awesome if you could whip up a fix PR as soon as a bug hits? Error logs aren't always clear, can mislead, and often don't reveal the cause, so you can't say you'll fix everything 100%. Still, it might cut down the initial investigation big time. So, we ran an experiment combining a logging tool with an AI Coding Agent to see if we could create a fix PR right after a bug shows up.

Back in the day, when manual testing was the norm, folks would spend ages crafting test specs in Excel and have someone else review them. But when it came time to actually run the tests, they'd often be short on time or things wouldn’t go smoothly. This led to fudging results since everything was manual. This kind of thing was common, and there were constant inquiries into why these fudging occurred and how to prevent them.

Now? Automating tons of tests and running them instantly is a breeze. I wrote an article showing how you can use an AI coding agent, GitAuto, to whip up integration test PRs in minutes, run those tests immediately, and keep them running continuously going forward. If you're in a similar boat, give it a shot.

Back in the day, when manual testing was the norm, folks would spend ages crafting test specs in Excel and have someone else review them. But when it came time to actually run the tests, they'd often be short on time or things wouldn’t go smoothly. This led to fudging results since everything was manual. This kind of thing was common, and there were constant inquiries into why these fudging occurred and how to prevent them.

Now? Automating tons of tests and running them instantly is a breeze. I wrote an article showing how you can use an AI coding agent, GitAuto, to whip up integration test PRs in minutes, run those tests immediately, and keep them running continuously going forward. If you're in a similar boat, give it a shot.

GitAuto can now reference the parent issue’s number, title, and body (description) when triggered from a sub-issue. GitHub introduced issue parent-child relationships in October 2024 (beta). Since the REST API does not yet support this feature, GraphQL is used instead.

With this update, users can create a main issue for tasks like unit test creation, integration test creation, or external specification writing, and then create sub-issues for specific files or functions. Common requirements—such as using functions instead of classes, using Jest for JavaScript, or specifying a test constants file—can be documented in the parent issue’s body. This eliminates the need to repeatedly open requirement documents when writing sub-issues, allowing sub-issue bodies to focus only on sub-issue specific details, making the process more efficient.