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.

That’s also roughly what I find after a long English-only session with a coding agent. Our conversation covers a lot of ground... and leaves out details at every level. When I look at what got built, the misunderstandings are fractal too.

I agree it’s important to design it yourself, but UML is only one level. Lately I’ve been using a scratch Python file (or even a scratch repo) that Claude and I both edit. Never mind that I’m writing Rust. Python reads like pseudocode, and pass and ... (Ellipsis) let me skip whatever I don’t care about. At any level where I do care, I can say exactly what a method’s signature should look like, what fields a domain model should have, or how it should maintain key invariants. Everywhere else I leave an ellipsis, maybe a docstring, and let the agent decide.

It works both ways: I ask the agent to sketch the current system in Python, with some details elided and others spelled out. Then I edit the sketch and have the agent push the changes back into the much bigger Rust+Tauri app.

Time will tell whether this approach has legs, but when I want to be precise, I find it sometimes pays to just write some code.

I’ve also tried spending an hour or two first before handing over control. That way there’s something pre-existing it can work from.

* Bite sized jobs, about what you would expect for a traditional user story.

* 10-15 minutes discussing the implementation. It's almost the exact same conversation I would have with a human engineer. I'm almost entirely asking questions - "How would you do Xyz? What about this problem? What about that problem?"

* At the end of the conversation, both the AI and I have a good understanding of the problem and the solution.

* I say "do it".

* There are occasions when I don't fully understand what it wants to do. I'll tell it to do the work, then we discuss it afterwards. Sometimes we change things, sometimes I just need to see the code to understand.

* It doesn't commit code. I do.

This has been really effective for me, easily 10X'd or more my pace of development. Sometimes I have to ask for a lot of rework and sometimes it one-shots it. But I never ship something I don't understand and it always feels like "my" code. Very satisfying. More satisfying than typing it all out; the typing was never the fun part of programming.

But that's at the scale of <1kloc. Might be different if you're trying to do a bigger feature all at once.

Guiding the LLM (or humans structuring/guiding juniors) to shape the abstractions help make the overall feature and reliability of the code much better.

The best results for me have been when I write something 100% in a language and when it is done the AI takes my implementation and ports it to another language.

Sometimes the grass really is greener - company culture can be actually incredibly toxic and compensation very below market, but when surrounded by people who normalize it most folks will project that experience out to the rest.

I might be lucky (in a sense I am, but in another sense "all" I've done is work boring normal jobs and have low expenses), so maybe my path is not perfectly reproducible, but that's kind of the point of temptation: it has to be tempting. And quick, easy, sure money is the bait. You'll never even be held accountable. The only cost is looking around at the bad things in the world and knowing it wouldn't have been there without you.

Personally, the only reason I have to continue working these days is to give my kids a better future, so creating a hellscape for them to inherit would defeat the purpose.

They care a lot about prestige. Or at least did before AI. Don’t know what their current hiring practices look like.

Comfort yourself with the fact that you did not have to sell your soul, sit through endless woke sexual harassment videos where you are taught that the white man is the source of all evil, and in endless management meetings.

> sit through endless woke sexual harassment videos where you are taught that the white man is the source of all evil,

In big tech I had fewer trainings than any other org in my career, because they knew time was money.

There’s always been a percentage of luck getting offers from big tech companies, but it’s way more luck than than merit it has ever been.

I'm old enough now to be a protected class, so I don't want people accusing me of ageism, because that's not where this is coming from - but there's a type of person that clearly is on their last job of their career and knows it and I try to avoid them like the plague, I've seen it too many times.

Yup (and it's not ageism).

I'm young and stupid but forced by circumstance to practice a certain degree of respect for my own stupidity.

My philosophy is, "I write code like I expect it to outlive me".

Because sloppy work --AI generated or otherwise-- has a tendency to come back to haunt you.

The code isn’t for you. It’s for them.

Of course, there’s also a chance you’ll be them. :)

By the time the system starts to experience strain under the weight of its technical debt two years later, the original tech lead/architect of the project has already added it to his resume as another bullet point, found a new job at 20% higher comp, and no longer has to ever look at that code, ever again.

Now it's the next asshole's problem. Good luck!

[0] Freeman & Pryce 2009 for the "internal quality" vs. "external quality" dichotomy

I just approve PRs, because I have to. I don't know what else to do. I can barely keep an eye on all my code.

Actively looking, but job market is rough in Northern Europe. I quit caring about quality in any capacity here, the company has clearly chosen its direction, against my very vocal complaints.

My last interview, with what I thought was a great company, failed when I didn't understand what NLP was when they asked me about it.

> NLP? > Natural Language Programming, it's the future. Claude, GPT, etc.

I laughed, he didn't, looked offended and said it was a serious question. I had thought it was a joke, said "oh you mean LLMs". I tried to answer seriously, of course, but that was my third round technical interview and I didn't get a call back.

Just getting a paycheck and producing mediocre work until I get something new. (Senior engineer, 10 YOE, patents, 3 years at a unicorn).

Also considering becoming an electrician.

Without massive scale weapon-grade NLP coming out of AI PR depts and targeting unwitting programmers, the LLM psychosis wouldn't happen.

Ahem Maybe you should write a shim for the stack you're using to broker domains.

Med school interests me, but I'm a woman in my late 20s who would like to have children, and if I started down the med school road now I wouldn't be done with training until my late 30s, where PA and nursing school don't have that problem. Medical physics is kind of in the middle.

Understand completely. I'm a little older than you but the high chance of giving up a family was the first thing on the negative column when I was deciding paths.

No one cares at best, or I'm callously told "keep up or fall behind" at worst. When that's not even the problem, it just, sucks now. There's no joy in anything I do professionally.

Can I ask where you went? I'm seriously looking for an exit, I just don't know what yet. Maybe a trade, in Scandinavia the pay is actually comparable, I just don't want to go back to school.

It can feel that way with all the hype but I very much doubt that is really true. I see an industry that is rapidly dividing into two camps - "move fast and break things" and "this actually needs to work". Writing everything with agents and merging while barely even checking what is in the PR has become standard practice in the former but it will get you laughed out of the room in the latter.

For the latter, the product looks nice and polished on the outside but makes “steaming pile of crap” a gross understatement.

I never had a better time "professionally" (albeit no income yet!) so far in my whole life! Apparently it's truly like the best of times and the worst of times to be building software, if you have the luck and the luxury to be able to work only for yourself than it's really a great time to be alive.

Often, the lack of meaningfully challenging demands being put on you is punishing on its own. It can feel like a relief for a week or month or year, but if you catch a glimpse of that being your whole future, you can come to recognize yourself as being in a mind-eroding secular purgatory.

This anguish is especially common among on highly capable people, high achievers, and those used to some kind of ambition. And by accident of its history, there's a lot of those people in this industry and some of them are going nuts now.

Pretty much this. I know it sounds melodramatic but it literally feels like rotting.

I don't solve anything anymore. I don't get any spark of fixing bugs. I don't DO ANYTHING, and it's fucking chipping away at me.

Also I'm fairly sure people are going to realise soon that if they're happy with slop, they don't actually need highly trained engineers anymore.

This whole thread actually prompted me to look into electrician work, especially in renewables that we have here in Norway.

I might fix my burnout and go to school to get my 2 year qualification. AI can't rewire a hydro dam.

?!!?

No way. Are you sure? What kind of work? Here there’s still a lot of care needed to navigate the LLM work, like knowing when to make it quit, rewrite, refactor, follow your outline.

It feels magic but when I watch people who don’t know what they are doing trying to make something new (not almost a clone of an existing product), they get pretty frustrated.

I went nuts for years, until I sold off my interest in my dream partnership.

10 years of heaven. All the benefits and none of the downsides of my internal colleagues. Then 14 years of bureaucracy aimed at predictability over progress, which was infinitely more difficult for me to dodge as an external player.

Compensation for my interest was very objectively valued, with the rate of stalled progress priced in. Which made complete sense, while also being its own madness.

I walked away from so much value, but I don't regret it for a minute.

https://en.wikipedia.org/wiki/The_Right_to_Be_Lazy

https://en.wikipedia.org/wiki/In_Praise_of_Idleness_and_Othe...

I can't believe how much mental justification needs to be made by otherwise highly intelligent people (Bertrand Russel wrote In Praise of Idleness) to defend the right to not work.

No, I fully reject any notion of life value coming from work, and those who hold your view are basically jailors to those who don't want our identity defined by work.

I would gladly not work and learn cello and physics independently if that were a real possibility, but it's not, and it won't be within my lifetime.

I had a job in a system that required jobs to survive that genuinely didn't bother me. I actually quite enjoyed it most of the time. Now it's permanently dead and I need something else, or I am homeless and starve to death.

> No, I fully reject any notion of life value coming from work, and those who hold your view are basically jailors to those who don't want our identity defined by work.

Fuck off.

Obviously there are mission critical systems where it matters, but if “your code can be A/B tested” or “slowly rolled out”, chances are, it doesn’t matter.

Tech debt is still tech debt, even if there exist models that can wade through, because it's going to require increasingly sophisticated models navigating increasingly large context windows and increasingly speculative workspace operations to keep making progress on it.

Vendors like Anthropic and OpenAI are laying a pit trap when they demonstrate how their models can independently code their whole platform as it becomes increasingly byzantine and inscrutable because not only do they benefit from internal/prerelease models but they have effectively unlimited spend because all that spending acts as a lure to draw you into their trap.

For everybody else, design still matters. People are just working really hard to make you forget.

That said, I also feel like betting on readability, maintainablility, taste, etc, being an important aspect of software, at least until code will remain some sort of human readable artifact. We'll still want to be able to understand it and perhaps occasionally add/edit by hand, make sense of it without trusting blindly what any kind of program (LLM based or not) will tell us about it, and so on.

Cost of tokens is NOT a problem unless you have a codebase with hundreds of person-years of effort. Not many people do.

It may encourage more secrecy and backend style designs though.

You're also find that implementation matters when token spend starts facing real accounting.

I really wish people would become more coherent with their reasoning.

There are legitimate FAANG-like companies that have general guidelines about “when to use Fable/GLM/DS” and etc. to keep the costs down. And I think it’ll continue that way.

https://www.cnbc.com/2026/10/11/ai-software-developer-jobs.h...

Doesn't matter as much. The cost of "maintenance" is going down, from what I can see internally, from other companies, and every story i'm reading from other organizations as well. Token budgets are changing, but model quality and effectiveness are going up as well.

> We've also been hearing for years that LLMs are going to automate away software development entirely, but software job postings are steadily rising.

I think this has been contested from day 1. SE jobs might be automated, but jobs might increase, if there's possibility of starting new companies / new investments / etc.

The analogy would be math people with AI vs. non-math people with AI trying to solve some problems. I cannot solve the problems because I have no idea how to prompt it to go specific way. But it doesn’t matter how dirty your scratchpad was, because you got to the solution.

> I don't see it happening on projects that have a minimum bar for security/reliability and long-term maintenance

I don’t get this, because this is currently, right now, at this second, happening across huge projects. My point was that maintainability is less of an issue than before. Also, frankly, over years, I’ve seen bad code that AI wouldn’t even write. So there can be a case that the maintainability/code quality isn’t even going down as the models get better.

These things are important even in a repo with zero human code. A project that's filled with tech debt will always be hard to work with no matter what latest frontier model you're using.

I think a lot of this can be automated with slop detectors that flag messy unreadable code and make agents rewrite it, but you can't say it doesn't matter.

1. We are working on different types of application and code.

2. I am in a bubble and no-one in it has experienced the standards and productivity that SOTA AI tools can achieve.

3. The advocates are in a bubble and no-one in it has experienced the standards and productivity that expert developers can achieve.

I hope the answer is 1. I fear the answer is 2. I suspect the answer is 3.

Sometimes, not enough to believe you that you can do it better. And even if you could, to believe that it's overall worth it to work in that way.

It seems too early to make any conclusion like that. We've still only been doing agentic coding for a year and capability significantly improved during that time. I don't think anybody on either side of this debate can have actual empirical evidence to support conclusions about where it lands longer term.

The main argument I see is that it probably pays to be slightly conservative because the cost of being wrong by maintaining too much oversight and shipping slightly less code is better than the cost of ending up with an entirely unmaintainable system. In some cases it will be more than "slightly less" but in almost all complex pre-existing systems, you are rate limited by a lot of other factors outside of code production, so the effective difference just isn't that high.

And it's debatable how much better they will get quickly. Verifiable rewards for maintainability of software is, I think, possible but very hard.

I also see devs, seniors as well, that have a different experience. At least that's what they say. I stay open to the possibility that I'm doing or seeing it 'wrong', but I'm far from convinced. I do like to experiment like you wrote in a later comment, things may change, and even now I do find it can be very powerful, for the right tasks.

It still applies to all things LLms can do from law to code to art to ideas.

They can do it - and very acceptably - but only to the untrained eye.

They are only as good as their training data.

I expect them to have badder taste for PHP or JS, than, say, Kotlin or Ruby.

That's be because I prefer the code the latter communities have produced over the former.

Way to come off as incredibly insecure. There's no need to randomly put people down.

The advantage I have is that I know things that are not in the training distribution. Things about our business, our product, and its internal architecture. Without this knowledge, some new features cannot be designed successfully.

Some day I expect that will change, but all the patchwork "memory" systems, all the docs etc, will never get there because at some point they just pollute context. Knowledge has to be integrated, and that is what happens during sleep for humans, during pre-training and RL for models. LLMs are terribly inefficient at learning though and degrade generally during fine-tuning.

That's it. Maybe you should go re-read?

That certainly can be true but I would challenge "generally". If you're working on something novel then it's not exactly unusual for even SOTA models to produce a first attempt that makes some very bad assumptions but then get stuck when instructed to use correct axioms instead. This looks a lot like the suduko meme - without any real insight into the problem the models end up just iterating around in circles and never finding a solution.

You probably won't see this very often if you're working on simple CRUD web applications where there are millions if not billions of lines of code in the training data set. IME you will probably see it quite frequently if you're working on - for example - software to control some kind of equipment or analyse the results of some kind of experiment where the LLM might have little if any training data about the field you're operating in.

Not any time. Your feedback loop must provide some direction so the iteration is at least heading towards an improvement. For novel applications you might not have a convenient way to do that yet.

Even with that provision there's still a possibility of incrementally updating output converging on a local maximum. That local maximum might not be a solution at all. If it is a solution then the model might still miss much better solutions that a real developer with more insight might find.

As you said yourself the models need external feedback if they don't have sufficient information to make adjustments by themselves. In some cases that feedback might be "Start again because you're hopelessly off track". Sometimes even when they start again they just get hopelessly off-track again. That can happen even if they are explicitly prompted to do something else. So even closely supervising the LLM and not using self-iterating agents isn't guaranteed to get good results for novel applications.

You're right though that in new territory you may often have domain experts who still cannot adequately define success in an automated fashion because this is literally something that hasn't been created before. So they must be a part of the loop. They cannot necessarily put into code and descriptions what "better" or "right" is for an LLM to follow. But they can recognize it when they see it. In this case, it's still best to create the tightest feedback loop you can. If the LLM is waiting 2 days for your feedback, the loop is 2 days long.

I would say that a system with some sort of binary evaluation that indicates whether it succeeded or not is receiving feedback. It could also be some kind of sliding scale - how close did it get?

Either of those might be useful for determining a good future direction to iterate in but that would surely depend on the nature of the problem and how it's possible to search for solutions. I'd still call it a feedback loop even if the evaluation wasn't enough to point in a specific direction for a further iteration though. YMMV.

For example, Li et al. (2023), Emergent World Representations, showed that a GPT model trained only to predict Othello moves developed an internal representation of the board state, without being explicitly taught the rules or board structure.

I don't really care about the code being unmaintainable. Fable 6 or whatever will take care of it, just like Opus 5.5 takes care of our Opus 4.6 slop. The code working and our feature shipping is way way more important.

I would say I am now responsible for more big-picture decisions than I was previously, with Claude taking on the role of SWE (or a team of them). Despite this, there is still way more work than people.

> The code working and our feature shipping is way way more important.

I like that we both use AI very differently (you YOLO, I don't) but can agree that these are basically the important questions. If a company or team answers them like you do, I agree with the conclusion (YOLO). To me that's still a decision to be made though, and to be made wisely. Whether to accept the code may become unmaintainable, to forwardly rely on Fable 6 and to ship above anything (or at least a lot) else.

It can keep patching everything left and right whenever a new requirement comes up so it does not "need" to build abstractions, and it will only do it to please the human reviewer.

A year from now Fable 6 will de-slopify, so I don't really care about having pretty abstractions. That's simply not my job anymore. Sacrilege, I know.

On the other hand, I do some stuff with physics simulations and LLMs will spit out arrays like

static constexpr std::array<int, Q> cx{0, 1, 0, -1, 0, 1, -1, -1, 1};

static constexpr std::array<int, Q> cy{0, 0, 1, 0, -1, 1, 1, -1, -1};

static constexpr std::array<real_t, Q> w{ real_t(4) / 9, real_t(1) / 9, real_t(1) / 9, real_t(1) / 9, real_t(1) / 9, real_t(1) / 36, real_t(1) / 36, real_t(1) / 36, real_t(1) / 36};

static constexpr std::array<int, Q> opp{0, 3, 4, 1, 2, 7, 8, 5, 6};

and it's like ??? I know what these are for, but I have no clue if any of the numbers are right :-)

I was working on a ground-up implementation of a SPICE circuit simulator that would generate code to do realtime simulation of electrical circuits. Much of the work was derived from complex mathematics in a couple of papers that I was using as a guide, and from The Spice Manual (3rd edition) which serves as a guide/standard to the Spice language, including detailed mathematical formulae, expressed in standard mathematical notion (but no code) for most of the simulation operations.

When transcribing formulae into code by hand, I had gotten in the habit of providing references to page numbers and equation numbers in comments in the code, and "footnote" comments that provided URLs to the original material.

Imagine my surprise when Claude also provided correct comment references to pages and equation numbers when I asked it to write code to implement diode models.

This is okay as an end user who only cares about features but can be disastrous when something goes wrong and your only hope is to prompt an LLM that might or might not be (a) available or (b) not read into the context of the codebase.

The scope of the problem worsens when you consider that many teams STILL don't own what they write and have SREs serve as their first-line. These folks NEED to know how the hot paths of the services they support work without the memory or tools that your Claude account has. This is much much harder to do on a codebase that's a billion SLOC for no reason with inconsistent code style and questionable tests littered everywhere

I think that writing the code OR having written a lot of code in the past is the only way to REALLY understand what's going on.

Knowing the codebase is often the difference between proactive resolution ("This keeps happening when that log message keeps appearing; here is the PR that fixes this bug; here is the runbook on what to do if something like this class of problem appears") and reactive resolution (increasing quota, which costs money and might not always be possible; rolling back, which might introduce security concerns; etc.)

This is probably the biggest reason why SREs at big tech companies are usually also SWEs or SWE-adjacent.

Yes, agents, but given that AI-generated codebases grow and change too quickly for humans to keep up, the issue becomes over-reliance on agents over time, a Russian Roulette style of problem when the cost to access to these models keeps increasing...

I quote this just to put extra weight on this! It's surprising, the effect size of this statement.

Are you working on a team? I've found that for solo projects this works but, even when you own the design of your piece, integrating with the work of several people doing this ultimately leads to even the part you initially designed no longer working exactly as you remember it.

A good chunk of my time now is spend working with an LLM to understand how other parts of the code base work and how they relate to and interact with the product features I manage. But I'm still on a small enough team that this is possible. I'm not surprised at all that an engineer at an org the size of Meta would not even be able to perform this level of work in understanding what's happening.

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

It reminds me of George Fairbanks’ Just Enough Software Architecture. He tells a story about his father, a civil engineer, who didn’t apply every engineering technique he knew when installing a mailbox. He just dug a hole, put in a post, and filled it with concrete.

The idea is simple: the effort you spend on architecture should be proportional to the risks involved. Sometimes you need careful analysis, sometimes you don’t.

Seems even more relevant now with AI coding.

I've been starting in the ChatGPT web UI, having long conversations, having it generate Markdown plans, and then editing those plans; I hand those off to implementation agents.

Do you do this with every repository that's brand-new to you? You refuse to, for example, use an agent to learn where the feature should generally live? This seems absurdly slow for that purpose, because even though humans can still get a deeper understanding of a codebase after several months, an agent can get a much deeper understanding over a timeline of the initial few days. Unless everything is already meticulously documented for you, I suppose.

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

In essence you basically say that you don't read or review the code produced in detail, you just know the high level design of how the system works.

Anyone who's ever directed AI at a very large legacy code base will have noticed that AI just gets dumber and slower the worse (larger + inconsistent) the code base gets (just like us humans do). The big difference is that with AI you can get to the point where the code base is an unmaintainable legacy mess in a fraction of the time that it used to take. Directing architecture is the only way to mitigate this to some extent.

Sometimes you do need to see how things are implemented before you know that a design doesn’t work, I’ve never been big on large upfront design work and prefer more iterative development. This can still be perfectly done with LLMs.

In practical terms it probably doesn't matter. But it's still an unsettling feeling.

I’m willing to believe that software you authored or designed yourself is better than whatever Claude spits out. I’m not as confident that the cost benefit ratio pencils out anymore. In fact, I would say most software does not need to be particularly good or well thought out. The vast majority of things I need software to do for me day-to-day at work are so niche and specialized that I tend to prefer AI slop that I can get now for a few tens of dollars at a time and something expertly crafted by a true artisan for thousands of times higher cost.

Of course I only arrived at the framework after trial and error with an LLM showed me the shape of the problem and the framework presented itself to me.

Soon that will be counterproductive and you'll be better off trusting whatever design it comes up with.

I have very particular ideas about how everything must work. Very particular ideas about which should be the tech stack. Meaning I don't have anything that uses nodejs or Rust.

The algorithms used, the abstractions that matter to me. Almost everything is different to what the AI would do if left to its own devices.

And many times I try to patch the code myself, and succeed, before giving up to the AI.

Anything else leads to insanity.

A question I've been struggling with, however, is what are the artifacts that live at this level? Are they design docs? Are they standardized? If I read your design docs, will I understand the code or do I need to "decompile" (use a coding agent to explain) to get back to this level of abstract for me to edit it?

I have found that making the AI look the plantuml and the rendering and reviewing before presenting it to me results in much more legible designs. To me the peak of this would be a shared interactive whiteboard w the ai during design.

I am very much in agreement with you. What language do you do the design in?

I have hand written a bootstrap MD file in English, which guided a Greenfield implementation. Do you actually use a UML language?

I suspect there is a missing language (abstraction) here, English can be a bit unclear and ambiguous. Perhaps an AI dialect?

Planning is fundamentally so critical to ensuring alignment and outcomes, that over time how one plans can be better trained into the process to help do more and more of it.

Coding is however just one small aspect of bringing software into being. We generally start with an intuition. That intuition comes from context.

That context, hard won as it is, for software engineers at least, was mostly a side effect.

You had to buffer a significant portion of the system in your mind to be able to manipulate it. LLMs remove that constraint. Now you can just prompt from the upstream intuition and its passable a good portion of the time.

Notice the catch? If you don't get to the beat of the system your interaction with it will be jarring, for yourself, for the person using the software and for the agent building it.

So I made a tool to help get the context into my head faster. No its not an app (it could be but meh) Its a skill that helps the LLM make a voice narrated walkthrough of the complexity so you retain context Check a demo here if you want https://theronburger.github.io/review-story/

It still needs a lot of back and forth before I'm comfortable it's not doing slop architecture, but once it's on thesame page as me it genuinely is better at it than me.

The pace of AI is literally changing so fast that we can't keep up. Your strategy here was probably true around 3 to 4 months ago. Right now it's no longer true. Not many people understand navier stokes and that's what AI can offer, it can offer some superior problem solving methodology with the level of complexity of navier stokes that you have no hope of understanding without years of study and education to get yourself up that level.

This is not a trivial question with a trivial answer.

Unfortunately your answer is outdated. I think if trendlines continue, the answer is trending violently towards putting more and more trust towards AI.

For those of us with practical budgets not measured in the millions, that bar for stupidity is pretty damn low, and I’m not convinced that there’s enough compute being built to account for every idiot in the world.

I'm saying ask the AI something beyond your intellectual capabilities. Or ask it something beyond your intrinsic knowledge base. It can produce a working machine that does the job, but you won't be able to understand it.

You can still verify the machine works by using the machine... but you won't necessarily understand it. Similar to how you own a smartphone... you know it works, but you will never fully understand everything about it.

Until it doesn’t, and then you’re too stupid to understand why not. Was it that your prompt wasn’t good enough? Does the model not have enough context? Is it even possible for your request to be satisfied?

> What does human stupidity have to do with this?

You answered this yourself:

> but you won't be able to understand it.

And:

> I'm saying ask the AI something beyond your intellectual capabilities. Or ask it something beyond your intrinsic knowledge base.

What’s the limit to this? “Claude build me a nuclear fusion reactor.” Surely we can agree that there’s a limit or we’d already be living in some post-scarcity utopia. So what’s the limit?

I’m suggesting a limit: human stupidity is limitless while compute is finite. We can use the word “ignorance” if the word “stupid” is too inflammatory.

You’re unable to comprehend the topic of the conversation.

We’re talking about querying the model with prompts and asking for solutions beyond your intelligence. You’re talking about flawed prompts.

> You answered this yourself

You’re rude af. Not understanding something is not intrinsically bad.

In fact you use things you don’t understand on a daily fucking basis. Your iPhone, your car, your computer. All of these things have aspects of it beyond your intellectual capability to fully grasp or comprehend and yet you use it. Sometimes these people who make these things produce faulty products and you ask for a refund and are more careful in the future about what you trust, sometimes the product is exemplary.

Relying on an LLM to do something for you is much of the same.

Get it? Probably not. What are you going to do? Call me stupid again because you have nothing substantial to say? lol.

Edit: you edited your response which is uncharitable. But whatever I’ll respond to your new statements below.

> What’s the limit to this? “Claude build me a nuclear fusion reactor.” Surely we can agree that there’s a limit or we’d already be living in some post-scarcity utopia. So what’s the limit?

I agree. But this is not the topic of conversation. I’m talking about querying LLM to do something beyond your ability. This is something you can do and also stay well within the obvious limit you’re implying here.

> I’m suggesting a limit: human stupidity is limitless while compute is finite. We can use the word “ignorance” if the word “stupid” is too inflammatory.

You don’t need to suggest a limit. It’s obvious ai can’t build a nuclear reactor. Nobody needs to be told this.

A clever quote doesn’t prove shit. Ok so human stupidity is limitless. Computer is also finite. I agree.

How the fuck does the above two facts which I agree with have anything to do with me asking the LLM to make something I have no knowledge about? “Hey LLM write an emulator for this Zelda n64 game.”

The prompt is well within the “limit” of what an LLM can do. Compute is still limited. And human stupidity is still boundless. Nothing has changed. Why? Because someone is ignorant and unaware they are prancing off topic onto orthogonal concepts.

But in your argument we are all essentially idiots compared to AI, and should essentially embrace that, dunno why you take offense to it. I essentially agree. Where I disagree is how far we can make it without human intelligence in the loop because of finite compute power.

I'm saying right now in your personal workflow you are giving up many useful features of AI when you only allow it to implement your design as opposed to letting it design for you.

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.

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

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.

> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script.

and

> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.

If you can affectively use vim macros, then GREAT! But if you cannot, even with using vim for decades, then please don't advertise them as the "fun" part.

And the other thing is that vim has the “dot” command to repeat your last edit. Similar to macros, you think about your local edit first, then about where to repeat it (usually tied to the next item in the search list).

Edit (after reading the article).

Both vim and emacs (which have the steep learning curve) are aimed at power users. It’s best to compare them to professional tools like CAD, DAW, industrial appliances,… The friction when learning is because a lot of users don’t know what’s possible to do or even have the kind of problems that experienced users do (or they fail to perceive them as issues). After a while, it becomes like an extension of your thinking and the tool disappears.

You think about the evolution of the internal state and the suitable commands just appears, just like you think of an idea and the suitable words appears. Learning commands is like expanding your vocabulary, not learning how to speak. Learning how to speak is internalizing the aforementioned conceptual model.

That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it. When you do a macro, you have to try and get it right, and then try again from the start each time to get it right. `dot` et al are not enough in that regard. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.

If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.

Also, getting bulk editing perfect, including the edge cases, is inefficient regardless of the tools you use. For the majority of those cases, I would just combine simple search and replace (cgn), dot repeat (.), and undo plus skip (un) for the edge cases. Then jump back (N) to the edge cases and make manual edits. It's quick, provides instant visual feedback, and requires less cognitive work than trying to process it all at once. And that's the approach people likely have in mind when they mention dot repeat.

[1] Or at least stepping right close to it.

I do not disagree with that

> When you do a macro, you have to try and get it right, and then try again from the start each time to get it right.

But you are wrong in that, because you assume that visual feedbacks are necessary. They are useful. Using vim and the likes is very much like playing the piano or driving a car. You’re always one step ahead of your actions because translating intent into operations is effortless as they are ingrained in muscle memories. I don’t even look at the cursor much of the time because it will be where I need it. I don’t care for mistakes because they are easily corrected.

Even then, I rarely use macros because they are at the high end of the power spectrum. Only writing your own commands is higher on the list. Easy macros are easy to create, powerful macros are created only when necessary and are worth the carefulness. I don’t think there’s something similar to named registers and emacs counters with multiple cursors solutions. Or the ability to have multiple macros ready to go at anytime (very useful for data cleanup).

I can't relate, either as a Vim user myself or having heard other users.

To the extent that it happens, it's surely because the macro can be seen as a sort of programming. Vim offers you two esoteric programming languages, if you want to see them that way: vimscript obviously, and the simple concatenation of Vim commands. But any system consisting of a text editor plus a way to record and play back its commands gives you the latter. Vim isn't doing anything special to create that second esolang; it's just bundling the playback mechanism.

But that rather is the point: creating the macro is as much "scripting" as actually using vimscript is. Not only is it recorded in an at-register, but it can be stored as plain text in a vimrc file. It should be compared to "written a quick script" and not to "used multiple cursors"; and any sensible Vim user would have a different approach (commonly powered by :%s/foo/bar/g , perhaps with backreferences) to the cases where Sublime's multiple cursors shine. (Yes, you can use visual-block across multiple lines if everything lines up; and yes, it's inferior to a real multiple-cursor system; and no, I don't think I've ever personally had a use case for it.)

There are people who reach a level of proficiency where they enjoy the challenge of an intentionally difficult to use programming language. Vim macros are accidentally a programming language, and definitely not intentionally difficult. And using them to "handle some one-off text-refactoring problem" is entirely missing the point, and a sign that one has more room to grow in proficiency and a lot more room in wisdom.

In short, the people you've heard this from should not at all be taken as representative of Vim users.

Search for “vim puzzle” and you’ll find entire websites dedicated to it. Here’s a random one: https://vimventure.dev/

> multiple cursors really are better than macros 99.999% of the time (since they give direct visual feedback)

I don't know what he means, vim macros also give direct visual feedback while writing them. You just edit as normal while recording, and replay those edits later. I think it is technically possible to write a macro without seeing the live effect on the text as you write it, but I've never done that.

I looked up multiple cursors out of interest, I guess the advantage is that it's one interface that is easy to explain. I would use multiple vim commands to replace it in practice.

I'll agree that multiple cursors are maybe better than macros for most of the things that someone would use multiple cursors for, but usually I wouldn't use macro's.

But I think most of the things I do with macro's cannot be done with multiple cursors.

I would be very interested in being proven wrong, if someone has some examples of "this is where multiple cursors are great, and vim doesn't have a good alternative".

And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.

If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.

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.

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.

Not much. Add to it deference to technology and the innate preference for new stuff not liked by previous generations: sloppy LLM style will look more authoritative than well thought human style of parents and older siblings.