DEV Community: Sharon Y. Barr

Jest Unit Testing with AI Coding Agents: A 5-Gate Workflow

Sharon Y. Barr — Wed, 26 Aug 2026 06:48:42 +0000

Current AI coding agents can usually produce Jest syntax. They can write describe, test, expect, mocks, and fixtures quickly. That is no longer the difficult part.

The difficult part is getting a test that belongs in the repository and protects behavior that matters. An agent can write a perfectly valid test for the wrong boundary, mock away the risk, or report a passing command that proves much less than the reviewer assumes.

The prompt should therefore define a testing workflow, not merely request test code. The sequence I use is context, risk, one focused implementation, an adversarial challenge, and an evidence report.

Begin With the Repository, Not Jest

Before asking an agent to install Jest or create tests, ask it to map the existing test system. This matters because Jest may not be the right runner. A frontend workspace may already use Vitest. A Node project may use the built-in test runner. A monorepo may use different runners in different packages. When Jest is appropriate, its official configuration reference should be the source for version-specific options rather than a remembered setup recipe.

Use an inspection prompt that forbids edits:

Inspect this repository before making changes.

Determine:
- The package manager, language, and module system.
- Whether this is a monorepo and which workspace owns [target].
- The current test runner, libraries, commands, and CI setup.
- Whether Jest is installed and how it is configured.
- The nearest tests, fixtures, factories, and naming conventions.
- Any TypeScript, ESM, path alias, DOM, or transform requirements.

Report whether Jest is appropriate for [target], the smallest safe
path forward, and any decisions I need to make. Do not edit files.

This first response is a gate. If the agent recommends adding Jest to a workspace that already has an established runner, ask it to justify the operational cost. The correct result can be a decision not to use Jest.

Durable repository instructions also vary by agent. Codex reads layered AGENTS.md files. Claude Code supports CLAUDE.md and scoped rules. Cursor uses project rules under .cursor/rules. GitHub Copilot supports repository and path-specific instructions, with support depending on the environment. The prompts in this article are portable, but you still need to confirm what your chosen agent actually loads.

Ask for a Behavior and Risk Plan

"Write tests for this file" gives the agent a file boundary, not a quality standard. It can reward itself with coverage by testing getters, copying implementation branches, or asserting that mocks were called.

Ask for a plan before code:

Plan Jest tests for [feature, module, or change]. Do not write code yet.

Read the implementation, callers, nearby tests, and relevant product
or API documentation. For each proposed case, report:
- The observable behavior or contract.
- Why failure matters.
- The normal, boundary, and error cases.
- The correct test level: unit, integration, contract, or end-to-end.
- Dependencies that should remain real.
- Boundaries that should be mocked and why.
- Existing coverage that already protects the behavior.

Finish with the smallest useful test set and explain what it will not prove.

The test-level decision is important. A pure function is a natural unit-test target. A route that depends on middleware, serialization, or authentication may need HTTP-level evidence. A data-access change may need a real schema. Mocking every dependency can make a test fast while removing the behavior that carries the risk.

Consider a service that rejects expired discount codes. A weak generated test may mock the expiry validator and assert that the mock was called. It executes the service without testing the rule. A useful unit test supplies timestamps immediately before, at, and after the expiry boundary and asserts the observable result. A separate integration test may still be needed to prove that stored timestamps are serialized and interpreted correctly. The behavior determines the boundary, not the convenience of the mock.

Generate One Focused Test

Once the plan is approved, reduce the scope again. One behavior is easier to inspect than a repository-wide request that produces dozens of plausible cases.

Implement the approved Jest tests for [single behavior].

Constraints:
- Follow the nearest test file's structure and naming conventions.
- Assert exact observable outcomes when exact values are available.
- Include only meaningful normal, boundary, and failure cases.
- Reuse established fixtures without hiding key inputs.
- Do not update snapshots without showing and explaining the diff.
- Do not change production code without stopping to explain why.

Run the smallest relevant Jest command. If it passes and the working
tree is isolated and clean, temporarily alter the implementation
behavior to confirm the key assertion can fail. Revert the mutation,
rerun the focused test, and confirm the final diff contains no mutation
residue. Report all three results and the changed files.

The temporary mutation is a narrow trust check. If changing the intended behavior does not make the new test fail, the assertion probably does not protect the rule it claims to protect. This does not replace a mutation-testing system, but it catches a common weakness in generated tests.

Command execution is not uniform across agents. It depends on the product, permissions, sandbox, and environment. If the agent cannot run Jest, it has produced a proposed test change. It has not produced verified test evidence.

Review Tests as Generated Code

Passing tests still deserve a separate review pass. The same agent can do useful first-pass criticism when the prompt asks it to look for failure modes rather than approve its own work.

Review the new Jest tests as a skeptical maintainer.

Look for weak assertions, implementation mirroring, mocks that replace
the logic under test, missing awaits, shared state, nondeterminism,
opaque snapshots, duplicate cases, and tests that would still pass if
the intended behavior were broken.

For each finding, cite the test and explain the failure mode. Apply
clear fixes, rerun the focused suite, and report unresolved concerns.
Do not praise the tests or summarize unchanged files.

Review the production diff beside the test diff. A generated test can accurately encode current behavior even when the intended requirement is different. Important assertions should trace to a product rule, API contract, defect report, or observable user outcome. If that source is unclear, ask for clarification instead of generating another case.

Treat Coverage as a Map

Coverage identifies code that did not execute. It does not tell you whether an assertion is meaningful, whether a mock is realistic, or whether the chosen cases represent the product contract.

One hundred percent coverage is therefore not the goal. A suite can execute every line while relying on weak assertions and unrealistic mocks. Every test should earn its place by protecting meaningful behavior, documenting a stable contract, reproducing an important failure, or making a risky change easier to verify.

Ask the agent to classify weak tests:

Audit the Jest tests in [scope] for value, not test count.

Classify each weak or costly test as:
- Strengthen: the behavior matters, but the assertion is weak.
- Replace: the risk is real, but the test uses the wrong boundary.
- Delete: the test is duplicate, tautological, obsolete, or coupled to
  implementation without protecting an observable contract.
- Keep: the test provides clear evidence for meaningful behavior.

Explain the evidence for every recommendation. Do not delete tests
only to simplify maintenance or improve speed. Apply only approved
changes and report any behavior that lost protection.

A test that is inconvenient because it exposes a compatibility requirement is not low quality. A test that fails during harmless refactoring because it mirrors private implementation probably is. The agent should make that distinction explicit.

End With Evidence, Not Confidence

The final handoff should separate what ran from what remains an assumption.

Prepare the testing evidence for this change.

Report:
1. The behavior and risk the Jest tests address.
2. Test files added or changed.
3. Exact commands run and their results.
4. Key assertions and why they detect the intended failure.
5. Mocks used and which real contracts they exclude.
6. Coverage change, if measured, without treating it as proof.
7. Behavior that still needs integration, contract, end-to-end, or
   regression verification.
8. Tests considered but intentionally not added, and why.

Use only evidence from this task. Do not claim the change is safe or
ready to ship beyond what the executed checks establish.

Keep this report with the pull request or task. The next reviewer should not need to reconstruct the agent conversation to learn which commands ran or which risks remain.

AI coding agents make Jest implementation faster. The durable advantage comes from prompting them to inspect before editing, test behavior rather than structure, challenge their own assertions, and report the limits of their evidence.

Jest evidence also has a boundary. A passing unit test can verify selected JavaScript or TypeScript behavior under the supplied cases. It cannot prove that a release preserves behavior across services, data contracts, infrastructure, configuration, or operational dependencies. That wider risk needs the appropriate integration, contract, end-to-end, and regression evidence.

The syntax is cheap. The judgment about what deserves protection is not.

5 Checks to Catch Regressions in Agent-Generated Code

Sharon Y. Barr — Mon, 24 Aug 2026 20:08:26 +0000

Consider a coding agent asked to add a promotion type to a shared discount service. The task looks narrow. The agent changes one API endpoint, adds focused tests, and returns a clean diff.

Everything in the assigned task can be correct while the release still changes renewal pricing, invoice totals, account entitlements, or a reporting job that depends on the same service.

That is the core problem with reviewing agent-generated code only at the task boundary. The implementation is visible in the pull request. Its consequences can be distributed across the product.

A useful release review needs more than one passing signal. It needs evidence that moves from the narrow intent of the task to the wider behavior of the build the team plans to deploy, often called the release candidate.

A passing task is not the same as release confidence

Coding agents work from the context they receive: a prompt, repository instructions, selected files, tool output, and known tests. That context may not include every business flow that depends on the changed behavior.

The same boundary applies to conventional review tools:

A diff shows what changed in the repository.
A test suite shows whether encoded expectations passed.
Static analysis shows whether selected rules were violated.
A security scanner shows whether its checks found known classes of problems.

Each signal is valuable. None proves that all existing product behavior remained intact.

GitHub's responsible-use guidance for coding agents makes the human boundary explicit: generated output still requires review and verification. The practical question is what evidence a reviewer should require before approving a release.

The following five checks build a useful release record.

Move from task intent through behavioral comparison before making the release decision.

1. Define the intended behavior before reviewing the code

Start with the intended change, not the implementation the agent produced.

Write down the requested outcome, the important constraints, and the behavior that must remain unchanged. For the promotion example, the task might require a new promotion type while preserving existing promotion precedence, authorization, renewal rules, and rounding behavior.

A useful intent statement answers four questions:

What user or system outcome should change?
Which existing behavior must remain unchanged?
Which interfaces, data rules, or security boundaries apply?
Who owns decisions when the requirement is ambiguous?

This keeps a polished implementation from quietly redefining the task. It also gives reviewers a standard that does not depend on the agent's explanation of its own work.

Keep it concise. The goal is not a second specification. It is to make the expected change and protected boundaries explicit enough to verify.

2. Inspect the diff and the path that produced it

The final diff is necessary, but it is not the entire review surface.

When available, inspect the agent's work record: the prompt, repository instructions, files read, commands run, tests selected, tool approvals, and assumptions. This record does not establish correctness. It shows the boundary of what the agent considered.

For example, a correct change to the discount calculation may still deserve more review if the agent never inspected renewal code, invoice generation, or entitlement updates. Missing context is not proof of a defect. It is evidence about where uncertainty remains.

Review the code for the familiar failure modes as well:

Incorrect authorization or data access.
Incomplete error handling.
Unexpected schema or persistence changes.
Changes that exceed the requested scope.
Tests altered only to make a failure disappear.
Assumptions that conflict with product rules.

The right question is not merely, "Does this code look reasonable?" Ask, "What did the agent know, what did it change, and what relevant context did it not examine?"

3. Run reproducible checks, with people accountable for the result

Run reproducible controls: builds, type checks, linters, policy and security checks, dependency checks, and relevant unit, component, integration, and end-to-end tests.

Add focused tests for the acceptance criteria and important error paths. Then investigate every failure before changing the expected result.

This distinction matters. A failing test can indicate an intended product change, a stale assertion, an environment problem, or a real regression. An agent can help investigate the cause, but it should not silently rewrite the test until the status turns green.

Passing controls answer a bounded question: did the release candidate satisfy the checks that ran? They do not show whether every affected behavior had coverage.

Record what ran, what was skipped, and why. "All tests passed" is weak evidence when nobody can say which tests were relevant or whether a required environment was unavailable.

4. Map the change to affected business flows

Move from files and functions to product behavior.

A shared service can participate in customer, financial, administrative, and reporting flows that are implemented elsewhere. The impact boundary is therefore rarely identical to the changed-file boundary.

For the promotion change, an affected-flow map might include:

Creating a subscription with a promotion.
Renewing an existing subscription.
Combining account and campaign discounts.
Calculating invoice totals and taxes.
Applying entitlements after payment.
Exporting promotion data for reporting.

Use architecture documentation, product owners, service relationships, and domain expertise to build this map. It is not an automatic dependency graph that proves impact. It tells the team which established outcomes deserve evidence.

The map also exposes ownership gaps. If a change can affect billing but nobody reviewing the release owns billing behavior, the release process has found a coordination problem before customers do.

5. Compare candidate behavior with the production baseline

Tests start from scenarios the team anticipated and encoded. A baseline comparison starts from established behavior and asks what changed.

Compare controlled runs of relevant flows in the release candidate with a production baseline. The baseline can be captured production behavior or a controlled reference derived from it. Do not send state-changing test traffic to production. Classify differences instead of flattening them into one pass-or-fail result.

Some differences are expected because the task intentionally changes behavior. Others reveal an unintended effect. The reviewer needs enough evidence to distinguish the two and identify who confirmed each expected change.

This comparison is especially useful when the code change is local but the product effect is not. It can reveal that the new promotion works as requested while an existing renewal path now calculates a different total.

Baseline comparison also has limits. Production behavior can contain existing defects. Test data may not represent every customer state. Environments may differ. Record those constraints instead of presenting the comparison as certainty.

Keep the five signals separate

Teams often collapse several checks into one reassuring status. That removes the information needed for a decision.

A useful release record preserves each layer:

Evidence layer	Question it answers
Intent	What is supposed to change, and what must remain stable?
Agent work record	What did the agent inspect, assume, execute, and modify?
Reproducible controls	Which known rules and scenarios passed or failed?
Affected flows	Which existing product outcomes could depend on the change?
Behavioral comparison	What differs between the candidate and the current baseline?

No layer substitutes for another. A complete agent work record does not replace tests. A green suite does not replace impact analysis. A baseline difference does not explain whether the change was intended.

The final decision remains human and accountable

Bring the evidence together before approving the release:

Did the implementation satisfy the stated intent?
Are there unresolved review findings or assumptions?
Which checks ran, failed, passed, or were skipped?
Which business flows may be affected?
Which behaviors differ from the baseline?
Which differences are expected, and who confirmed them?
Which gaps remain unverified?

An agent can collect evidence, summarize findings, and investigate a failure. It should not turn incomplete context into automatic approval.

The engineering, QA, product, or release owner decides what ships. That owner should be visible in the release record, along with the evidence and remaining uncertainty behind the decision.

The goal is not to distrust generated code by default. It is to verify change at the level where the risk exists. A coding agent changes files. A release changes a product.

Originally published on Early: 5 Ways to Check Agent-Generated Code for Regressions.

AI Code Review Is Not Regression Review

Sharon Y. Barr — Sun, 23 Aug 2026 13:00:53 +0000

In Part 1, I argued that an agent completing its task does not make the resulting change ready to ship. The practical next question is how to review that release candidate before production.

Teams often treat the answer as a single review step, but code review and regression review protect against different failures. Code review asks whether the proposed change is correct. Regression review asks whether the working system remains correct after that change.

The two reviews can inspect some of the same evidence, but they begin from different reference points. That distinction matters because a correct change can still produce a broken release.

Code Review Starts With the Change

A code reviewer begins with the implementation.

Did the code satisfy the requirement? Is the logic correct? Does the change follow the architecture and security constraints? Did it introduce a defect, an unnecessary dependency, or an unsafe pattern?

An AI code reviewer can inspect the diff, nearby code, tests, repository instructions, and related symbols. A human reviewer can add product knowledge, architectural judgment, and experience that may not exist in the repository.

The better the available context, the broader and more useful that review can become. A strong reviewer may even identify a dependency outside the changed files.

But the review still starts with the change. Its natural question is whether the proposed implementation is correct.

Regression Review Starts With the Working System

Regression review begins from a different reference point: the production baseline.

What behavior already works? Which user journeys, components, integrations, data transitions, and permission rules could this release candidate affect? What evidence shows that those behaviors remain intact?

This changes the unit of analysis. The diff remains important, but it is no longer the boundary.

Execution controls bound the work. Release controls evaluate whether the resulting change should ship.

The distinction matters because a technically correct change can produce a bad release. The failure may sit in a component that did not change, a repository the reviewer did not open, or a business flow that no test represented.

One Correct Backend Change, One Broken Journey

Imagine asking a coding agent to add a 72-hour expiration rule to account invitations.

The agent updates the backend model and endpoint. It validates expired tokens, returns a defined response, adds targeted tests, and passes the repository checks. The implementation matches the assigned requirement.

The invitation journey, however, extends beyond that backend endpoint. An existing frontend accepts the invitation. Membership state becomes active. An audit event is written. A notification job retries failures.

The frontend was created before the expiration rule. It may send a token shape that the new validation rejects. The backend code can be correct while the complete invitation journey is now broken.

A sufficiently broad code review might discover that relationship. Regression review makes the relationship the starting point rather than a lucky extension of the diff review.

The changed code and the broken behavior can live in different components.

That is the practical difference. Code review evaluates the implementation against its requirement and technical context. Regression review evaluates the release candidate against the behavior the system must preserve.

Passing Checks Cannot Describe Missing Context

Tests matter. Static analysis matters. Security scans and code review matter. Each can provide strong evidence about a release candidate.

None of them automatically expands beyond the behavior and context it represents.

A green test result says that encoded behavior passed for a particular revision in a particular environment. It does not say that every dependent business flow was encoded. A clean code review says the reviewer found no blocking issue in the context available. It does not say the reviewer had every operational dependency or historical behavior.

The problem is not that the evidence is weak. The problem is turning a bounded result into a broader claim than it supports.

A release owner needs to know what ran, what passed, what did not run, and which affected behaviors remain uncertain. Revision-bound evidence prevents another common mistake: approving a release with results produced from a different commit, configuration, or environment.

Five Guardrails Connect the Task to the Release

Once code review and regression review are separated, a practical control stack becomes clearer.

Change contract. Write down the desired outcome, allowed scope, stable behavior, expected failure handling, and required evidence before consequential work begins.
Access limits. Bound which files, commands, tools, networks, credentials, and environments the agent may reach.
AI code review. When a code-aware reviewer is available, evaluate the implementation against the requirement and relevant repository context. Tie findings to the exact revision.
Regression review. Evaluate affected business flows and cross-component relationships against the production baseline. Make missing evidence visible.
Owner approval. Keep the release decision with a named person who understands the remaining uncertainty and owns the rollback plan.

These controls are connected, but they do different jobs.

The first two shape and bound the work. Code review evaluates what changed. Regression review evaluates what the release could disturb. Owner approval turns the evidence and remaining uncertainty into an accountable decision.

Regression Review Can Be Expressed in Business Terms

Developers using Codex, Claude Code, Cursor, or GitHub Copilot can inspect generated code directly or ask another qualified reviewer to do it.

Not every release owner can review source code. Managed app builders may expose or synchronize the source while serving users who do not have the technical ability to evaluate it.

Regression review remains useful because its questions can be expressed in business terms.

Which signup journey could stop working? Which role could gain or lose access? Which payment, notification, or data transition might change? Which integration depends on the previous response?

The person approving a release should be able to understand those consequences even when that person delegates the implementation review.

Four Questions Before Production

Before an AI-generated change reaches production, the release owner should be able to answer four questions:

Which exact release candidate was evaluated?
Which business flows and component relationships could be affected?
What evidence exists, and what remains unknown?
Who accepts the remaining uncertainty and owns the rollback?

An agent can operate inside strict permissions and still produce a release candidate with consequences beyond its assigned task. Execution controls determine what the agent may do. Code review evaluates what it changed. Regression review evaluates what the release could disturb across the wider system.

Code review asks whether the change is correct.

Regression review asks whether the system remains correct after the change.

Production needs both.

This article is adapted from Vibe Coding Guardrails for Production Teams in 2026 on the Early blog, which includes the complete five-layer framework and source list.

Vibe Coding Grew Up. Are We Ready to Ship What Agents Build?

Sharon Y. Barr — Wed, 12 Aug 2026 09:41:17 +0000

When the phrase "vibe coding" entered the software vocabulary in 2025, it described a surprisingly simple loop.

Describe the outcome. Let a model produce the code. Try it. Keep prompting until the result feels right.

The phrase was playful. The shift was not.

One year later, the model is no longer waiting in a chat window for the next instruction. Claude Code can navigate a repository, edit multiple files, run commands, test its work, and commit a change. The Codex app can take on long-running tasks, work in parallel, and hand a developer a diff to review.

The prompt now starts an execution loop.

That is a much bigger capability than prompt-driven code generation. It also exposes a harder question: what has to be true before anyone should trust the resulting change in production?

Three Modes That Look Similar but Are Not

The term vibe coding has become broad enough to hide three different ways of working.

Prompt-driven generation starts with a request and iterative feedback. The system produces code or a small application. Success often means the demonstrated flow works.

Agentic coding adds a repository, tools, and a longer task horizon. The system can plan, edit, run commands, test, inspect failures, and continue working.

Production engineering adds the controls and evidence needed for a team to own the release. It begins before the prompt and continues after the agent says the task is complete.

These modes can use the same model. What changes is the operating contract around it.

Vibe coding is an interaction style. Agentic coding is a system capability. Production engineering is an organizational responsibility.

Treating them as synonyms makes a successful agent run look like a release decision. It is not one.

The Tool Changed Category

The first generation of AI coding tools helped developers type. The current generation acts.

An agent can install a dependency, change an interface, update its callers, run the suite, inspect a failure, and try again. It can make a sequence of technical decisions and observe the consequences.

That execution loop is why the old distinction between AI-generated code and human-written code is becoming less useful. A single change may contain model output, human edits, generated tests, copied patterns, and a second agent's review.

The practical unit is not authorship. It is the change the team is considering releasing.

This matters because a change can be technically coherent and still be wrong for the product around it. The repository gives an agent a great deal of implementation context. It does not automatically contain every customer expectation, operational dependency, security boundary, or undocumented behavior that must remain stable.

The Bottleneck Moved

When implementation gets cheaper, more ideas become changes.

That is a real productivity gain. Every additional change still needs intent, context, review, security, validation, and ownership. Generating five plausible implementations does not create five times the capacity to understand their consequences.

In a June 2026 survey commissioned by GitLab and conducted by The Harris Poll, 85% of 1,528 developers and technology buyers agreed that AI had shifted the bottleneck from writing code to reviewing and validating it.

A survey records perception rather than delivery telemetry, so it is not proof of a universal effect. It does show that teams adopting these tools feel pressure moving into verification and governance.

The scarce resource is no longer only the ability to produce a candidate change. It is the ability to state what should happen, provide the context the agent cannot infer, and decide which evidence is strong enough to ship.

Working Is a Narrow Claim

A working result is valuable. It may mean the application loaded, the requested flow worked once, or the tests selected by the agent passed.

Production asks wider questions:

Does the implementation match the real product intent?
Does it follow architectural and security constraints that were absent from the prompt?
Does it integrate with private systems correctly?
What established behavior outside the changed files could be affected?
What was not tested or inspected?
Who owns the remaining uncertainty?

Claude Code and Codex reduce the effort required to implement and investigate. They do not collapse these questions into a green test run.

In 2025, the production gap looked like a limitation of generation quality. In 2026, capable agents show that the deeper gap is the delivery system around generation.

A Successful Task Can Still Produce a Bad Release

Consider an illustrative case.

A team asks an agent to replace authentication middleware in one service. The agent updates the interface, migrates the known callers, adds tests, and passes the repository checks. Against the assigned task, the result looks complete.

After release, an internal administration flow fails because it depends on an undocumented error response from the old middleware. The broken behavior sits outside the files and checks the agent used.

The agent completed the assigned task. The delivery system failed to describe the full behavior that had to remain stable.

This is the production boundary. Agent execution is judged against the task. A release must be judged against the product behavior and operational dependencies the change could affect.

Expertise Became More Valuable

The more capable the agent becomes, the more valuable clear judgment becomes.

Anthropic's research on agentic coding found a recurring division of labor: people made most planning decisions about what to do, while Claude made more execution decisions about how to do it. Domain expertise helped people give better direction and recover when the agent misunderstood the task.

The agent can remove a great deal of implementation friction. That increases the leverage of the person who understands the problem, the system, and the consequences.

The valuable developer is not merely the fastest typist. It is the person who can turn an ambiguous request into a precise task, recognize when a plausible implementation violates an important constraint, and ask for evidence that tests the real risk.

Five Responsibilities That Become More Important

Engineering leaders should stop treating agent supervision as only an upgraded code-review problem. It is a release-accountability problem.

Five responsibilities become more important as agents become more capable:

Specify intent. Define the behavior, boundaries, and acceptance criteria before implementation begins.
Curate context. Maintain repository instructions, architectural decisions, product constraints, and operating knowledge the agent needs.
Bound execution. Decide which files, tools, networks, credentials, and environments the agent may access.
Demand evidence. Require the relevant builds, tests, reviews, and inspections, including a clear record of what did not run.
Own the outcome. Keep the release decision with an accountable person who understands the remaining uncertainty.

This is not a retreat from automation. It is how automation becomes usable for consequential work.

Agent adoption should not be measured only by completed tasks or accepted code. The stronger measure is whether faster execution is matched by clearer intent, independent evidence, and explicit ownership.

Vibe coding grew up because the tools grew up.

Production got harder for the same reason.

The prompt can start the implementation. It cannot own what ships.

This article is adapted from Vibe Coding Grew Up. Production Got Harder. on the Early blog, which includes the full source list and Part 2 of the series.