Boris has some really good advice

Technological concepts & product/feature analysis

Shift in engineering workflow (agent era)

The speaker(s) describe how recent changes in software engineering workflows—especially around AI coding agents (e.g., Claude Code / “Claude” generally)—have made some developers feel “left behind.” Earlier workflows often emphasized manually customizing development environments and tooling.

The counter-argument is that engineering is still fun, but the “clever work” shifts toward:

• building better automation systems,
• designing agent-steering mechanisms.

Claude Code / agent-first development mindset

A core claim (attributed to Boris’s post) is that engineers who care about building exact tools for exact problems should be excited now. The point is not to replace engineers, but to enable engineers to:

• build the environment and tooling agents need,
• automate repetitive work,
• encode domain knowledge into artifacts that agents can use.

Automation as the “highest leverage” skill

The video argues that automation—historically via scripts, editor/Vim/Emacs automation, lint rules, and end-to-end tests—remains crucial and may become even more important:

• Automation improves developer experience (DX) and also speeds up agent operations.
• When agents scale (“an army of agents”), improvements to provisioning, preview environments, CI, and tests compound.

Preview environments still matter (now for agents too)

The speaker references prior pushback against preview environments (e.g., “nobody needs preview envs”). The rebuttal: in an agent-driven world, code runs in more places (cloud, background, other machines), so a strong preview/test loop is valuable.

Agents can:

• test previews,
• find bugs,
• generate evidence.

Example: custom PR file upload skill

A concrete workflow gap is described: agents couldn’t add video files to GitHub PRs because programmatic PR updates via CLI/API don’t replicate GitHub UI drag-and-drop behavior.

Solution

• build a custom “file upload skill,”
• upload via a service hosted on Cloudflare (named in subtitles as files.teslop.org),
• authenticate using a key available on the machine fleet,
• then post/attach the result within the PR.

Takeaway: agent tooling often needs “glue” integrations for gaps in existing CLIs/APIs.

CI acceleration with a dedicated CLI tool (sponsor: Blacksmith)

A sponsored segment addresses an agent+CI pain loop:

• Agents push PR changes, then wait for CI.
• CI fails with errors the agent didn’t reproduce locally.
• The agent workflow becomes slow/expensive due to repeated iterations.

Blacksmith’s pitch

• a CLI that allows agents to run CI directly,
• faster cycles and lower cost than standard PR/CI wait loops,
• better monitoring and analytics (utilization, error frequency, transient failures, and job-level attribution).

Turning one-off fixes into loops (automation of classes of work)

The video emphasizes “loops” / ongoing automation rather than one-off agent fixes:

• Don’t use agents ad hoc to patch issues each time (wastes tokens and risks missing cases).
• Use lint rules, CI steps, and routines to prevent entire categories of issues permanently.

The idea includes adding targeted automation that would have been too tedious if done fully manually.

Encoding domain knowledge as infrastructure (agent steering files)

A major theme: “domain knowledge” should be encoded into infrastructure-like artifacts, not only in humans’ heads:

• Claude MD / agent MD / review MD files
• skills
• memories
• structured guidance and guardrails (not just links to files)

Goal: even if a contributor lacks context, code submitted in a PR stays high quality.

Example of onboarding/quality control: “dumb questions rule”

A team practice:

• require new teammates to ask at least one “dumb question” daily,
• use beginner questions to identify where codebase/docs/guards fail,
• then improve agent steering docs and tooling to prevent regressions.

Agents enabling broader contributions (including non-engineers)

The video claims agents can reduce dependency on deep domain knowledge by navigating codebases and following encoded rules—potentially letting non-engineers contribute more effectively.

However, the speaker also argues non-engineers still won’t match engineers, because engineers understand what “good” systems look like and can improve them.

Do not leave all behavior to agents

Strong caution: don’t rely on agents to “magically intuit” everything forever. Teams should:

• build feedback loops,
• observe agent behavior,
• refine steering files and tooling based on observed failure modes,
• avoid overloading the system with lots of random skills/plugins before seeing what fails in real prompts.

Quality of steering files matters

If “agent MD”/“CloudMD” merely lists where things are, that’s insufficient. Steering should guide success behaviors and correct patterns—not only point to source locations.

Career argument: environment-building as senior/staff path

A concluding “hot take” suggests building these systems (environments, automation, guardrails, agent workflows) is a stronger path to senior/principal/staff impact than only writing more code.

With agents, even solo developers can build systems beyond what they can fully understand manually—making environment/system engineering high leverage.

---

Key “review / guide / tutorial” elements (explicitly described)

Practical agent workflow guidance

• Start with minimal touching of agent/steering files.
• Send initial prompts with minimal external context to see what fails.
• Encode missing knowledge into the appropriate Claude MD / agent MD / skills / review docs.
• Add guardrails that prevent repeated issue categories (lint/CI/routines).

Integration tutorial pattern (file upload to PRs)

• Identify a capability gap in agent tooling/CLIs.
• Implement a small service (Cloudflare-hosted) to provide the missing function.
• Provide an agent “skill” that uses that service and updates the PR accordingly.

CI workflow improvement (sponsor)

• Use Blacksmith CLI so agents can run CI directly, avoiding slow PR→CI→wait cycles and improving failure analytics.

---

Main speakers / sources (as referenced in the subtitles)

• Boris — original creator of Claude Code at Anthropic (discusses the post being referenced).
• Ryan — creator of SolidJS (joins chat; provides perspective on automations).
• The narrator / main speaker — the YouTube video host/commentator who supports Boris’s points and adds examples and opinions.
• Blacksmith (sponsor) — product being discussed for CI acceleration and analytics.