Community Catchup #9

The ninth community catchup landed on the same morning as Opus 4.8, so naturally the whole session became a live exploration of the new model, dynamic workflows, remote coding sessions, and what happens when agentic coding moves from "impressive demos" to everyday team practice.

Highlights

Adam built the slide deck with Opus 4.8, then spent the session trying it live. The headline: even when the shiny new workflow feature did not trigger exactly as expected, the model still one-shot a useful Skills Explorer app from a substantial prompt and a sibling repository of NZ data skills.

Opus 4.8 and the Workflow Shift

Adam focused on two launches: Opus 4.8 and dynamic workflows. The model arrived only weeks after 4.7, with better judgement, stronger task completion, dynamic effort control, and new ways for agents to fan work out to specialised sub-agents.

The group discussed fast mode, remote control from a phone, background sessions, and the idea that the human’s main job is increasingly to set objectives, review outputs, and step in when the agent needs judgement. Steve framed dynamic workflows as “plan mode on steroids” — not just planning, but dependency-aware orchestration.

Building the Skills Explorer Live

For the live demo, Adam asked Opus 4.8 to turn a starter Next.js app into a local TheColab Skills Explorer for the public NZ skills repository. The app needed to browse skills, group them by category, inspect docs, and run local commands against the sibling repo.

It did not initially use the dynamic workflow mode Adam expected, but it still ran for nearly an hour, consumed a large number of tokens, and produced a working app. The impressive part was not just that it built UI; it inspected the skills, classified categories, picked up brand colours, tested itself in the browser, and noticed accuracy issues such as a skill being incorrectly marked as requiring an API key.

Skills as the New SOPs

The Skills Explorer sparked a broader point: organisations should be turning their standards, processes, and domain knowledge into reusable skills. Brand rules, deployment processes, finance workflows, returns handling, reconciliation, security checks — all of these can become version-controlled instructions and tools that agents apply consistently.

When Matt asked how to keep multiple people and projects aligned without shackling every developer, the answer was not “write bigger prompts”. It was: define outcomes, document the standards that matter, make them testable, and let agents use those shared skills rather than every person improvising their own context.

Quality, Domain Knowledge, and the New Builder

Jason shared several examples of the new pace: a 2D-to-3D vectorising system for architects and quantity surveyors built in minutes, SIEM and log-ingestion problems that had taken weeks reduced to a short session, and performance issues solved quickly by the new model.

That led to a strong debate about who makes the best AI-era builder. Traditional coding knowledge still matters, especially around security, architecture, and maintainability. But several people argued that non-traditional builders with strong domain knowledge, clear objectives, and comfort letting the AI think are now producing better outcomes than developers who keep trying to rewrite everything into their old style.

Costs, Controls, and the Frontier Moving Target

The session ended with token economics and infrastructure. Adam’s live build showed the real cost of a large Opus 4.8 run, including cache reads and writes. Chris compared that with a 14-minute dynamic workflow audit. Others discussed when high-volume pipelines justify local GPUs, why legal firms are rolling their own systems, and whether large platform features will absorb many things startups are currently building.

The practical takeaway was grounded: use the frontier models when they buy you leverage, use smaller or local models when the task is narrow and cost-sensitive, and expect the line to keep moving every few weeks.