Try using spec kit. Codex 5 high for planning; Claude code sonnet 4.5 for implementation; codex 5 high for checking the implementation; back to Claude code for addressing feedback from codex; ask Claude code to create a PR; read the PR description to ensure it tracks your expectations.
There’s more you’ll get a feel for when you do all that. But it’s a place to start.
These guys are pursuing what they believe to be the biggest prize ever in the history of capitalism. Given that, viewing their decisions as a cynic, by default, seems like a rational place to start.
I don’t understand the use of MCP described in the post.
Claude code can access pretty much all those third party services in the shell, using curl or gh and so on. And in at least one case using MCP can cause trouble: the linear MCP server truncates long issues, in my experience, whereas curling the API does not.
> Overall, LLMs aren’t yet at the point where they can replace all engineers. But I don’t doubt they will be soon enough.
All engineers? This doesn't match my hands-on experience at all.
If you give a chainsaw to everyone, it doesn't make everyone a lumberjack. And a chainsaw itself certainly isn't a lumberjack.
If you give Claude Code or the like to everyone, it's doesn't make everyone a highly skilled software engineer. And Claude code itself isn't a highly skilled software engineer.
I've come around to this view. When I first began using these things for building software (the moment ChatGPT dropped), I was immediately skeptical of the view that these things are merely glorified autocomplete. They felt so different than that. These computers would do what I _meant_, not what I _said_. That was a first and very unlike any autocomplete I'd ever seen.
Now, with experience using them to build software and feeling how they are improving, I believe they are nothing more or less than fantastically good auto complete. So good that it was previously unimaginable outside of science fiction.
Why autocomplete and not highly skilled software engineer? They have no taste. And, at best, they only pretend to know the big picture, sometimes.
They do generate lots of code, of course. And you need something / someone that you can trust to review all that code. And THAT thing needs to have good taste and to know the big picture, so that it can reliably make good judgement calls.
LLMs can't. So, using LLMs to write loads of code just shifts the bottleneck from writing code to reviewing code. Moreover, LLMs and their trajectory of improvements do not, to this experienced software engineer, feel like they are kind of solution and kind of improvements needed to get to an automated code review system so reliable that a company would bet its life on it.
Are we going to need fewer software engineers per line of code written? Yes. Are lines of code going to go way up? Yes. Is the need for human code review going to go way up? Yes, until something other than mere LLM improvements arrive.
Even if you assume 100% of code is written by LLMs, all engineers aren't going to be replaced by LLMs.
I would emphasize, though, that getting clearly defined input _that remains stable_ is hard. Often something is discovered during implementation of a task that informs changes in other task definitions. A parallel system has to deal with this or the results of the parallel tasks diverge.
Based on experience of someone in my family, I ask: are you and your doctor sure that the mood stabilizers themselves aren’t making that hard?