Engineering AI agent · Code generation
Code-Generation & Review AI Agent
Source every suggestion at the moment it is offered — the model, its version, the filter settings and the hunks kept — then hold the change for the named engineer who commits it.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named engineer
- Per suggestion
- After launch
- Agent Care
What this agent does
Suggests the hunk, never signs the commit
In
- 01
A completion is offered, and the model, its version and the filter settings go down beside it.
- 02
A commit is signed by a person, and the machine origin beneath that signature stops being visible.
Reason
- 03
A hunk is machine-written, and copyright does not reach that portion standing alone.
- 04
A registration is prepared, and 88 FR 16190 asks which content is AI-generated and excluded.
- 05
A routine is reproduced, and GPLv2 § 2(b) reaches the whole work it was distributed inside.
Decide
- 06
A licence claim is pleaded in contract, and in Doe v. GitHub the contract claims are what survive.
- 07
A filter setting is changed, and a vendor indemnity condition can turn on that single setting.
Out
- 08
A diligence team asks who wrote a file, and the git history answers with a human name.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Suggestion, provenance and the record belong to the agent. The commit belongs to a named engineer, who takes the change into the product and owns it there.
Example workflow
One suggestion, offer to commit
- 1Editor request receivedAn open file, a diff under review, a failing test or a pull-request comment
- 2Context and provenance assembledThe branch, the file, the model and its version, the filter settings and the licence rules configured
- 3Suggestion producedThe hunk, the resemblance flags, the provenance record and confidence
- 4Controls appliedLicence-resemblance checks, filter-setting checks, secret checks and confidence
No human action required
Stages 1 to 4 run unaided, and nothing is committed at any of them — the agent is suggesting, and the engineer lane opens at the confidence gate.
Goes to the named engineer to commit.
Adds a code-owner read first.
Engineer review
The hunk is held with its provenance, its resemblance flags and the confidence.
Commit · Amend · Send to code-owner review
Committed — by a named engineer
- 6Repository and forge records updatedOnly where write access and branch policy allow it
- 7Outcome evaluatedAcceptance rate, amend distance, resemblance-flag outcomes and post-merge defects
Amendments
Each engineer amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Placing a suggestion into the repository.
- Deciding that a flagged hunk is safe to ship.
- Accepting a licence obligation on the codebase.
- Changing a vendor configuration an indemnity rests on.
Automation boundary
Agent acts unaided
- ✓Draft the hunk from the file open in the editor.
- ✓Record the model, its version and the filter settings.
- ✓Flag a suggestion that resembles a source under a known licence.
- ✓Hold the flagged hunk for the engineer who will sign the commit.
Nothing enters the repository except by a named engineer, inside the agreed boundaries.
- Signing an IP representation in a transaction.
- Deciding what a copyright registration discloses.
- Saying that a review was substantive.
- Changes to the SDLC policy or automation thresholds.
Example output
One suggestion, annotated
The PLC automation copilot in manufacturing drafts industrial control logic to a controls standard; this one suggests general application code, and the question it raises is who owns what came back.
Suggestion output · single hunk
Illustrative example- Suggestion
- Retry loop with exponential backoff
- Recorded as
- Stamped with model and version
- Repository
- Payments service, main
- Evidence of record
- Editor session, 3 August 2026
- Confidence
- Held uncommitted
- Held for
- The named engineer, by name
As received
Taken from the open file and the rules set for that repository, and it claims nothing beyond them.
What the record holds
- Model and version
- Filter settings
- Hunks kept
Why no commit here
Taking a suggestion into the product is a judgement an engineer makes.
What the score decides
Below the configured threshold a hunk gets a code-owner read before the engineer sees it.
Action
CommitAmendSend to code-owner reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Each suggestion
From the branch it was read on
Which rules reach a copilot
Biometrics, infrastructure, education, employment, essential services, policing, migration, justice — the Annex III areas, and a coding copilot is in none of them.
Whose code is this now
Registration requires a human author, and Thaler v. Perlmutter, No. 23-5233, decided by the D.C. Circuit on 18 March 2025, went unreviewed when certiorari was denied.
What was checked, and not found
No statute found requires source code to be reviewed before it is committed, and none requires a record of which lines a machine wrote; the nearest binding instrument is PCI DSS 6.2.3, a card-brand contract. What answers a claim years later is that record, or nothing.
Build an evidence trail
The suggestion, the source it resembles and the developer who committed it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Editors and IDEs
- VS Code
- JetBrains
- Neovim
- Editor and language-server hooks
Source forges
- GitHub
- GitLab
- Bitbucket
- Pull requests and branches
Vendor and model settings
- Filter modes
- duplicate detection
- Configuration and change history
Agent
Code generation and review
- Reads the branch
- Suggests the hunk
- Holds for the engineer
Scanning and policy
- Licence scanners
- SAST
- Licence, dependency and secret findings
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six sieves between the model and the commit
Six sieves in one column, the last the finest. What settles is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a hunk may stand
- L3
- Leaves the commit to a named engineer
- L4 – L5
- Keep the commit and the suggestion behind it
- L6
- Offers no completion at all when signals degrade
How Nestack evaluates it
Evaluate the whole suggestion path — not only the hunk that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the code that ships in the product
- E1Final-output evaluationDid the suggestion record the model and settings it was actually produced under?
- E2Step-level evaluationDid the agent read the right branch, the right file and the live licence rules?
- E3Tool evaluationDid it read and write the correct repository and the correct file?
- E4Confidence calibrationDo low-confidence suggestions actually attract more engineer amendments?
- E5Slice evaluationHow does performance change across specific repository classes?
- E6Business outcomeHow many suggestions needed an amendment before the engineer committed?
Floor — the codebase the company must defend
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed where it first becomes visible.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- QR-03
Stale branch context
The file read is not the one now on the branch.
Stage gathers
The branch, the file, the model version and the rules
02 · Reasoning
2 modes
- QR-04
Resemblance missed at drafting
A suggestion echoes a source no rule matched.
- QR-06
Retired setting read as live
A superseded configuration is worked as current.
Stage proposes
The hunk, its provenance and the flags
03 · Tool / write
2 modes
- QR-02
Thin suggestion passed forward
A hunk moves on without the code-owner read.
- QR-05
Hunk bound to the wrong change
The record is filed against another commit.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- QR-01
Committed, provenance detached
The commit stands but the suggestion under it does not.
Stage returns
The code the engineer commits and then ships
05 · Change / Version
1 mode
- QR-07
Silent filter drift
A setting changes while the stored record keeps the old one.
Stage tracks
Model, prompt, filter settings and licence rules
- Sev-1 · a commit with no provenance behind it
- Sev-2 · a flagged hunk reaches the product
- Sev-3 · signals degrade, suggestion withheld
Affected slices
Unfamiliar APIs absorb the amendments
A repository-level provenance figure can read clean while suggestions against unfamiliar APIs carry most of the amendments. Nestack reports the amendment rate by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Unfamiliar third-party APIs | 14.1% | 3.7× | Review | |
| Cryptography and auth code | 10.0% | 2.6× | Review | |
| Legacy modules without tests | 6.3% | 1.7× | Watch | |
| Routine application code | 2.9% | 0.8× | Normal |
Bar: amendment-rate lift vs. routine-application baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What a signed commit conceals
A cycle ends when the copied hunk nobody can source is a standing case. That suite is what the next suggestion accepted is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Amendment rate rises on unfamiliar third-party APIs.
- 02
Diagnose
The function that arrived complete, from somewhere, under a human name is worked backwards until one source is left standing.
- 03
Improve
The change ships numbered, and the commits that forced it ride with it.
- 04
Verify
One provenance case still failing is enough to hold the release back.
- 05
Learn
It is kept for good, and the suggestion rules are amended in the same commit.
Learn → Detect
The return edge. The next suggestion is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, suggestion workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Code-review workflow and automation-boundary scope.Week 1
- 02Editor, forge and scanner assessment.Week 1, Week 2
- 03Licence-rule mapping and filter-configuration capture.Week 1, Week 2
- 04Suggestion-record capture.Week 2
- 05Provenance and hunk binding.Week 2, Week 3
- 06Resemblance scoring and review routing.Week 3
- 07Engineer commit workflow.Week 3, Week 4
- 08Editor and forge integration.Week 5
- 09Provenance and review cases.Week 4, Week 5
- 10Guardrails and suggestion controls.Week 4
- 11Commit-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne repository, one team | ProductionProduction engineering workflow | AdvancedMultiple repositories / teams |
|---|---|---|---|
| Introduced at Pilot | |||
| Suggestions to your licence rules | ✓ | ✓ | ✓ |
| Named engineer commit | ✓ | ✓ | ✓ |
| Repository-provenance baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by suggestion class | — | ✓ | ✓ |
| Code-owner review workflow in your forge | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Editor-and-forge integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-licence rule sets | — | — | ✓ |
| Multi-stage code-owner approvals | — | — | ✓ |
| Large monorepos | — | — | ✓ |
| Multi-repository suggestion controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, repository volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your live repositories and the licence rules each is held to
→Provenance capture and suggestion-record versioning
Week 102Representative branches, diffs and review history
→Suggestion binding, licence rules and the provenance baseline
Week 203Your release calendar and the engineers it names
→Licence-rule mapping, filter capture and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Editor, forge and scanner assessment, then integration setup
Week 205Commits you would not want traced
→Source cases and the failure-mode round
Week 406What no suggestion may carry
→Resemblance scoring, review routing, guardrails and release controls
Week 307A named engineer who commits the change
→Release to the named engineer, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
These bands are counted, not spaced for looks; the fifth week carries two because those two coincide.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Repository workflow discovery, licence-rule mapping and the automation boundary
W2Editor and forge integration and the provenance baseline
W3Suggestion workflow, confidence logic and commit controls
W4Evaluation suite, source cases and failure-mode testing
W5Forge integration, pilot repositories and targeted corrections
W6One release cycle run under the code owner, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for, and week five is shared by design.
- At the end of W6
- When the commit record validates, Agent Care takes the agent on.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a code-generation agent around the provenance your last commit never recorded.
Show us one repository and the last release cut from it. What the company owns is the human expression in that code and the trade secret around it, and neither answers a question about which lines a machine wrote. Provenance is cheap at suggestion time and unrecoverable later.
- Typical delivery
- 4–6 weeks
- Deployment
- Your repositories
- Named engineer
- Per suggestion
- After launch
- Agent Care available
Nestack Agents · Code generation and review
AGT-ENG-01 · Agent Care available after launch