It really is better than I would expect it to be. But it requires a special treatment. Since the model is smaller it needs a smaller and simpler tasks. I use smarter model to decompose the task into primitive subtasks, write good description, submit to worker with qwen3.6, review completion and create new task to fix if required (20% of cases). This workflow works fine.
AI adoption is nowhere near the current capabilities of AI. I think its because of the lack of expertise at companies. Everyone has an opinion but in fact nobody knows how to work with AI. There is neither AI dedicated positions at companies nor AI transformation leaders on the market.
What companies can do in this case? Install Claude Code and wait how things change over time.
Not only SE career. Many careers which rely on static knowledge accumulated over years.
We have a senior guy who is like a walking cybersecurity library - knowing all the protocols, standards, vendors, threats. He is quite desperate atm. There is nothing he can add to what LLM already knows or can research in 30 seconds. He was building his profile for 30+ years.
I am on the side that AI will change everything. The reason why it has not yet is the lack of skills on the market - no AI transformation leaders. My strategy is to be closer to AI - number of nano startups with few people on board building smth AI related is exploding and they need expertise with AI engineering.
Love the approach. I am a big fun of hierarchical knowledge organization. I think that almost all current Claude abstractions to knowledge management are broken. It becomes visible when you start running many coders concurrently or need to create 1K+ skills fe: https://news.ycombinator.com/item?id=48407998
I started using brain -> workers approach for coding.
-- Brain is expensive smart model from claude subscription, Fable 5 when it was available, Opus now.
-- Worker is a local model (qwen3.6:46B), deployed in 36GB GPU, Opencode + Ollama.
Brain is responsible for analysis/design and task creation. Task should be made simple and clear so the worker can handle it. Worker does the coding. Brain validates and create a fix task when required. Atm fix to task ration is ~ 1:20.
If no available GPU at home - qwen3.6 is quite cheap on clouds.
Its rather experimental setup, out of curiosity, but it works better than I would expect it to. This allows me running 3 coding agents non stop for the 4-th day atm. Here I explain how I got there: https://news.ycombinator.com/item?id=48520757
It has to be coming from above. This is what McKinsey thinks and I think I agree. AI adoption required company transformation. This can't be done from the bottom - you will face severe resistance as this threatens people jobs/positions. Question is - how much you can extract from operational activity that can be automated reliably with AI. The more you can transform your company/operations in a way to maximize the AI automation - the bigger competitive advantage you get.
The problem companies are facing - is the lack of expertise. CEOs / Investors hear the rumors, AI can generate asymmetrical advantage - but no one knows HOW? And there are no AI transformation leaders on the market atm. So companies would try just to do something to be able to claim - we are on the road of AI adoption.
Using Claude Code for coding is a typical first move. Does it create a competitive advantage? It depends if company can ship features faster or cheaper. Otherwise it doesn't.
I have not heard of success stories about successful operational transformation based on AI. But I see a lot of nano-size startups popping up which build products on AI and embed AI into operations since the very early stage.
I use SDD since Feb for all my mid+ size projects. This works great for me from many angles:
- two levels of task decomposition - first is multiple steps in workflow, second is task decomposition into multiple subtasks - help to keep session context clean and focused, thus improving adherence, reducing cost
- multiple levels of model understanding verification - you verify first requirements step, then design step and only later code implementation. This helps to ensure that even if miss implementation happens it is rather tactical, on a code level, than strategical - on design level
- agent works as a helper to analyze what you need to build, interview you, builds spec which is better than just short prompt
- works nicely with coding agents orchestrated around task queue
Started with GSD and later implemented my own to fit better my typical size of features.
-- Stronger model from claude subscription is responsible for analysis/solution design/task creation.
-- Cheaper model (qwen3.6, local deployment on 36GB GPU with 250K context size) is responsible for task execution
Doing this for less then 24 hours. Fable can monitor and validate execution and create smaller tasks when something has to be adjusted after qwen execution. It is slower ofc, but this can work non stop without hitting the limits even when using Fable for orchestration/monitoring. Using this app for orchestration: https://github.com/sermakarevich/fleet
There are other reasons why the roles separation might be important. Anthropic changes limits for claude -p next Monday. But even current limits are not great - they might be ok for occasional research but they burn within 2 hour of coding in interactive mode and 20 minutes if we use multiple workers. There are rumors that tokens we got within subscription fee for $200 is equivalent to 8-12K in API cost.
Question is what companies will do when subscription fee will be not enough even for coding. Paying x40 does not look like an option.
My strong opinion is that every SE should go for agentic engineering these days: understand the limitations, how to shift them, and how to squeeze the maximum possible out of AI. The AI boom is seeing hundreds of billions, close to a trillion, in investments — with yesterday's announcement from China about investing $300B in a nationwide grid of data centers. Models are becoming smarter, and the gap where yesterday's models were unable to do something is closing fast.
I look at agentic engineering from the complexity perspective. Give an agent a simple task like inserting an assertion and you can be 100% sure it will do it correctly. Give it a complex task made of many subtasks in a complex codebase and it will fail. There is a boundary of complexity that a single call to an agent can handle. We can push this boundary if we decompose the task into many small ones and provide a sufficient description of what has to be done.
I found the Spec Driven Development approach works nicely for me, and I've been using it since Feb 2026 for all my mid+ size projects. I started with the GSD plugin, but it soon became too heavy, so I implemented my own lightweight SDD-based workflow for Claude. A friend of mine ported it to gemini-cli, and that version was added to Google's approved third-party frameworks for internal usage. The idea is to decompose feature implementation into multiple steps, task implementation into multiple subtasks, and be able to clear the context after every task/implementation.
When SDD was not enough, I started playing with scaling a single AI worker to multiple, and then got to an agent swarm. Built on top of a centralized Beads database, claude -p headless execution, a UI, a custom ask_user MCP, and Telegram integrations, fleet (the app name) lets me add many tasks in advance, control the number of workers executing them, and use any kind of coder/model. It works nicely with the SDDW implementation phase. It shines when you keep creating tasks, define dependencies between them, and give clear descriptions. For personal projects I can queue up 70 tasks for an overnight run, set the number of workers to 1 to not be blocked by usage limits, and let it roll.
Since Fable 5 appeared, I've been changing the way I work with fleet. Instead of adding tasks/descriptions/dependencies to fleet myself, I talk to Fable: specify the goal, ensure understanding, and let Fable 5 add tasks to fleet. Fable is expensive, but in this setup it doesn't code — it just investigates, designs, decomposes, and creates tasks. Workers use the cheaper Sonnet 4.6 model.
Reliability comes with task implementation decomposition into multiple steps, feature decomposition into many smaller and simpler subtasks, having better description, clean and focused context.