After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walking a tightrope where screwing up was painful and expensive, and easy to take the wrong path, and abort is the universal solvent to all of that.
I do still find myself tripping up on whether the next appropriate step is to make a commit or continue the rebase, as that is dependent on if you're in a merge conflict or just editing a commit. But even when I get that wrong, and collapse two commits together, abort saves the day.
You don't need to keep their hashes because git keeps them for you. If you realise too late that things went terribly wrong, you can get the pre-rebase hashes with "git reflog". (It can take a little getting used to knowing how to identify them quickly after a rebase but they're there.)
Better yet, git reset ORIG_HEAD or whatever is usually sufficient[0]. The reflog is the general solution, but git's magic references do provide quite a few niceties.
This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.
tags and branches are both just refs to the commit and can be used interchangeably for something like this. tags are not immutable, just in convention.
if you're a beginner thats going to be very difficult, restoring the git dir a few times makes the learning process much faster, till it all clicks and you don't need too anymore
But then you have multiple copies of your repo which is inevitably going to end up with a my_project_v2_FINAL_3b/ mess, reminiscent of how people used to manage files before version control.
Not having to deal with all that is exactly what git is for.
I'm pretty comfortable with Git, but I've still done this a number of times, and in my experience this situation is very evitable. After I've completed my gnarly process (whether successfully or unsuccessfully), I just delete the folder I don't want to use.
I like the fact that it ends up being a lifecycle. I know it can have different entry points based on what you ask, and which skill you trigger first, but it inherently is chaining together skills. There also seems to be logic built into it such that if the ask is small, but you've still triggered the skill with "brainstorm", it will make judgements like "want me to skip phase X and go straight to implementation?"
I've noticed among my coworkers that we all have different amounts of trust we're willing to give the agent. That seems to manifest into some people only asking questions about the existing code, but never writing anything new with it. Others are willing to do limited targeted changes with the agent, but are unwilling to do things like let it make commits, or connect MCP servers, or really do anything that isnt fully understood by the human before setting the agent loose. Then I find myself, who has dove headlong into it all. I have skills that use MCP servers to check for pull requests, and give me summaries to give me more context for code reviews. I update Jira tickets in batches of 50+. I develop complete features exclusively through prompting the agent to do everything. I know I still have the responsibility to understand it at the same level as if I wrote it my self, and defend it and debug it.
I can easily see that superpowers would be wasted on most of my coworkers, simply because the benefits compound with the complexity of my ask. My coworkers aren't willing to hand off enough control to receive the benefits of superpowers.
I am in the completely same boat as you and completely agree that you need to “give into it” more to get the most out of superpowers. I gain so much confidence out of the actual process and all of the adversarial reviews, re-reviews, refinement, etc.
I see it as another iteration of the wave that had everyone controlling agents directly from a chat app like slack. It isn't actually a more effective way to reach flow state, exchange information faster, and move your development projects forward to greater success, its simply a novel, oddly satisfying input mechanism, at least for the first day.
Which is no different than when the iphone first came out, the basic concept of touch screens was endlessly novel as an input and output device. That novelty did a lot more heavy lifting than what we can now see in hindsight was appropriate, because now many of us won't be able to control the temperature in our cars after the touch screen fails.
I think its the same underlying mechanism that explains why I, a person who has never recorded or mixed audio in a studio, and a person who can know for certain that purchasing a 24 channel mixing console isn't going to faclilitate my career change or even hobby development. But part of me is still viscerally certain that my life would be fuller if I purchased a 24 channel mixing console.
I don't need a legitimate reason to own a tool, or a problem I would fix with it, to fantasize about using that tool.
Watching him walk out with UFC fighter Alexander Volkanovski as if he were part of his corner, and seeing him continuously, but incorrectly, anticipate that the rest of the men he was with were about to hand him something, or otherwise interact with him in any way, was honestly a mouth wide open moment for me. Not that the other guys ignored him, but that he clearly expected them all to include him at this moment that months of their preparation have lead up to, contrasted with him buying his way in to. It was one of those moments that makes you feel better about your own social awkwardness in comparison.
TDS, like BDS (ODS never really caught on), is typically known to be <President's Name> Derangement Syndrome, targeted at people who the commenter thinks to be unreasonably upset about the politician in question.
I think you're ascribing too much thought and reason to the people that use that phrase. If anything, its a signal to their ingroup that they are keeping the faith, and proving that they are sufficiently devoted.
There is most certainly still prompt engineering involved. How there can be both the responsivity to different cues like "plan this", "write this", "analyze this", "defend this", "poke holes in this", but not responsivity to the various terminology you provide in your explanations of "this", where to get information about specs/standards/requirements, what details I care about, and therefore can't compromise on, vs what details I'm willing to accept whatever the top reddit post from 4 years ago recommends.
I don't see how these systems can have the ability to be effectively expressive about all of the minutia, and not have all of the various different possible expressions lead to vastly different outcomes.
I think all of the cues that you just described are in the plan.
For example - I might (real world example from this morning):
"Create a script that installs hashicorp vault and consul, store the data on consul. Then create ahelper script that will fill the vault server with sample data. Add HTTPS support. Now write a framework that reads and decrypts the encrypted data in consul. Support old (pre 1.3) and new (post 1.3 vault). "
That generates a 6 page plan using Opus 4.8 w/1mm context, including notes on what to prioritize, what format to create the scripts in, etc... (My cursor guidance already has a couple months of hints as to what I want in terms of scaffolding unit tests, canonical linux, performance, security, etc...)
That 6 page plan is the "Prompt" - but it's entirely generated by Cursor/Opus. It's there to tweak if you want to emphasize, or provide some taste - but, honestly - it probably does a better job than I would - so ~90% of the time I just accept the plan as is.
I would say prompt engineering, in the sense of people claiming you need to include in every prompt magic incantations like "You are a senior engineer from a superintelligent alien species" and "take a deep breath and make no mistakes" doesn’t really do that much for everyday work I feel or they are all already included in the system prompt maybe. I reckon it can still edge out a few percentage points in automation.
What actually matters is the ability to communicate well in general, not anything LLM-specific. Being able to state what you want clearly and unambiguously, and having a sense for what additional information you need to dump, even when the other side claims they already have everything they need.
For months, I've been thinking of how to express or name this idea that people misname the way other people use coding agents and make bad assumptions about what sorts of tasks they could be used for, seemingly all in the service of demonstrating how derivative the end results must be. So thank you for whatever you've done to help dislodge the blocker for me.
I think there is a model in a lot of people's minds that AI coding is exclusively handing off the thought processes and ideation processes to the agent, which seems to foreclose on the possibility that it offers the least friction of any other available method to translate the users thoughts into useful artifacts, some of which are the working software that is the primary goal of development. The model says something like "I don't know what it needs to consist of, but make me this thing I'll know when I see.". But there are also plenty of people who have spent the time learning these skills before AI came along, and remain capable of performing those feats without the ai, but realize they are even more capable to do those same things with AI, in volumes that would have been previously prohibitively tedious. And now that they have the tedium wrangled, they are freed from all of these arguments that start: we can't do that because it would take forever.
> And now that they have the tedium wrangled, they are freed from all of these arguments that start: we can't do that because it would take forever.
I'm strongly skeptical of this argument, as there's only a few things you can not build a rough version and get something to ideate upon. Even with 3d games you can do design with blocks and buy models to have something to pinpoint the design.
This is still an incomplete model, in my opinion. You're still holding up what is possible as a non ai assisted developer as equal to the assisted one in the abstract, before adding in real world things like tedium, boredom, distraction, the ephemeral nature of novelty, frustration, and everything else that has derailed human software development, but inference engines are perfectly impervious to.
I can give you a concrete example: this week at work, it occurred to me that the 16 channels of expected and measured binary on or off test data I need to collect could benefit from a visualization because matching expectations will have visual properties that failures will not. So I had my AI agent create a script that encodes 16 channels of expected and measured binary wave forms over time, as a 32 channel 1Hz sampling frequency wav file, which I can view with audacity, which also has the necessary controls to measure time between transitions in the waveformms.
From hindsight, one could argue that since all of that solution consisted of rudiments of perfectly normal software that didnt need AI to be written or integrated, it was equally possible to create without AI. But knowing that could do it with the greatest of ease, for the total price of naming it, converted this from a project that required the motivation to figure out all of the necessary steps to one that just needed a good description.
I do get your point about speeds and ease of producing working code. This kind of quick win can be a good example of AI assisted tooling. But I don't generate scripts that way as I prefer to have composable blocks that I can reuse later. AI is not great at reusable code.
Another things I noticed with AI assisted programming is the one track thinking. Someone has an idea, generate a working sample and then it becomes like a sunk-cost fallacy where they don't envision any other implementation choice or design. It's about adding more feature without taking a step back and assessing the overall goal of the project and if that feature is really needed.
Antoine de Saint-Exupéry has said it best:
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
This kind of cohesiveness is often missed in projects that are AI assisted because there's no refinement step. The product and the efforts are not tempered by real world usage.
But what about compositions of your reusable blocks an order of magnitude larger than you were ordinarily willing to manually compose? A lot of this misnaming Im circling around comes down to demanding that the ai user must be giving up their agency. Whatever you can name as a good practice you don't think an AI agent is a capable of employing on its own, I can retort that a human can demand the agent employ it, along with all of its other capabilities that outstrip the human typist.
Theoretically they can. There are people that use Paint to draw masterpieces. But your argument is only true if they’re willing to do so. AI is a slop enabler, having the discipline to funnel the slop into something concise and useful is not a given.
It isn't reasonable to infer that OP was claiming to have universally been unimpressed about every facet of Fable, and now some unrelated impressiveness is the evidence of their false claims.
According to Google, this claim is sourced to a person rather famous for baseless claims, from the founding of companies he owns, to the capabilities of his products, to cash prizes for registering to vote, to when he will send humans to mars.
Continuing to accept this person as a credible source of information isnt a reasonable thing to do.
I do still find myself tripping up on whether the next appropriate step is to make a commit or continue the rebase, as that is dependent on if you're in a merge conflict or just editing a commit. But even when I get that wrong, and collapse two commits together, abort saves the day.