I've been on one to two of these plans for eight months or so. There used to be a lot of issues with CC's terminal but at least in iterm2 they have largely been sorted.
I find that my orchestrating agent still needs to be fast to properly coordinate a fleet of slower models.
During post-training of opus 5, the last few days, opus was a real wreck. I had to swap in gpt 5.6 sol for my orchestrator and enable fast mode (1.5x speed) in order for it to keep up with work and communications from a handful of mostly 5.6 sol agents.
Also because interacting with a slow orchestrator is no fun, even when plenty of work is getting done in parallel in the background.
I used to read him in my dad's PC Magazine subscription. I had some ~falling out over what my teenage self perceived as backwards take on mp3s and their proliferation. Perhaps one one of my earliest experiences with "kill your heroes" concept.
Glad for all of his contributions, I did enjoy reading his work.
It is ~a meme on subreddits that developers struggling to get good results out of any given model is a "skills issue."
But I think your comment drives at some authentic take on this. Skill with AI is not only crafting iterative prompts the agent will understand, but also very high domain-specific knowledge of what the prompts explore.
One without the other can result in frustration or worse.
A naive hope is: you see that the LLM is so good at coding that all you need to do is supply a "yes/no" on what you want.
Turns out that understanding the technical domain is important to getting good results, even if the LLM is more capable at producing output. -- It's still a case of "garbage in, garbage out".
I think for many newbies, they see the LLM is so good at programming and so figure they don't need to learn anything. Apparently not so.
It is a skill issue. Such developers have to take a problem, isolate it and explain it to someone/something else with enough context to be able to work with it.
It is perplexing how many developers lack this basic skill, some of them borderline lack theory of mind and are incapable to understand that other people can't see the unspoken part in their heads.
It has been a good long while, but in my undergrad the engineering dept did not put a lot of emphasis on being a well rounded individual. It was more about passing physics and getting through all of the math.
One of my first jobs out of undergrad was technical writing on EDA tools for Mentor Graphics Calibre product. For many years, I did not appreciate that experience--it seemed orthogonal to what I'd gone to school.
Once I did become a professional SWE, something that took me too long to realize was that writing documentation and tutorials for people and looking after the quality of onboarding materials was almost never rewarded.
I came to see it more of a liability with ~all emphasis being on human code gen.
I listened to an interview with Steve Yegge earlier this year, one of his concerns was that many people just don't type very fast or read very quickly. IIRC, he expressed concern this would continue to be a big barrier to successful use of AI.
I previously commented on annotation for coding agents that an important skill was knowing the beat of a conversation.
I think that extends into critical reading. For example, it is not that unusual for a Washington Post article to put some ~explosive detail deep in the article--this is called "burying the lede."
I see this regularly reading AI output. That is: the AI will lead with the strongest claim it can state cleanly, but not the most explosive implication.
With Claude Code and Codex, you're looking essentially neverending walls of text dense with technical information.
So now you have to have high domain expertise, a good understanding of written communication, a sense for the beat of a conversation (which assists in identifying understatements or overstatements), and the ability to dense text outputs quickly and then highlight critical statements for further exploration.
I'd almost describe part of this work as that of a skilled interviewer.
I wonder how much this overlaps with the seeming inability of so many developers to ask good questions. They want to jump right into screen sharing and talking about the issue. They cannot sit down and summarize the problem accurately and describe the things they have tried already. It's always "let's hop on a call real quick and walk through it". Just tell me what the damn problem is!
This goes straight to the compiler and whether that precludes original craft. But I think it would be more relevant to discuss the use of open source packages.
Because I absolutely feel I made entire SaaS products, cool ones, by hand and they sat on a multitude of packages and infra I but glued together.
For frontend, I tailored templates, and instead put energy and time into making modern frontend toolchains and Django backends work together. This was satisfying to understand and build.
Being at ease with the minute details of Django or latest flags of esbuild felt like knowing the various modes of my Dewalt or Dewalt-colored power tools.
Building with AI is not a passive activity, and doing so well and efficiently, there is a ton to master and it evolved a great deal in the past six months.
So leveraging the tools using custom skills, custom CLIs, etc this is very important and very valuable thing to do. I would classify it as a serious contemporary computer science skill that should be taught in addition to the fundamentals.
Presume now, you're making and leveraging all of the modern bells and whistles of Claude Code and Codex. That is, you're reading the release notes and you have personal tooling so you can switch between them easily.
You can build incredible things with sustainable release workflows and reasonable security and possibly more than what a solo dev's "production quality" of yore.
I know this because I had Fable look at an entirely "hand crafted" SaaS I built over two years and it found about a page of bullets just in p0-p1 that I had not caught in my artisanal best effort. They were real issues, maybe unlikely but still things that I would have fixed if I had known.
But what can not be replaced is *taste*.
You can build all day and night and if it ain't good people won't use it. If you can't describe it in a way that makes sense to people they won't care.
If you build something people don't want you've not really made anything more than we did before we had AI as a tool.
I do think it can still achieve the same level of satisfaction if it is built well. Because it actually does take a lot of skill and knowledge to make something well using agentic programming. This is regardless of whether people want it.
In the "old west" if a horse was spooked and ran a person over, liability for the horse's owner varied but was similar to how this might be handled.
Consider this Supreme Court case, Brown v. Collins. [0]
A pair of horses were spooked by a nearby train engine, causing the animals to damage a stone post.
The driver of the grain-loaded wagon was not found to be at fault because he was "not guilty of any malice or unreasonable unskilfulness or negligence." And that the horses "did damage there against the will, intent and desire of the defendant."
If you read OpenAI's statement, in the Actions Being Taken section:
1. "As part of the investigation, we are implementing strict controls in infrastructure configuration at the cost of research velocity while the vulnerabilities are patched."
Which I think implies that as a result of this incident, OpenAI has instituted controls beyond ~"reasonable skillfulness" such that it might even impede their business (and from a certain point of view impede the progress of the people governed by the laws which might hold the company accountable.)
I'm not taking a position on the merit of the above but I can understand the line of thinking.
We're also at the point where you can roll out context to your entire organisation. I created an app for our m365 Cowork and deployed it to everyone who develops software. It does a couple of things, but it main knows our compliance policies and can guide developers through writing the documentation needed for NIS2 compliance. It also guardrails against non-approved packages, and helps developers find alternatives, or if none can be reasonably found, how to get a new package/dependency approved (or rejected).
A few months back this would be something every developer kind of did on their own. Maybe they shared skills, we certainly encouraged it and tried to do all the change management things, but nobody really had the same versions of the skills. Which was horrible in the deployment pipelines, something like the compliance documentation often had to go back and forth several times before it could be approved. Now it's just there, for everyone.
In a year or two, I expect a lot of these things to have become even more standardized. So that we don't even really have to build our own apps, but can simply use the ones in the catalog with minimal configuration (and that config will likely only be necessary because I'm from a tiny country that nobody will maintain standards for).
Yes. I worked on two large monorepos, about one quarter per project. Maybe 80+ devs on first, maybe 40+ on second. Both were not sure how to describe this but ultra-high-velocity agentic driven development efforts.
On the first, there were ~no shared skills. There were some requirements set up but they were not minded properly and became stale / ate context for little gain. The hardest hit was in E2E tests which would flake and create long running, too-often failing CI. People would disable them, because they were not reliable and velocity was so high, no one was happy w them.
I maintained my own set of skills and CLIs to back them. I'd share them if they came up but it was like the old days of manage your own stuff. Not much credit for building and sharing devex tooling to the team.
But then on the second one we were in better shape--we had vendoring set up to distro skills automatically.
Before the project was well underway, I put time into understanding how all of our tests aught to be written. Finding the forbidden things, etc, getting review from our best test folks and ultimately landed on a `/test` that routed across all possible test types.
Like night and day. Instead of finding out while trying to get a release out the door that some corner of the project had a handful of flakes, tests were written the right way from the start.
Like, it was beautiful. And I don't think devs noted difference while building. Only that there was an absence of BS in CI.
Hard to quantify the lack of pain, but it was big!
This made me chuckle because it's so true. So much detailed steering and finagling in the past, now I point the agent to a bunch of information sources, skills, similar repositories that might hold useful input and tell it very roughly what I need and off it goes, I'll grab coffee.
Look here and here and here are some tools, and /skill /skill [repo of folder paths etc] and here is what needs to happen: [stuff].
---
Restate this request in your own words and enrich it as appropriate handling any gaps.
?
It is an ultra-lite way to plan, I suppose.
I like the format because:
- I still get to put all my thinking into the request but then easily override the instruction
- It is interesting to see my casual typo-riddled blast professionalized and improved upon.
- Sometimes it surfaces useful questions that can save some time up front.
I think the models are doing this anyway, but I find the words "enrich" and "gap" are well understood by models and they demonstrate it in the response to the above pattern.
Anyhow, to get back to the point, there are still prompt-level tricks--but ultimately if repeated, should probably also be built into skills themselves!
reply