I feel a bit wacky even saying this, but I just started re-reading Team Topologies last week because it's starting to feel like the whole orchestration pattern only works reliably when roles and structure are clearly defined.
I love this insight, and it generalizes. Just swapping out humans with AIs won't just fix everything, because many of the biggest problems are structural or emergent.
I'm hopeful that we can use AI models to pressure test better options of social organization etc.
Mainly because Martin Fowler is part of their C suite
I agree that it's marketing material, but that doesn't instantly make it garbage. I've been reading their quarterly Thoughtworks Radar for a while now and it's clearly put together by people who understand the industry.
Polymarket is banned in most first world countries (including the US). It's not particularly tough to get around with a VPN, but they do enough that they have plausible deniability. I'm sure if the US wanted to they could go after them and prove that they're still letting US customer sign up, but it's not the open and shut case you're making it out to be.
Polymarket US is starting to roll out in the US and other countries where Polymarket cannot operate, but that's a separate company and they do abide by KYC laws similar to Kalshi.
> I find LLMs so much more exhausting than manual coding
I do as well, so totally know what you're talking about. There's part of me that thinks it will become less exhausting with time and practice.
In high school and college I worked at this Italian place that did dine in, togo, and delivery orders. I got hired as a delivery driver and loved it. A couple years in there was a spell where they had really high turnover so the owners asked me to be a waiter for a little while. The first couple months I found the small talk and the need to always be "on" absolutely exhausting, but overtime I found my routine and it became less exhausting. I definitely loved being a delivery driver far more, but eventually I did hit a point where I didn't feel completely drained after every shift of waiting tables.
I can't help but think coding with LLMs will follow a similar pattern. I don't think I'll ever like it more than writing the code myself, but I have to believe at some point I'll have done it enough that it doesn't feel completely draining.
I think it's because traditionally, software engineering was a field where you built your own primitives, then composited those, etc... so that the entire flow of data was something that you had a mental model for, and when there was a bug, you simply sat down and fixed the bug.
With the rise of open source, there started to be more black-box compositing, you grabbed some big libraries like Django or NumPy and honestly just hoped there weren't any bugs, but if there were, you could plausibly step through the debugger and figure out what was going wrong and file a bug report.
Now, the LLMs are generating so many orders of magnitude more code than any human could ever have the chance to debug, you're basically just firing this stuff out like a firehose on a house fire, giving it as much control as you can muster but really just trusting the raw power of the thing to get the job done. And, bafflingly, it works pretty well, except in those cases where it doesn't, so you can't stop using the tool but you can't really ever get comfortable with it either.
> I think it's because traditionally, software engineering was a field where you built your own primitives, then composited those, etc... so that the entire flow of data was something that you had a mental model for
Not just that, but the fact that with programming languages you can have the utmost precision to describe _how_ the problem needs to be solved _and_ you can have some degree of certainty that your directions (code) will be followed accurately.
It’s maddening to go from that to using natural language which is interpreted by a non-deterministic entity. And then having to endlessly iterate on the results with some variation of “no, do it better” or, even worse, some clever “pattern” of directing multiple agents to check each other’s work, which you’ll have to check as well eventually.
> bafflingly, it works pretty well, except in those cases where it doesn't
so as a human, you would make the judgement that the cases where it works well enough is more than make up for the mistakes. Comfort is a mental state, and can be easily defeated by separating your own identity and ego with the output you create.
I mean, you could make that judgment in some cases, but clearly not all. If you use AI to ship 20 additional features but accidentally delete your production database you definitely have not come out ahead.
I think what will eventually help is something I call AI-discipline. LLMs are a tool, not more, no less. Just like we now recognize unbridled use of mobile phones to be a mental health issue, causing some to strictly limit their use, I think we will eventually recognize that the best use of LLMs is found by being judicious and intentional.
When I first started dabbling in the use of LLMs for coding, I almost went overboard trying to build all kinds of tools to maximize their use: parallel autonomous worktree-based agents, secure sandboxing for agents to do as they like, etc.
I now find it much more effective to use LLMs in a target and minimalist manner. I still architecturally important and tricky code by hand, using LLMs to do several review passes. When I do write code with LLMs, I almost never allow them to do it without me in the loop, approving every single edit. I limit the number of simultaneous sessions I manage to at most 3 or 4. Sometimes, I take a break of a few days from using LLMs (and ofter from writing any code at all), and just think and update the specs of the project(s) I'm working on at a high level, to ensure I not doing busy-work in the wrong direction.
I don't think I'm missing anything by this approach. If anything, I think I am more productive.
Thanks for the story. I also spent time as a delivery driver at an italian restaurant. It was a blast in the sense that i look back at that slice of life with pride and becoming. Never got the chance to be a waiter, but definitely they were characters and worked hard for their money. Also the cooking staff. What a hoot.
I'm an EM as well and I've been telling my teams for a while now that I think they really only need to start worrying once our backlog starts going down instead of up. Generally, I still agree with that (and your) sentiment when you look at the long term, but in the short term, I think all of the following arguments can be made in favor of layoffs:
- AI tools are expensive so until the increased productivity translates to increased revenue we need to make room in the budget
- We expect the bottlenecks in our org to move from writing code to something else (PM or design or something) so we're cutting SWEs in anticipation of needing to move that budget elsewhere.
- We anticipate the skillsets needed by developers in the AI world to be fundamentally different from what they are now that it's cheaper to just lay people off, run as lean as possible, and rehire people with the skills we want in a year or two than it is to try and retrain.
I don't necessarily agree with those arguments (especially the last one), but I think they're somewhat valid arguments
I see similar arguments and I don't agree as well, here is why:
> rehire people with the skills we want in a year or two than it is to try and retrain.
before that future comes your company might become obsolete already, because you have lost your market share to new entrants
> We expect the bottlenecks in our org to move from writing code to something else
I would love to tell them, hey lets leverage current momentum and build, when those times come, we offer existing people with accumulated knowledge to retrain to a new type of work, if they think they're not good fit, they can leave, if they're willing, give them a chance, invest in people, make them feel safe and earn trust and loyalty from them
> AI tools are expensive so until the increased productivity translates to increased revenue we need to make room in the budget
1. Its not that expensive: 150$/seat/month -> 5 lunches? or maybe squeeze it from Sales personnel traveling with Business class?
2. By the time increased productivity is realized by others, company who resisted could be so far behind, that they won't be able to afford hiring engineers with those skillsets, if they think 150$ is expensive now, I am sure they will say "What??? 350k$ for this engineer?, no way, I will instead hire contractors"
Your last point I think is the crux for now, if you can get so much more value out of talent then the market will eventually price that into wages. I think the idea some have instead is that I can use cheap, unskilled people to get the same value as before, which is probably true for some aspects of the industry. My experience of that so far for boutique software is AI propels unskilled employees at light speed into dead ends, similar to how a junior would spend two weeks following ideas from stack overflow and being unable to execute on it.
However AI definitely is capable of lower end software tasks and really well trodden ground, especially when managed by a developer, so perhaps what we will see is a bigger gap in pay and talent not too different from the off-shore vs on-shore market comparisons.
The key for me though for me is that, if AI makes your employees 20% more valuable, that will either get priced into their wage or captured by the business, but it still doesn't replace the need for good talent (software engineer, agent handler, whatever it will get called).
I fully agree with everything you've said and think the Twitter one is a really good point that I haven't heard before.
That said, I think you've left out the impact of interest rates and the end of the Zero Interest Rate Policy (ZIRP) on this. So much of the "growth above all else", "revenue and user count matters more than profit" mindset companies had over the last 10 years was because ZIRP incentivizes them to invest in riskier assets. If safe investments pay 1% a year that's only a 10.4% return 10 years later. If safe investments pay 5% a year that's a 62.8% return 10 years later.
When rates are low, investors are more willing to focus on a company's potential because their money isn't making a lot while sitting in the bank. When rates went up (in addition to everything you said) investors all of a sudden wanted to see profit, not revenue or user base numbers which means a lot of these companies had to pivot their strategy fast. All the perks and crazy moonshot projects get cut and only things that are profitable or have a clear path to profitability are kept.
If you look back, that's exactly why we saw things like companies throwing crazy money at things like the metaverse and crypto and then practically over night pull the plug on them.
The charts below are the fed funds rate and the number of SWE jobs from Indeed, both from the fed and you can see how they align.
The creator has an estimated net worth of $50 million to $200 million prior to Open AI hiring him. If you listen to any interviews with him, doesn't really seem like the type of person who's driven by money and I get the impression that no matter what OpenAI is paying him, his life will remain pretty much unchanged (from a financial perspective at least).
He also still talks very fondly about Claude Code and openly admits it's better at a lot of things, but he thinks Codex fits his development workflow better.
I really, really don't think there's a conspiracy around the Codex thing like you're implying. I know plenty of devs who don't work for OpenAI who prefer Codex ever since 5.2 was released and if you read up a little on Peter Steinberger he really doesn't seem like the type of person who would be saying things like that if he didn't believe them. Don't get me wrong, I'm not fan boy-ing him. He seems like a really quirky dude and I disagree with a ton of his opinions, but I just really don't get the impression that he's driven by money, especially now that he already had more than he could spend in a lifetime.
I didn't say he didn't care about money, I just don't think that's his main driver, especially since he's already set for life. He spent 10 years building a company around a genuinely valuable product that just about everyone was using and, yeah, it made him rich.
I think "I'm going to keep the money I made from the company I spent 10 years building" and "I'm not going to lie about the coding tools to try and court a deal with OpenAI" aren't contradictory values. If anything, after hearing him talk for a while, I think it's way more believable that he switched from CC to Codex because Anthropic sent lawyers after him over the ClawdBot name than because of an OpenAI deal.
Having a few hundred thousand doesn't make you greedy, it makes you fortunate.
Having a hundred times that does make you greedy. You had more than enough long before getting to that point. You could have been content with less, so the only reason to try to extract more out of others is greed.
If I'm reading this correctly, caching only happens if I give it a stable cache key? If that's true, this just seems like an insanely bad decision. I've seen waaaay to much bad React code to think that that isn't a massive foot-gun.
1. That combined with hot reloading just makes me think some jr dev is going to forget to put that there while they're building something locally and burn through their LLM budget without even knowing it.
2. What happens if the cache key changes. Is there any way to migrate from one key to another? Let's say I'm using user ids as the cache key and you need to do a migration that changes the format of the key, is the existing design just gone forever?
3. Does anyone even want a non-deterministic UI? Don't get me wrong, it's a cool for a demo, but I can't think of anything that would annoy me more than coming back to a website and every week it looks different.
Sorry to be a downer, but man, I just really struggle with this. If this is just kind of a cool hobby project then you can ignore #3, but for 1 and 2 I really feel like it'd be a better to do something like have a data attr for the prompt and then have component generation be something a user kicks off through a script or something.
I only switched to using the terminal based agents in the last week. Prior to this I was pretty much only using it through Cursor and GH Copilot. The Anthropic models when used through GH Copilot were far superior to the codex ones and I didn't really get the hype of Codex. Using them through the CLI though, Codex is much better, IMO.
My guess is that it's potentially that and just momentum from developers who started using CC when it was far superior to Codex has allowed it to become so much more popular. Potentially, it's might be that, as it's more autonomous, it's better for true vibe-coding and it's more popular with the Twitter/LinkedIn wantrepreneur crew which meant it gets a lot of publicity which increases adoption quicker.
Out of curiosity, what do you feel are the key differences between cursor + models versus something like Claude Code/Codex?
Are you feeling the benefits of the switch? What prompted you to change?
I've been running cursor with my own workflows (where planning is definitely a key step) and it's been great. However, the feeling of missing out, coupled with the fact I am a paying ChatGPT customer, got me to try codex. It hasn't really clicked in what way this is better, as so far it really hasn't been.
I have this feeling that supposedly you can give these tools a bit more of a hands-off approach so maybe I just haven't really done that yet. Haven't fiddled with worktrees or anything else yet either.
AFAICT it really is just a preference for terminal vs IDE. The terminal folks often believe terminal is intrinsically better and say things like “you’re still using an IDE.” Yegge makes this quite explicit in his gastown manifesto.
I been using Unix command lines since before most people here were born. And I actively prefer cursor to the text only coding agents. I like being able to browse the code next to the chat and easily switch between sessions, see markdown rendered properly, etc.
On fundamentals I think the differences are vanishing. They have converged on the same skills format standards. Cursor uses RAG for file lookups but Claude reads the whole file - token efficiency vs completeness. They both seem to periodically innovate some orchestration function which the other copies a few weeks later.
I think it really is just a stylistic preference. But the Claude people seem convinced Claude is better. Having spent a bunch of time analyzing both I just don’t see it.
reply