What you need to know
- Blacksmith says its new financing will expand its team and CI infrastructure.
- Scope a trial around a known workflow and its required build-and-test result.
- Compare waiting, execution, failures and maintenance effort across representative runs.
Funding for the validation layer
Blacksmith announced a $66 million Series C led by Sequoia Capital on October 21, with the company valued at $1 billion. It says the funding will support hiring and a larger compute footprint for its continuous integration platform. Blacksmith runs the automated builds and tests that teams use to check software changes.
The company is pitching its expansion around the demand created by AI-assisted development. Our view is that the useful question for an engineering leader is where a change waits before it can receive a dependable result. A larger flow of proposed code makes that question more urgent, but a new infrastructure provider still needs to improve a specific workflow.
Give the migration a defined scope
Blacksmith’s setup documentation describes connecting a GitHub organization and changing the runner selection in workflow jobs. It also describes dependency caching and Docker-layer reuse. The documented service is available to organizations rather than personal repositories. Those are concrete boundaries for a team considering an initial trial.
Start with a workflow whose inputs and required checks are understood. Record the environment, permissions and expected artifacts before moving it. Include the people who maintain the tests in the acceptance decision. A runner change can be small in a configuration file while still touching assumptions about the environment in which the application is checked.
Look at the slow runs as well as the typical one
The company’s analytics documentation describes repository-level views of job failures, duration, caches and costs. It also describes examining the steps inside the slowest jobs through a duration distribution. These views provide a way to investigate a delay; they do not establish that every workload will improve by the same amount.
A useful comparison could follow the same set of changes through the existing and proposed environments. Separate waiting for a runner from setup, test execution and retries. Examine an ordinary day and a busy period. Keep the failed runs in the comparison, because an apparently fast successful job tells little about the effort required to recover from an intermittent failure.
Keep the result meaningful to the release decision
Faster feedback helps when the team can act on it. A pilot could therefore measure the time from a ready change to a trustworthy build-and-test result, alongside compute use and maintenance effort. Agree beforehand which tests must run and what counts as a usable result. Preserve that standard while comparing environments.
An engineering review should also ask what happens when the preferred runner is unavailable and who handles a confusing failure. Keep an agreed route to the previous setup during the trial. The deployment decision becomes easier when the team can explain which delays were reduced, which still belong to the tests themselves and what work remains with people.
