Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.
I'm fully on the agentic coding train and haven't manually typed code in a while so I understand the sentiment around moving beyond this level of analysis. However, how can this advice work practically speaking, day to day? Especially at ones day job?
I'm sitting here working and just caught a handful of really bad decisions by the agent, one right after the other, cascading from an assumption that was incorrect. My ideas and architecture are sound in this codebase! Are those things simply to remain in the code if they work 'good enough', or are there consequences right around the corner?
I have found including this in my AGENTS.md to be quite transformative in this regard:
> Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently.
> Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful.
> The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.
> It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run.
Is this for llm purposes? In many forms of TDD a compile error is key to the red phase. And you are going from red to green before asserts even exist is part of the process.
For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction
But that does come with tradeoffs, and it's not the right thing for every project. But when it does work it does increase the amount of work you get out in the same time
>For complex code changes or bigger features I often spend hours with an LLM refining architecture
The problem here is that the LLM hallucinates, so
* it will tell that something is a bad idea, even when it is not.
* it will miss good ideas.
But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actually just doing a slightly better rubber ducking...
The LLM will often miss the most obvious simplifications. And if I ask it to present me with six approaches how we could solve a problem, chances are we will settle on number seven or eight, both my ideas after rejecting all the other six. But those first six were still valuable for coming up with the version we actually settle on. Making the rubber-duck talk is genuinely useful.
And the rubber duck is actually pretty good at the localized grunt work, so you can spend more time talking with it about big-picture stuff
> I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions,
Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.
I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.
But the CPU is not executing the textual description of your architecture. It executes code.
Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.
How much of the source code of the compiler you use did you read? How much of the source code of the standard library of your chosen language did you read? What about the dependencies?
How much of the source code of a huge codebase does the average developer read? I don't think any human alive has read the majority of code in huge codebases like Word, Windows, Linux, etc.
For almost every developer, the majority of the code you use every day, whether in software you use or actual code you're shipping, is not code you've ever read. And no one seems to have a problem with it, because we've built lots of processes around this. It's only when the code is written by an AI and not a coworker or random library author that people seem to have a problem.
And I get it! AI wasn't very good at writing code two years ago. Maybe even a year ago. I think it's good now, but maybe you don't - ok, that's fine, maybe it'll only live up to your standards in a year or two or ten. But that doesn't seem to be what people are arguing, it's not "AI isn't good enough", it's "how can we possibly ship code we never read", and my point is that we've all been doing this for our entire careers.
The idea is that -someone- reviewed the lines of code they modified, leading to the sum of code being looked at by many human eyes. Using someone else's code has always been a system of trust in this way.
AI/Vibecoding breaks this social trust, hence the general aversion to using those codebases or bringing LLM code in. It's not really about the general quality of the agents. It's about the code no longer being reviewed and understood by a human. How can one place trust in that? Unit tests don't replace careful review and considerate design.
The code we've shipped throughout our careers certainly wasn't reviewed only by us. It was reviewed by programmers with more expertise in the relevant area. That's a healthy and efficient division of labor, expertise, and responsibility.
NTS radio https://www.nts.live (and the app) is my most recent favorite way to discover, underground/rare/undiscovered music, curated by humans that are experts in their scene or musicians themselves. Covers many genres
Wonder showzen was inspired by this stunt and took their episode budget of ~$100k and paid a homeless person $10k to throw another $10k out of a helicopter onto the statue of liberty. It didn’t work out in the end but still was a hell of a tribute in theory. See https://www.brooklynvegan.com/wonder-showzen-creators-talk-t...
These zwift races require two data inputs, one from a power meter (pedal or crank) and one from the trainer. So manipulating just the trainer flywheel would not be enough.
> We will then begin the hybrid pilot in full on May 23, with people coming to the office three days a week — on Monday, Tuesday, and Thursday — and working flexibly on Wednesday and Friday if you wish.
Though personally I'm fully remote, everything I've read and seen suggests something like this is going to be extremely common. Most employees seem to want to come into an office on a semi-regular basis but not 5 days a week. And, if you're going to do that, you probably want some level of coordination whether it's at a company, facility, or team level.
Can confirm. We do something like this (2 days in, 3 days remote). We have one mandatory day and then each team has a designated day where their whole team is present. I never minded going into the office anyway because I live in a fairly small apartment, so it's nice to have dedicated space away from home. The only downside I've experienced so far is that the all-teams day can be very chaotic, with more disruptions than ever before because everyone tries to plan everything that is more than a little involved for that day.
As long as the ISA can get compiled for from Tensorflow, Torch or whatever DeepLearning AST is used geht's comppiled down to it the user won't notice unless he is optimizing his model for the hardware in which cases he would also have to care about the equivalent implementation details
Private relay will egress from the same general region as the client source location. So if you’re in switzerland and hopping through a US exit point that is a bug. This is clearly explained in the wwdc video
Yeah, and there are solid performance reasons for that too even beyond any legal/privacy ones. Relaying across an ocean could actually be a fairly significant latency hit in many cases. Services that are completely focused on privacy even against some level of state actions (like Tor) may just accept and eat that, but that's not definitely not the threat scenario Apple is targeting and it would diminish its appeal as a fairly transparent service. Even purely in the browser people do engage in a certain amount of real-time activity. I can't see Apple considering adding thousands of miles worth of RTT ideal.
All depends on where the destination server is. If the destination is in the U.S., you might benefit from your traffic being routed through Apple's private network.
The two options are basically city-level or country but same TZ level. e.g. Toronto, or somewhere in Canada in Eastern time (which I mean would almost certainly be limited to Toronto -- presumably these options make more sense on say the East Coast for the US where there are a number of possible major locations that fit)
There are clearly some bugs. Occasionally I, in Canada, get routed through the US. This guy got routed through the US. Neither case should happen by Apple's description. Apple is quite intentionally trying to avoid their relays getting around geo-restrictions (likely to avoid them getting blacklisted).
AT&T runs transparent proxies on their network that have been known to intercept and mangle tls, and directly manipulate tcp packets on the wire.
Take a tcpdump capture on both server/client side and compare the handshake/tcp headers/negotiated window size. Often you see the server sending one thing, but the client sees another
I'm confused if this is for people that are already employed (aren't there tax implications for working in another country?) or for startup founders, or startup employees?
You won’t be taxed by the Finns since you need to be there 181 days to be considered a tax resident. For those staying for about a year, the US has a FEIE exemption that kicks in for the first 105k or so anyway. No exception for California taxes, however.
No major tax implications, it's just for 90 days... It's more like a concierge service + air bnb "experiences" and stuff like that, plus services for your family (like day care). If you wanted to apply for a longer stay that's an option too. I think it's a neat idea though, and it sounds like fun!
I think there may be tax implications since the company you work for might need to pay taxes to the country you are working in. This is the reason HR is not allowing me to work in another country even though I am 100% WFH right now due to COVID and thus physical location should not matter.
