Yup, very parisian. Love how then they almost mock how pain (bread) is pronounced in the south-west where you won't mistake the sounds between the words un pain.
Not the same - I still want to be able to just use and carry round the one thing without needing a monitor, mouse, keyboard etc at every single location, but I basically never need to use it somewhere where there isn't a wall socket available.
It seems ridiculous on the surface, since you'd think you'd just buy a desktop or something, but with a laptop with no battery, and hypothetically better everything else, it would eliminate the need for a bunch of other peripherals
The point is: when I was a kid, all Lego sets consisted almost completely of general bricks. You could, and would, start building different things from the moment you got your first set, and the possibilities would increase exponentially once you got a few more sets. Any set contributed to your collection of building blocks to create new things.
I really don't get this sentiment. The only sets that I think didn't contribute like this were the bionicle stuff. Getting a few more unique parts with a set gives you more options, not less.
I think you have the same feeling I have with most modern sets (and especially technic ones): not blocky enough and too much smooth curved surfaces. But you can still make blocky stuffs if you want to, while being able to learn modern lego building methods and integrate those curved designs in your builds.
I don’t think this is true at all. What do you mean by “general bricks”? If anything there is more brick-built stuff nowadays.
For example the Creator 3-in-1 Castle (which I got for my son for Christmas) is pretty similar to castle sets I had as a child but basically way better and with brick built horses rather than large mould ones
The 3-in-1 sets (where the set numbers actually begin with 31) should really be the first thing you look at when choosing a set for a child, and they deserve more praise. There are a lot of cool 3-in-1 sets out there. That castle (31168) is really good (and those horses are too!), and the haunted mansion (31167) is just cool with minifigs which are a hit with any kid.
For a small and cheap present that hamster (31376) is just too cute to pass up too.
It feels like those sets are where the Lego designers get to do their thing and do it right, without the weight of licenced IP (of which there is so much) and the trite offerings of the City range.
Other ones that to me felt like completely fair value and better than anything I had as a child were the Creator Bunny, Space Telescope, and Space Robot. Something like £18/£25/£25 the second two having light bricks included.
JK Brickworks has an alt build for the bunny that doesn’t require a massive amount of different pieces and makes it lay mini eggs.
This might actually be a limitation of the "predict next word" approach since the network is never trained to predict a result in one field from a result in another. It might still make the connection though, but not as easily.
Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code".
Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you can ask your agent to change a feature and be 100% sure they won't break other features then you don't care about how the code looks like.
All the hype is on how fast it is to produce code. But the actual bottleneck has always been the cost of specifying intent clearly enough that the result is changeable, testable, and correct AND that you build something that brings value.
> Once you can ask your agent to change a feature and be 100% sure they won't break other features then you don't care about how the code looks like.
That bar is unreasonably high.
Right now, if I ask a senior engineer to change a feature in a mature codebase, I only have perhaps 70% certainty they won't break other features. Tests help, but only so far.
This bar only seems high because the bar in most companies is already unreasonably low. We had decades of research into functional programming, formal methods and specification languages. However, code monkey culture was cheaper and much more readily available. Enterprise software development has always been a race to the bottom, and the excitement for "vibe coding" is just the latest manifestation of its careless, thoughtless approach to programming.
> functional programming, formal methods and specification languages
Haha. Tell me you've never done professional software development without, etc. None of those things are solutions to the problem, which is: does the code do the business value it's supposed to?
There are limits how badly can such senior screw up, or more likely forget some corner case situation. And he/she is on top of their own code and whole codebase and getting better each time, changing only whats needed, reverting unnecessary changes, seeing bigger picture. That's (also) seniority.
Llm brings an illusion of that, a statistical model that may or may not hit what you need. Repeat the question twice and senior will be better at task the second time. LLM will produce simply different output, maybe.
Do you feel like you have a full control over whats happening here? Business has absolutely insatiable lust for control, and IT systems are an area of each business that C-suite always feel they have least control of.
Reproducibility and general trust is not something marginal but core of good deliveries. Just read this thread - llms have 0 of that.
But if push come to shove any other engineer can come in and debug your senior engineer code. That's why we insist on people creating easy to change code.
With auto generated code which almost no one will check or debug by hand, you want at least compiler level exactitude. Then changing "the code" is as easy as asking your code generator for new things. If people have to debug its output, then it does not help in making maintainable software unless it also generates "good" code.
This is the brake on “AI will replace all developers”.
Coding is a correctness-discovery-process. For a real product you need to build to know the right thing. As the product matures those constraints increase in granularity to tighter bits of code (security, performance, etc)
You can have AI write 100% of the code but more mature products might be caring about more and more specific low level requirements.
The time you can let an agent swarm just go are cases very well specificed by years of work (like the Anthropic C compiler)
I am constantly getting LLMs to change features and fix bugs. The key is to micromanage the LLM and its context, and read the changes. It's slower that vibe coding but faster than coding by hand, and it results in working, maintainable software.
The comments explain the nuance there pretty well:
> This study had 16 participants, with a mix of previous exposure to AI tools - 56% of them had never used Cursor before, and the study was mainly about Cursor.
> My intuition here is that this study mainly demonstrated that the learning curve on AI-assisted development is high enough that asking developers to bake it into their existing workflows reduces their performance while they climb that learing curve.
Giving people a tool, that have no experience with it, and expecting them to be productive feels... odd?
That's a good point. Myself is the easiest person to fool.
I knocked together a quick analysis of my commit graphs going back several years, if you're interested: https://mccormick.cx/gh/
My average leading up to 2023 was around 2k commits per year. 2023 I started using ChatGPT and I hit my highest commits so far that year at 2,600. 2024 I moved to a different country, which broke my productivity. I started using aider at the end of 2024 and in 2025 I again hit my highest commits ever at 2,900. This year is looking pretty solid.
From this it looks to me like I'm at least 1.4x more productive than before.
As a freelancer I have to track issues closed and hours pretty closely so I can give estimates and updates to clients. My baseline was always "two issues closed per working day". These are issues I create myself (full stack, self-managed freelancer) so the average granularity has stayed roughly constant.
This morning I closed 8 issues on a client project. I estimate I am averaging around 4 issues per working day these days. I know this because I have to actually close the issues each day. So on that metric my productivity has roughly doubled.
I believe those studies for sure. I think there is nuance to using these tools well, and I think a lot of people are going backwards and introducing more bugs than progress through vibe coding. I do not think I have gone backwards, and the metrics I have available seem to agree with that assessment.
Love your approach and that you actually have "before vs. after" numbers to back it up!
I personally also use AI in a similar way, strongly guiding it instead of vibe-coding. It reduces frustration because it surely "types" faster and better than me, including figuring out some syntax nuances.
But often I jump in and do some parts by myself. Either "starting" something (creating a directory, file, method etc.) to let the LLM fill in the "boring" parts, or "finishing" something by me filling in the "important" parts (like business logic etc.).
I think it's way easier to retain authorship and codebase understanding this way, and it's more fun as well (for me).
But in the industry right now there is a heavy push for "vibe coding".
I'd add in "code is easier to write than it is to read" - hence abstraction layers designed to present us with higher level code, hiding the complex implementations.
But LLMs are both really good at writing code _and_ reading code. However, they're not great at knowing when to stop - either finishing early and leaving stuff broken, over-engineering and adding in stuff that's not needed or deciding it's too hard and just removing stuff it deems unimportant.
I've found a TDD approach (with not just unit tests but high-level end-to-end behaviour-driven tests) works really well with them. I give them a high-level feature specification (remember Gherkin specifications?) and tell it to make that pass (with unit tests for any intermediate code it writes), make sure it hasn't broken anything (by running the other high-level tests) then, finally, refactor. I've also just started telling it to generate screenshots for each step in the feature, so I can quickly evaluate the UI flow (inspired by Simon Willison's Rodney tool).
Now I don't actually need to care if the code is easy to read or easy to change - because the LLM handles the details. I just need to make sure that when it says "I have implemented Feature X" that the steps it has written for that feature actually do what is expected and the UI fits the user's needs.
> Do current LLM based agents generate code which is easy to change?
Yes, if that's your goal and you take steps to achieve that goal while working with agents.
That means figuring out how to prompt them, providing them good examples (they'll work better in a codebase which is already designed to afford future changes since they imitate existing patterns) and keeping an eye on what they're doing so you can tell them "rewrite that like X" when they produce something bad.
> Once you can ask your agent to change a feature and be 100% sure they won't break other features
We won't be able to be sure of 100% with LLMs but maybe proper engineering around evals get us to an acceptable level of quality based on the blast radius/safety profile.
I'd also argue that we should be pushing towards tracer bullets as a development concept and less so prototypes that are nice but meant to be thrown away and people might not do that.
The clean room auto porting, after a messy exploratory prototyping session would be a nice pattern, nonetheless.
The thing is, the Toyota methods relies on people on every level to work to improve processes. If you're an employee and know you'll be there 10 years down the line or even until you retire, you have an incentive to improve said processes.
Now check most Western companies: since the 70 / 80, everything is about reducing headcount. Lay-offs, outsourcing, offshoring, now the concept of spending your whole working life at the same company feels like a fever dream. So why would an employee try to improve things for the company when they know there is no future for them there? Better improve their own career and future prospect. So yeah, things like Kaizen are doomed to fail until things change.
> Lay-offs, outsourcing, offshoring, now the concept of spending your whole working life at the same company feels like a fever dream
You are missing something here imo, very few companies actually increase pay (or to be more clear, show a clear way to get there) enough to make it attractive enough to stay there for long periods of time.
From my experience here in Germany the people staying at companies for a long time are those who don't focus on their career.
Well, anyone using the product of an open source project is free to fork it and then take on the maintenance. Or organize multiple users to handle the maintenance.
One thing most of those lack is an easy way to share screen.
Now if anyone wants to differentiate their Discord alternative, they want to have most of discord functionalities and add the possibility to be in multiple voice chats (maybe with rights and a channel hierarchy + different push-to-talk binds). It's a missed feature when doing huge operations in games and using the Canary client is not always enough.
I’ve been self hosting Element Call and use it to call my girlfriend (and also used it with another friend a few nights ago). I’ve had a few problems where when starting the call it seems to not connect but just trying again works, and that’s really the only issue i’ve had that I can think of since setting up a TURN server (before that it would completely fail sometimes, but that’s not Element Call’s fault)
Thanks for sharing. I think the design of MatrixRTC (especially the scaling via hierarchical SFUs) looks promising. It's nice to see someone actually using it at this early stage, even if only for 1:1 calls.
I use MiroTalk for it. Within Element you can set up widgets (basically PWAs) and so you can call via Element’s built in Jitsi widget (or a more reliable dedicated Jitsi link) and then use MiroTalk to share screens. It is a LOT better, especially for streaming video.
In terms of ease of use, it’s like three clicks. Technically more than Discord, but it’s p2p streaming so it’s far nicer quality.
My question would be: what are the myriad other projects you tasked Opus 4.6 to build and it could not get to a point you could kinda-sorta make a post about?
This kind of headline makes me think of p-hacking.
reply