标签：#codequality

How I Built a Full-Stack Quality Skill for AI Coding Agents AI coding agents are getting very good at writing code. But I kept running into the same problem: They can move fast, but without strong project rules they can also create messy architecture, duplicate utilities, inconsistent APIs, weak security checks, and frontend components that slowly drift away from the design system. So I built Full-Stack Quality Skill . It is a reusable AI coding skill for full-stack audits, architecture guidance, long-term project memory, and CI quality gates. Repo: https://github.com/lablnet/full-stack-quality-skill Website: https://skills.lablnet.com Why I Built It When I use AI agents like Cursor, Codex, Claude Code, Antigravity, or similar tools, I do not only want them to "write code". I want them to think like a careful senior engineer: Is the database normalized correctly? Are backend layers clean? Is business logic leaking into controllers? Are frontend components consistent? Are Vue components using composables? Are React components using hooks correctly? Are HTTP methods and status codes right? Is GraphQL safe from N+1 problems? Are security and privacy risks checked? Are tests missing for critical paths? Is documentation still matching the code? That is a lot to remember every time. So instead of repeating the same instructions in prompts, I turned them into a reusable skill. What It Covers The skill includes audit areas for: Database Backend Frontend Mobile HTTP APIs GraphQL Security Privacy Accessibility i18n Analytics Background jobs Infrastructure Testing Performance Observability Delivery / CI Multi-tenancy Payments Notifications Data import/export API compatibility Developer experience AI/LLM safety It also includes examples for common stacks: Node.js / TypeScript Python Django Laravel Java / Spring C# / ASP.NET Core Go Ruby on Rails React Next.js Vue Angular SvelteKit Flutter React Native Kotlin / Android Swift / iOS SQL GraphQL Read-Only Audits by Default One impo

If you’ve spent any time recently writing detailed product requirement documents or meticulously...

This is the workflow I follow before I use AI agents to implement any feature or bug fix. 🧭 Requirements/Specification ↓ Design/Architecture ↓ AI Code Generation ↓ Human Review ↓ Build & Static Analysis ↓ Testing & Validation ↓ Defect Resolution ↓ Security & Compliance Review ↓ Release ↓ Production Monitoring vs Claude Code ↓ Implements feature ↓ Codex QA Agent ↓ Runs application ↓ Tests happy path ↓ Tests edge cases ↓ Tests error handling ↓ Produces QA report This will resolve the self-review bias, confirmation bias, or AI-to-AI bias. 1️⃣ Understand Before Writing Code Before touching any code, I try to understand what I'm building and why . I usually start by reading: specs/<module>/<TICKET>-<slug>.md plan/<module>/<TICKET>-<slug>.md status.md Then I review the project conventions: specs/CONVENTIONS.md specs/conventions/core-porting.md Finally, I read the existing implementation (entities, services, mappers, etc.) so my changes follow the existing architecture instead of introducing a new style. 💡 Pro-Tip Good code fits into the codebase. Great code looks like it was always there. 2️⃣ Plan the Change Once I understand the requirements, I identify which architectural layers are affected. I always respect the dependency order: Schema / Entities / DAOs ↓ Mappers / DTOs ↓ Service Layer ↓ Application Layer ↓ Controllers I don't jump ahead of dependencies. If a change is complicated or ambiguous, I document the approach before writing code. --- ## 3️⃣ Write the Code While implementing, I follow the repository's rules. Some examples: | Rule | Detail |---|---|---| | DTOs | Generated from `schema.yml` — never handwritten | | Status values | Sourced only from the Core Porting specification | | Traceability | Every ported behavior includes a source citation | Citation formats I use: - `← Source <path>` - `← PS §...` - `← BR-###` Beyond repository rules, I also try to: - ✅ Match existing naming conventions - ✅ Keep comments minimal and meaningful - ✅ Make small, focused chang

A developer added an AI reviewer to a small Node and React project expecting an easy win. At first, the comments looked useful. Then the reviewer started repeating style complaints, commenting on code that had already changed, and missing a misplaced null check that crashed the application in staging. The team still had to perform a complete human review. That experience, shared in a public DevOps discussion, captures the real question engineering leaders should ask before adding an AI reviewer to every pull request: Did the reviewer remove work from the team, or did it create another thing the team had to review? The problem is not that AI review never works Developers report genuinely useful results too. In one Experienced Developers discussion, engineers described AI reviewers catching privacy leaks, incorrect data-flow assumptions, and logic errors that human reviewers had missed. In the same discussion, another engineer said their review bot was useful but produced plausible, inaccurate comments about one-third of the time. These are anecdotes, not a benchmark. But together they explain why the debate feels confused. AI review is not simply good or bad. Its value depends on the codebase, the context available to the reviewer, the kind of issue being reviewed, and how much verification its output requires. A tool can catch one subtle bug and still make the overall review process slower. It can also say nothing on several pull requests and then save a team from a serious failure. Counting comments cannot distinguish between those outcomes. Comment volume measures activity, not value GitHub says Copilot code review has completed more than 60 million reviews. Its definition of a good review has changed as that volume has grown. The team says it moved from optimizing for thoroughness to optimizing for accuracy, signal, and speed. GitHub reports actionable feedback in 71% of Copilot reviews. In the other 29%, the reviewer says nothing. That silence is intentional: if

Gone are the hours of careful thought and planning that go into coding a new feature. Vibe coding is too risky though, so another Driven Development was created. I'm referring to SDD (Spec Driven Development) of course. The vibe coding approach is great for prototypes and throwaway code, but this way of working falls apart when teams realise that the code needs to be maintained. So the thing that helps fix this is SDD. Create a spec once from clear technical specs and then generate some high quality code. Sounds great, right. Reminds me of IaC, where you use a templating language to create infrastructure. Software as Code maybe. SaC anyone? Unfortunately, in practice it's not that straightforward. Thoughtworks have placed SDD into an "Assess" category and warned that it could be an anti-pattern for releasing software. Deterministic vs Probabilistic This article isn't about SDD. I'm more interested in discussing the output of SDD and how that is tested. Code can now be generated fast these days. So what better to test AI-written code than with AI itself. There are a lot of concepts and technical terms for the Quality Assurance part of AI generated code. One of these is the LLM-as-a-Judge idea. This idea is used to score the output of an LLM based on some explicit criteria. Traditionally, the way to evaluate an LLM was to judge its output on the helpfulness or faithfulness (using something called "exact-match" metrics). Sometimes it was usually down to a human to do this. It also changes the way that Quality is Assured when dealing with AI-written code. Traditional QA is built on deterministic checks; either something does or does not fail. Something like expect(x).toContainText(y); . A failing test means that something is wrong. Then the bug can be fixed in the code and the test will pass. However, the outputs of an LLM are probabilistic , so it breaks the traditional pass/fail model. This is where a judge comes in. Instead of pass/fail, it can assign a score based o

There is a growing sentiment in engineering circles right now that documentation is a relic of the past. The argument usually goes something like this: We’re living in the era of agent-driven development. If an AI agent can read the raw source code or parse an OpenAPI specification instantly, why waste human engineering hours writing prose? Code churns too fast anyway, and human-written docs are outdated the second they’re committed. It’s an attractive, black-and-white view of the world. It’s also completely wrong. Chasing strict determinism in your source of truth is a pipe dream. Code and specs tell a system how something works, but they are fundamentally incapable of explaining why it was built that way in the first place. The Intent Gap: Why Code Isn't Enough Even if you’re building entirely for a downstream consumer of AI agents, there is a massive, structural gap between a raw API specification and an operational reality. Agents are phenomenal at pattern matching and syntax execution, but they struggle with architectural philosophy and human intent. We still need words to contextualize the boundaries. A spec can define an endpoint, its parameters, and its payload. What it can't capture is the nuance of why a specific architectural trade-off was made, or the implicit historical context of a legacy edge case. Prose provides the guardrails for non-deterministic systems. Even if that prose is ultimately consumed by a machine rather than a human, the written word remains the highest-leverage way to transmit intent. The Danger of Slop Describing Slop This doesn't mean we need to return to the days of manually maintaining massive, static wiki pages. Automation has a massive role to play here. Cascading automation—where documentation is dynamically generated alongside code changes—is incredibly powerful. But there’s a trap here: slop describing slop is entirely useless. If we completely hand off documentation generation to unchecked LLMs, we end up with a feedback loo

A while back I set three targets for my engineering team. Not velocity. Not story points. Not "things shipped." Just three numbers. Together they tell me whether the work is moving the way it should, or whether next week is shaping up to be a fire-fighting week. I check two of them most days. The third I used to watch closely...until we lost the tool that measured it. Here they are, and why they earned their spot. Why these and not just velocity The first metric most engineering managers reach for is velocity. Story points completed, tickets closed, work merged. Velocity is worth watching. It is a lagging indicator...it tells you what already happened...but it still shapes what comes next. When a sprint's work doesn't get finished, it rolls into the following one, and that rollover eats into whatever you had planned. What velocity doesn't tell you is how the work moved...whether it moved in a way that's going to come back and bite you. For that you need numbers that describe the shape and quality of the work, not just the amount of it...ideally ones that flag a problem while there's still time to act. These three do that. 1. Average PR size Target: under 300 lines changed per PR. What it tells me: how well the team is decomposing work. A team consistently shipping oversized PRs isn't producing more... they're producing PRs that no reviewer can read carefully. Big PRs get rubber-stamped. Rubber-stamped PRs are where production bugs hide. The 300-line target isn't magic. It's roughly the size below which most reviewers will actually read every line. I tell my team to aim for under 300 changes and to treat 500 as a hard ceiling, give or take a handful of genuine exceptions. Past 500 changes, I consistently see quality, review time, and thoroughness all drop sharply...the PR stops getting read and starts getting skimmed. When the team's average creeps up over a few weeks, I have an early signal that one of three things is happening: Stories are too coarse. The work does