That's a very cool analogy but I might not be understanding something here. Why then do objects that have no light have gravity? If 99% comes from time dilation, why am I stuck to the earth rather than drifting toward light sources?
The point is that mass bends space-time. The amount of bending is dependent on the size of the mass and on the distance from the mass. Even though the Sun is incomparably heavier than the Earth, it is also MUCH farther away from you. So, space-time around the Earth is curved much more towards the center of the Earth than it is towards the center of the Sun. In the mattress analogy, consider a large mattress, with a bowling ball and a car sitting on it. The car will obviously bend the mattress much more, but if you're close to the bowling ball, you'll still fall towards the bowling ball first before both you and it fall towards the car.
So, say you're in an airplane moving directly forward, with the Sun just overhead (and the Earth obviously just below you). The Earth curves spacetime towards it a lot in this area, while the Sun curves it towards itself just a little bit. The overall curvature is such that time still moves more for the bottom of the plane (closer to the Earth) than the top of the plane (closer to the Sun). So, the bottom side moves a little slower than the top side, but the structural integrity of the plane pulls the top side towards the bottom, causing a slight motion towards the Earth - gravity [note that the GP's explanation got the signs a little wrong - time flows slower, not faster, closer to a big mass]. Conversely, if the Earth disappears from the picture and only the Sun remains, now the top part of the plane will move slightly slower, pulling the bottom part towards it, and thus towards the Sun.
This article doesn't address writing code with AI, just code review. My issue with agentic coding is that I make numerous micro-architectural decisions while programming. I almost never have a full spec up front and develop one as I consider what I am writing.
When using Claude Code or Codex, that is all gone. Claude Code is extremely eager to reach the end goal to the point that it feels like a fever dream to write code with it. In the end, I have low confidence about edge cases and fit into the project's architectural and design goals.
On top of that, I enjoy programming, reverse engineering, etc. and I feel that the LLMs, while able to solve some problems or deliver some features, take that fun away. I'm trying really hard to find a workflow with them that I'm confident in, but I fear that workflow is just chat, search, and being a rubber duck for my thoughts.
> This article doesn't address writing code with AI, just code review. My issue with agentic coding is that I make numerous micro-architectural decisions while programming. I almost never have a full spec up front and develop one as I consider what I am writing.
working with AI forced me to write better specs but the way I write today is very different. I typically open Codex and have Linear MCP connected where my chat with the AI will end up writing the issue. Its a lot of back-end-forth where I tell what I want, the AI does all the code scanning, write something, I correct something, etc
The value for me is exactly that I tell what I want, the AI verify in the actual code if that's the path that makes more sense or not. In the end I have a pretty detailed spec that I'm much more confident is the correct path.
I find the spec easier to review than a huge PR so typically when executing is much faster and aligned with what I want.
> If the only impact of LLMs professionally was causing people to "think out loud" in a way which was routinely captured by computer systems and then could be operated on by computer systems, that would by itself be one of the most consequential changes in practice in 100 years
A lot of programming work is well represented in the training data. For that kind of stuff there’s not much to do regarding architectural decisions. I love to run the LLMs on auto for that work. But for anything not well represented in the training data, which could be anything from mundane stuff in PyQT or a truly novel application, keep them on a short leash or forget them altogether.
This isn’t a binary is/isn’t thing though. What if only 80% of my task is, how would I know that the other part isn’t, if I haven’t worked it through fully
What if my task is generally represented, but for my specific context, there are specific details that aren’t?
How would I know until I’ve reasoned through it myself? At that point having the LLM do the work doesn’t add much value
I find using the LLM to generate different git repo skeletons for the same class of project using the 4-5 different programming languages I’m familiar with is really interesting and helpful. Then I ask it to explicitly describe its design decisions for different parts of the small codebase, i.e. what do the internal APIs look like, so that if you make changes in one section of the codebase, you can be sure you don’t accidentally generate problems in another section of the codebase. Only once you’ve worked out all such constraints, clarified dependencies, etc. do you start generating code in each subsection and that’s done using the specific constraints for that section in each prompt, and reviewing all the code. This is also when you generate the tests for each subsection. Finally this is where using a different LLM(s) for code review after the code is written becomes important. It’s a slow process certainly but it seems to work pretty well.
> On top of that, I enjoy programming, reverse engineering, etc. and I feel that the LLMs, while able to solve some problems or deliver some features, take that fun away.
Same, I prefer asking one or multiple very technical questions to Gemini, analyze, compare and understand the responses then implement it myself based on what I learned (or just integrate it to the codebase as it is, if I asked it to write a function) than delegating away all the fun to an agent.
This is why I don't use agent-first platforms like Claude Code. I want to write software with an AI to assist me, not an AI to write my software for me. I don't want an environment whose main mode of operation is instructing an AI to write code - I want a typical IDE where I can continue writing code myself but with an assistant there to consult whenever I want it.
Even then, it's easy to fall into a trap of giving the AI a simple description and letting it fill in the blanks, but I've learned the discipline not to do that, in the same way I learned to think before I speak and design before I write code.
Planning mode is my entry point for almost all code I would have the AI write. I already have in mind what I think I want. I get it to create a detailed plan, which inevitably fills in things I didn't specify and even ask questions I hadn't considered. I iterate on this first revision spec until I think it's ready. This results in a task list. But just like waterfall doesn't mean make a plan and execute it all without looking back, executing this plan is also a stepwise iterative process. I let the AI execute the first step. I check its work. I run some tests and see if it behaves like I thought it would - the same stuff I would do during normal development. If I find issues, I go back to the plan and change it, then continue implementing the revised plan. If the previous step lead me into a dead end, I revert that one step and try again with my revised plan.
The key thing is this: this was my development methodology before AI entered the picture. Nothing has fundamentally changed. What has changed is that the AI provides input at one or more stages of the flow - offering alternatives, asking questions, running tests, researching and debugging - but in every single step the AI does not decide on the final outcome. Even if the AI wrote all of the code, I still review it and test it. Even if it suggested a design, I compare the options and review the referenced documents and decided for myself. Even if it reviews my code and says it would do a hundred things differently, I decide what suggestions I will act on and how. It's no different than I would do with having a coworker giving me ideas, reviewing my work, or making their own attempt at generating a solution. It's all helpful input and if I'm happy with it I will use it as is, but I'm still responsible for every line of code and I still make all of the decisions about what stays and what goes.
I'm sure this sounds wasteful - why use an AI if you have to review it and correct it anyway? For the same reason I delegate tickets to a team of 20 junior developers and don't do them all myself as a principal engineer - I am but one person and they are an army. Even if I have to discuss plans and options with them and review their work, they can spend the same hours I would brainstorming and researching and prototyping and debugging, and I can go over the results with them to make key decisions and make sure we are on the right track. I make the important decisions, but the leg work of getting everything in place is done by someone else who doesn't need as much knowledge or insight or experience. It is a force multiplier. It is the equivalent of a lawyer with a team of paralegals or a professor with a team of researchers and grad students. I can let the AI do the things it does well so that I don't have to, and instead I can spend my time on the things I do well that it can't do.
This is where I think we are going wrong with AI in many areas, but particularly in software development. An AI is not a replacement for an engineer - it's an engineer's assistant. It isn't a source of truth - it's a source of ideas. It's not responsible for the outcome - I am. A team of helpers can make an expert more productive, but that team isn't a substitute for the expert. Likewise, juniors still need to gain the same experiences and learn the same practices and make the same mistakes, because they still need to become experts, but they can use the AI as a guide along that journey rather than having to rely solely on another expert for mentorship.
This is helps describe my biggest pain point when engineering a program with LLMs. They do not have the full theory of the program, which makes things difficult. Additionally, the more hands-off approach to programming (even when I try to maintain involvement as much as I can) means that I lose the clear conceptualization of that piece code. I'm still trying it to see if it can work, but it is definitely a vibe shift from making 20 micro-architectural decisions in every function.
I have had success with an extremely aggressive red filter. My unchecked sleep schedule has me going to bed around 4 am, consistent over decades. I don't consume caffeine or any other stimulant. In the last 4 months I switched my lights to LED bulbs to turn red at 6pm and use QRedshift on Linux (Mint) with the temperature set to 1000k at 6pm. I have consistently been falling asleep around midnight. What is remarkable to me is that I am actually feeling tired at night.
As someone who spent time writing a native slack alternative... It's massively more challenging to do so, and means that you won't have the exact same experience on different platforms. Auto correction etc. behaves different, font rendering, buttons, interactions, all different.
If I had to do it today, I'd look at egui, but I have concerns about its lack of UX (it's still early), or electron still, with a sane language (The wails project looked interesting too).
I have the complete opposite impression w.r.t. architecture decisions. The LLMs can cargo cult an existing design, but they do not think through design consequences well at all. I use them as a rubber duck non-stop, but I think I respect less than one out of every six of their suggestions.
They've gotten pretty good IME so long as you guide it to think out of the box, give it the right level of background info, have it provide alternatives instead of recommendations, and do your best not to bias it in any particular direction.
That said, the thing it really struggles with is when the best approach is "do nothing". Which, given that a huge chunk of principal level work is in deciding what NOT to do, it may be a while before LLMs can viably take that role. A principal LLM based on current tech would approve every idea that comes across it, and moreover sell each of them as "the exact best thing needed by the organization right now!"
Knowing when to nudge it out of a rut (or say skip it) is probably the biggest current skill. This is why experienced people get generally much better results.
I’m not sure. I keep asking the LLMs whether I should rewrite project X in language Y and it just asks back, “what’s your problem?” And most of the times it shoots my problems down showing exactly why rewriting won’t fix that particular problem. Heck, it even quoted Joel Spolsky once!
Of course, I could just _tell_ it to rewrite, but that’s different.
Did I completely miss the technical aspect of this blog? They list an improvement but no details on how they achieved it. It sounds like a trained embedding model and a vector search. All told though this just reads as boring product talk.
The picture in the article shows what looks like keypoint matching (ie, SIFT, SURF, FAST) between the query picture and the database. This can give an exact location if a picture of the location exists in their database.
They contrasted this with their prior technique which is more of an image classifier that can identify general location from image features. This approach does not require their database to contain a picture of the exact location.
reply