All on my own, I hand-craft pretty good code, and I do it pretty fast. But one person is finite, and the amount of software to write is large.
If you add a second, skilled programmer, just having two people communicating imperfectly drops quality to 90% of the base.
If I add an LLM instead, it drops to maybe 80% of my base quality. But it's still not bad. I'm reading the diffs. There are tests and fancy property tests and even more documentation explaining constraints that Claude would otherwise miss.
So the question is if I can get 2x the features at 80% of the quality, how does that 80% compare to what the engineering problem requires?
Yes, as an American, I could point out that the side of US politics represented by Biden, Obama and Clinton is very real. It's internationalist, cooperative, and reliably so. Clinton was, in some ways, more willing to intervene in Eastern European crises than the EU was. And Biden came in early and aggressively to support Ukraine (though the EU eventually got there, and we can't decide who's side we're actually on, now).
But the problem is, internationalist Democrats are not the whole story of the US. There's another faction, one which our allies used to be able to work with. But that half of our nation's politics has been on a long, ugly moral slide. We are imposing ridiculous and destructive tariffs based on the personal grievances of one man. But a duly-elected Congress absolutely refuses to stop him. We are still covering up massive amounts of information about pedophiles in positions of power, but Congress hasn't done more than hold a vote and refuse to follow up. And we now have masked Federal police just murdering people in our streets for peacefully exercising their 1st and 2nd amendment rights, but a significant minority of voters are still cheering it on. If the moral trajectory sinks much lower, I'm not sure there would be any sins left to commit except public devil worship.
So no, you really can't trust the United States. Not because nobody here understands honor, alliances, or even practical business. But because that's not the whole story of the United States right now. We can't even get the Epstein files released. Which, admittedly doesn't affect you much. But it's clear sign of who we're becoming, and what a critical mass of our voters will ultimately accept.
If there's a human in then loop, actually reading the plans and generated code, then it's possible to have 90% of me code generated by an LLM and maintain reasonable quality.
Yes. Also, it's a fairly common trope that if you want to pilot a mech suit, you need to be someone like Tony Stark. He's a tinkerer and an expert. What he does is not a commodity. And when he loses his suit and access to his money? His big plot arc is that he is Iron Man. He built it in a cave out of a box of scraps, etc.
There are other fictional variants: the giant mech with the enormous support team, or Heinlein's "mobile infantry." And virtually every variantion on the Heinlein trope has a scene of drop commandos doing extensive pre-drop checks on their armor.
The actual reality is it isn't too had for a competent engineer to pair with Claude Code, if they're willing to read the diffs. But if you try to increase the ratio of agents to humans, dealing with their current limitations quickly starts to feel like you need to be Tony Stark.
Funny, because I was thinking of Evangelion's predecessor, Gunbuster, in which cadets are shown undergoing grueling physical training both in and out of their mechs to prepare for space combat.
There are some interesting possibilities for LLMs in math, especially in terms of generating machine-checked proofs using languages like Lean. But this is a supplement to the actual result, where the LLM would actually be adding a more rigorous version of a human's argument with all the boring steps included.
In a few cases, I see Terrance Tao has pointed out examples LLMs actually finding proofs of open problems unassisted. Not necessarily problems anyone cared deeply about. But there's still the fact that if the proof holds, then it's valid no matter who or what came up with it.
Yeah, I agree, the time zones are killer, and this can't be ignored. I work at a company spread over most of the world, with SMEs coming and going as the globe spins.
Back-and-forth iteration and consultation is a genuinely hard problem. Certain kinds of feedback cycles have a minimum latency of "overnight". Which means we need to invest heavily in good communication.
But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.
A lot of the international teams I've seen pull this off are ones where an Eastern European or Indian team is just another permanent part of the company, with broad-based professional expertise. Contractors on any continent are a whole different story.
So I think what a lot of people try to blame on Indian management culture (or whatever) really is just a case of "we hired contractors in a different time zone." I mean, there are always cultural issues—Linus Torvalds came from a famously direct management culture, and many US managers tend to present criticism as a not-so-subtle "hint" in between two compliments—but professionals of intelligence and goodwill will figure all that out eventually.
> But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.
Very common pattern you see in literature about military strategy, actually. The answer is delegation, heavy use of NCOs, and in general explaining the plan all the way down to the individual soldier. Under the western school it all falls under "initiative".
Notably, a lot of non-western militaries are terrible at it, and a number of military failings in africa, the middle east, and the soviet union (*cough*russia*cough*) are viewed as failures in flexibility with very low initiative, as well as lacking/unskilled NCO corps.
Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.
> Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.
The most successful engagements I've had with contracting firms have been when we've shelled out for a team manager and a software architect (in addition to the number of straight developers we want).
The software architect builds a solid understanding of our solution space, and from then on helps translate requirements into terms their engineers are familiar with, and provides code reviews to ensure their contributions are in line with the project goals. The team manager knows how to handle the day-to-day reporting, making sure everyone is on task, escalates blockers over the fence to our engineers and managment, etc.
Without those two roles from the contracting firm's side, I find that timezones and cultural mismatches (engineering culture, that is) pretty much erase the impact of the additional engineering headcount when adding contractors.
Explaining the plan to the individual soldier also works better when the individual soldier is expected to care at all about the overall goal. (Such as believing in the mission of defending the home country.) When the soldier only has extrinsic motivation such as money, top-down command and control and treating soldiers solely as equipment to be spent makes more "sense", in a terrible way.
IT also only works if the soldier is well trained in the things he can do. I can teach you to shoot a machine gun in a couple hours - and half of that time will be figuring out how to shoot and clean it myself (I've used hunting rifles and have enough mechanical knowledge that I think I can figure out the rest - but someone who knows that gun can likely find something I would not figure out). That will be enough for "spray and pray" which is a large part of what a machine gun is used for.
However in a real war you need to figure out what direction to point the gun, and need to know when to fire and when to not. I don't know how the army handles "we are advancing now so don't shoot", or "we are crawling along the ground so make sure you shoot high": someone else needs to give anyone I train those orders. The army trains their machine gun operators better so they can figure a lot of that out without being told.
> the time zones are killer, and this can't be ignored
100% agree, especially when there is minimal overlap during normal office hours. I was managing a dev team in India from the US and it was a real challenge. The company ended up moving team to the US, relocating most of my team. Despite all the people being the same, management became much easier.
Since then I've done US and EU, and EU and IN, and those have all worked fine because we had sufficient overlap during business hours.
He didn't need 8 hours, but zero didn't work. The us and india are about 12 hours apart (there are 4 times zones in the us, day light savings time, and india is offset half an hour, but it rounds out to 12 hours for discussion)
> If you needed 8 hour overlap you were micromanaging?
...ok. I didn't need 8 hours of overlap.
As I mentioned in my first comment, I've also now done US/EU and EU/IN. Both of which have only partial overlap and things have gone well.
With US West Coast and India, I was often doing meetings at 7AM and my devs were doing meetings at 9 or 10PM. That was challenging, irrespective of any cultural differences.
> Contractors on any continent are a whole different story.
Having spent the last ~7 years working for different startups before pivoting, my advice to any founder is this: do not hire overseas consultants. They're good, competent people, but you and your company do not have the tools or the culture to actualize them.
I think the actual problem here is that Opus 4.5 is actually pretty smart, and it is perfectly capable of explaining how PR disasters work and why that might be bad for Anthropic and Claude.
So Anthropic is describing a true fact about the situation, a fact that Claude could also figure out on its own.
So I read these sections as Anthropic basically being honest with Claude: "You know and we know that we can't ignore these things. But we want to model good behavior ourselves, and so we will tell you the truth: PR actually matters."
If Anthropic instead engaged in clear hypocrisy with Claude, would the model learn that it should lie about its motives?
As long as PR is a real thing in the world, I figure it's worth admitting it.
I think vibe coding isn't quite good enough for real products because I usually have 4 AI agents going non-stop. And I do read the code (I read so, so much code), and I give the AI plenty of feedback.
If you just want to build a little web app, or a couple of screens for your phone, you'll probably be fine. (Unless there's money or personal data involved.) It's empowering! Have fun.
But if you're trying to build something that has a whole bunch of moving parts and which isn't allowed to be a trash fire? Someone needs to be paying attention.
I have a version of this without the GUI, but with shared mounts and user ID mapping. It uses systemd-nspawn, and it's great.
In retrospect, agent permission models are unbelievably silly. Just give the poor agents their own user accounts, credentials, and branch protection, like you would for a short-term consultant.
The other reason to sandbox is to reduce damage if another NPM supply chain attack drops. User accounts should solve the problem, but they are just too coarse grained and fiddly especially when you have path hierarchies. I'd hate to have another dependency on systemd, hence runc only.
If you add a second, skilled programmer, just having two people communicating imperfectly drops quality to 90% of the base.
If I add an LLM instead, it drops to maybe 80% of my base quality. But it's still not bad. I'm reading the diffs. There are tests and fancy property tests and even more documentation explaining constraints that Claude would otherwise miss.
So the question is if I can get 2x the features at 80% of the quality, how does that 80% compare to what the engineering problem requires?
reply