bitwizeshift

I don’t believe I said I don’t use agents for things like research? There’s a difference between trying to get your bearings in a new codebase with an LLM pointing you in the right direction so that you can understand things, and just letting an LLM like Claude take the wheel to do a change for you.

Yes, new codebase we take the time to learn, as every good developer should. Ramp-up doesn’t have to be that long to get one’s bearings.

Also, changes don’t have to be deadbolted into bad designs. If the code was bad before and you have a change to make, it can sometimes be faster in the long run to redesign it and rebuild it so that it can scale better with future requirements. LLMs make this part fast and easy — but again, requires design, and designs require human brain involvement and understanding of the codebase

Yes this is on a team that I lead. We have augmented our practice so that teams do the design reviews together to ensure we are all understanding the changes. It’s also helped uplevel devs to think in terms of design practices.

It still has sharp edges but IMO it’s the best we have at the moment, and it works. It also means we deliver larger volumes of code, but we mostly look for alignment with the original review — so our reviews are more focused on what tests say behavior should be

I’m surprised I haven’t see anyone say this yet, but I don’t let the LLM design the code at all, I let it implement a design I have created.

By that I mean that, rather than let the LLM do the entire structure, I take the time to create the full hierarchy of abstractions and actors that I want my code to do. I decide, at the UML level, how abstractions will sit and interact — and then I make the LLM implement those gaps.

The key thing here is that, by doing this, I DO know how the code works. I may not know how each unit is implemented, but I know each unit’s responsibilities and how they interact with one another. I’ve found that LLMs are HORRIBLE at writing decent abstractions, regardless of how much prompting and skills I’ve given it. It will always get the job done, but it will often be unmaintainable and require bigger and heavier refactors as I introduce more and more requirement changes.

But by flexing my basic design skills, I don’t have those issues. Future refactoring fit into easy abstractions that I’ve designed. And by documenting it up front, I also have what becomes a living document on how this work will turn out.

It takes a few hours up front to plan ahead, but it makes the LLMs job easier and use less tokens, and it makes the code better long term. I don’t care if one unit is suboptimal, as long as the abstraction is right — because at worst I can change an implementation for a better one later.

It sounds like you have never used an Atlassian product, lol

There is an in between here that developers seem to keep forgetting: Design the software architecture yourself — do some whiteboarding, figure out your abstractions and your UML, then write that in your prompt for the LLM to implement through a plan.

Velocity stays high. Cognitive overhead remains low. You know enough of your architecture from the “unit” level to see how the pieces work meaning you can still work fast and understand it without hating the quality it produces. This has worked wonders for my company; I’ve managed to personally write tools that are barely distinguishable from what I’d write by hand, and I’m confident enough to discuss its architecture from top to bottom. If the LLM ever produces a unit with a poor implementation, I just rewrite that unit.

Basically: do the “engineering” part of software engineering instead of throwing LLMs at the wall until code sticks. It doesn’t take much time to come up with a good design, compared to repeatedly iterating on a bad design and maintaining it for years to come.

LLMs suck at design, and that’s why they lead to this bad code. But if a human spends an hour to build nice SOLID abstractions, and tell the LLM each responsibility — they are pretty good at using and wiring these parts together.

Thank you for this comment. I had mostly shrugged off this project as “neat” but didn’t go digging until I read this.

The choreography stuff is actually really cool! Definitely agree this should be front and center

Lol, “user defined copy/move constructors” That’s actually so many types that would define this

Well this is a take.

It’s weird how much the author fixates on Vim being “visible” and implies multiple cursors and features in Sublime aren’t. Just because your brain is trained to not think about it anymore doesn’t make it any less visible.

Multiple cursors aren’t a native feature in many tools, it is still something to learn how to use, let alone effectively — just as Vim key bindings are. Plus, vim is more than just a TUI choice for terminal-only users, it’s key bindings for people that have learned that a keyboard is a natural extension of themselves and would rather not jump back and forth to mice repeatedly — just as “multiple cursors” can be to a sublime user of 15 years.

Paywalled article on something vibe-coded? That seems like a bold strategy.

Thank you, bumholes

Aside from what some other users have said, logging is fundamentally an observable side-effect of your library. It’s now a behavior that can become load-bearing — and putting it in library code forces this exposed behavior on the consumer.

As a developer, this gets frustrating. I want to present a clean and coherent output to my callers, and poorly-authored libraries ruin that — especially if they offer no mechanism to disable it.

It’s also just _sloppy_ in many cases. Well-designed library code often shouldn’t even need to log in the first place because it should clearly articulate each units side-effects; the composition of which should become clear to understand. Sadly, “design” has become a lost art in modern software development.

You definitely are not alone in feeling this way, it’s happening everywhere now and it’s driving me nuts too.

I have the same complaint at work, where coworkers are using it for writing pull request descriptions, and it pumps out slop buzzwords like “streamlined the documentation”. Like, you didn’t streamline anything, you ran prettier on a markdown file!

On top of this type of description being useless marketing jargon, the writing style risks to train future LLMs to devolve their writing styles further into this. More frighteningly, how long until the excess amount of LLM-generated slop text like this starts training future humans reading it? People tend to model how they speak off of what they hear and read, and it’s everywhere now.

I hit send too early; Meant to say that it just knows words and that’s effectively it.

It’s cool technology, but the burden of proof of real intelligence shouldn’t be “can it answer questions it has great swaths of information on”, because that is the result it was designed to do.

It should be focused on whether it can truly synthesize information and know its limitations - something any programmer using Claude, copilot, Gemini, etc will tell you that it fabricates false information/apis/etc on a regular basis and has no fundamental knowledge that it even did that.

Or alternatively, ask these models leading questions that have no basis in reality — and watch what it comes up with. It’s become a fun meme in some circles to ask for definitions of nonsensical made up phrases to models, and see what crap it comes up with (again, without even knowing that it is).

I don’t really think one needs to define intelligence to be able to acknowledge that inability to distinguish fact from fiction, or even just basic cognition and awareness of when it’s uncertain, telling the truth, or lying — is a glaring flaw in claiming intelligence. Real intelligence doesn’t have an effective stroke from hearing a username (token training errors); this is when you are peeling back the curtain of the underlying implementation and seeing its flaws.

If we measure intelligence as results oriented, then my calculator is intelligent because it can do math better than me; but that’s what it’s programmed/wired to do. A text predictor is intelligent at predicting text, but it doesn’t mean it’s general intelligence. It lacks any real comprehension of the model or world around it. It just know words, and

Why “perma goodbye”?

Go has a similar function declaration, and it supports anonymous functions/lambdas.

E.g. in go, an anonymous func like this could be defined as

foo := func(x int, _ int) int { … }

So I’d imagine in Zig it should be feasible to do something like

var foo = fn(x: i32, i32) i32 { … }

unless I’m missing something?