Agents are a boon for extraverts and neurotypical people. If it gets to the point where the industry switches to agents, I’ll probably just find a new career
I do agree it’s definetly a tool category with a unique set of features and am not surprised it’s offputting to some. But it’s appeal is definetly clear to me as an introvert.
For me LLM:s are just a computer interface you can program using natural language.
I think I’m slightly ADD. I love coding _interesting_ things but boring tasks cause extreme discomfort.
Now - I can offload the most boring task to LLM and spend my mental energy on the interesting stuff!
It’s a great time to be a software engineer!
I wish they were, but they're not that yet because LLMs aren't very good at logical reasonsing. So it's more like an attempt to program using natural language. Sometimes it does what you ask, sometimes not.
I think "programming" implies that the machine will always do what you tell it, whatever the language, or reliably fail and say it can't be done because the "program" is contradictory, lacks sufficient detail, or doesn't have the necessary permissions/technical capabilities. If it only sometimes does what you ask, then it's not quite programming yet.
> Now - I can offload the most boring task to LLM and spend my mental energy on the interesting stuff!
I wish that, too, were true, and maybe it will be someday soon. But if I need to manually review the agent's output, then it doesn't feel like offloading much aside from the typing. All the same concentration and thought are still required, even for the boring things. If I could at least trust the agent to tell me if it did a good job or is unsure that would have been helpful, but we're not even there yet.
That's not to say the tools aren't useful, but they're not yet "programming in a natural language" and not yet able to "offload" stuff to.
The non-determinism is not as much as a problem because you are reading over the results and validating that what it is created matches what you tell it to do.
I'm not talking about vibe-coding here, I'm grabbing the steering wheel with both hands because this car allows me to go faster than if I was driving myself, but sometimes you have to steer or brake. And the analogy favors Claude Code here because you don't have to react in milliseconds while programming.
TL;DR: if you do the commit you are responsible for the code it contains.
Some have compared it to working with a very junior programmer. I haven't done that in a long while, but when I did, it didn't really feel like I was "offloading" much, and I could still trust even the most junior programmer to tell me whether the job was done well or not (and of any difficulties they encountered or insight they've learnt) much more than I can an agent, at least today.
Trust is something we have, for the most part, when we work with either other people or with tools. Working without (or with little) trust is something quite novel. Personally, I don't mind that an agent can't accomplish many tasks; I mind a great deal that I can't trust it to tell me whether it was able to do what I asked or not.
I don't know your current domain, but stuff like Loom requires very complex reasoning capabilities, most of which lives outside the actual codebase itself. Business code on the other hand often has a more direct mapping from idea to code, so LLMs might show more promise there.
Sure it is.
Modern ecosystem is sadly full of API:s like WPF on Windows that are both verbose and configuration heavy. Now, some people may be able to internalize xaml with little effort but not all us - and then you basically move forward iteratively, looking for code example, trying this or that … basically random walking towards something usable.
Or you use an agentic LLM and it does this peeking and poking for you, and with decades old APIs like WPF likely has enough context to do the thing you asked it to do far more competently than you could train yourself to program WPF in a few days.
Of course in the context of this example WPF was your main duty, you _would_ learn the ins and outs of it.
In quite many jobs a task like this may not infact be even among your top ten duties but you need to do it.
In these sort of situations a LLM is really nice. The worst it provides is a good first guess how to do something.
If your contex is something like radiology treatment then no, don’t use LLM!
But there are thoushands of miserable non-critical but necessary components in production for which LLM is just fine.
I'm curious about what experiences led you to that conclusion. IME, LLMs are very good at the type of logical reasoning required for most programming tasks. E.g. I only have to say something like "find the entries with the lowest X and highest Y that have a common Z from these N lists / maps / tables / files / etc." and it spits out mostly correct code instantly. I then review it and for any involved logic, rely on tests (also AI-generated) for correctness, where I find myself reviewing and tweaking the test cases much more than the business logic.
But then I do all that for all code anyway, including my own. So just starting off with a fully-fleshed out chunk of code, which typically looks like what I'd pictured in my head, is a huge load off my cognitive shoulders.
I agree that most of the time it does most simple tasks mostly right, but that's not good enough to truly "offload" my mental effort. Again, I'm not saying it's not useful, but more than working with a junior developer it's like working with a junior developer who may or may not be drunk or tired and doesn't tell you.
But mostly my point is that LLMs seem to do logical reasoning worse than other things they do better, such as generating prose or summarising a document. Of course, even then you can't trust them yet.
> But then I do all that for all code anyway, including my own
I don't, at least not constantly. I review other people's code only towards the very end of a project, and in between I trust that they tell me about any pertinent challenge or insight, precisely so that I can focus on other things unless they draw my attention to something I need to think about.
I still think that working with a coding assistant is interesting and even exciting, but the experience of not being able to trust anything, for me at least, is unlike working with another person or with a tool and doesn't yet allow me to focus on other things. Maybe with more practice I could learn to work with something I can't trust at all.
Bad news, friend.
Overall though, I think you're right. It's a lot like working with people. The things you might be missing are that you can get better at this with practice, and that once you are multiplexing multiple Claudes, you can become hyper efficient. These are things I'm looking into now.
Do I know these for a fact? Not yet. But, like any tool, I'm sure that the investment won't pay off right away.
Asking an LLM to do logic would be saying something like: "I have a row of a million light switches. They all start off. I start at the beginning and flip on every fourth one. Then I flip on every eighth one, then sixteen, and all the powers of two until I'm over a million. Now I do the same for the powers of three, then four, then five, and so on. How many light switches are on at the end? Do not use any external coding tools for this; use your own reasoning."
Note that the prompt itself is intentionally ambiguous -- a human getting this question should say "I don't understand why you started with every fourth instead of every second. Are you skipping the first integer of every power series or just when the exponent is two?"
When I asked GPT5 to do it, it didn't care about that; instead it complimented me on my "crisp statement of the problem," roughly described a similar problem, and gave a belivable but incorrect answer 270,961 .
I then asked it to write python code to simulate my question. It got the code correct, and said "If you run this, you’ll see it matches the 270,961 result I gave earlier." except, that was a hallucination.
Running the code actually produced 252711.
I guess it went with 270,961 because that was a lexically similar answer to some lexically similar problems in the training data.
And allowing python shells for both I think the randomly selected human would do worse on average.
And I also think e.g. Google's IMO model would be able to pass but I have no way to verify that.
I mean, this is a super basic python task that I could write in 2 minutes. The naiive implementation is a couple of basic for loops. I wouldn't hire a junior dev that couldn't write it.
My point here is that for someone who can program, it's easier and better to write this in python than to write it in english and have an LLM translate it to python (and LLMs themselves are incapable of logic or reasoning, so the only option is for them to translate it to real code).
"You can ask any clarifying questions first before starting on the problem."
Here's what it asked (Claude Opus, web search off so it didn't find your post):
> Looking at this problem, I want to make sure I understand the process correctly before diving into the solution. Let me clarify a few things:
> When you say "flip on every fourth one" for the powers of two, do you mean:
> We flip switches at positions 4, 8, 12, 16, 20, 24, ... (every 4th position) Then flip switches at positions 8, 16, 24, 32, 40, 48, ... (every 8th position) And so on?
> When you move to "powers of three", do you mean:
> Start with every 3rd switch (3, 6, 9, 12, ...) Then every 9th switch (9, 18, 27, 36, ...) Then every 27th switch, etc.?
> Or does "powers of three" mean we start with 3² = 9 as the first increment, similar to how we started with 2² = 4 for powers of two?
> When you say "then four, then five, and so on" - do you mean we continue this process for all integers k ≥ 2, using powers of k as our increments?
> The final state of each switch depends on whether it gets flipped an odd or even number of times total, so I want to make sure I understand the flipping pattern correctly before calculating the answer.
So my experience in working with AI is actually much more similar to working with people, except I have to correct the AI much less frequently.
I always say, AI is technology that behaves like people, and so the trick to working with it effectively is to approach it like working with a colleague, with all their specific quirks and skillsets, rather than a tool.
It can translate, but it cannot reason or calculate. The python can calculate.
Here is one recent exchange (some proprietary details redacted) with Claude Sonnet 3.7 via the Cody VSCode Extension (RIP):
---
Me: At this point, "segments" represents a list of bounding boxes that can overlap. Write a function to coalesce only those boxes that are substantially (i.e. within some tolerance) horizontally aligned along one or both edges or their centers, either: 1) overlapping completely or partially; or 2) very closely spaced like the words of a sentence should be (you can assume the threshold for spacing could be a reasonable fraction of the height of the box).
Claude: I'll create a function to coalesce horizontally aligned boxes based on your requirements. This function will identify boxes that are either overlapping or closely spaced and horizontally aligned (by top edge, bottom edge, or vertical center).
```javascript function coalesceHorizontallyAlignedSegments(segments, options = {}) { // Default options const { verticalAlignmentTolerance = 0.1, // 10% tolerance for vertical alignment horizontalSpacingThreshold = 0.5, // Max horizontal spacing as a fraction of box height overlapThreshold = 0.2 // Minimum overlap required (20% of the smaller box) } = options;
if (!segments || segments.length <= 1) {
return segments;
}
// Sort segments by x position (left to right)
const sortedSegments = [...segments].sort((a, b) => a.x - b.x);
// Track which segments have been merged
const merged = new Array(sortedSegments.length).fill(false);
const mergedSegments = [];
for (let i = 0; i < sortedSegments.length; i++) {
// Skip if this segment has already been merged
if (merged[i]) continue;
const currentSegment = sortedSegments[i];
let mergedSegment = { ...currentSegment };
merged[i] = true;
// Check for potential merges with subsequent segments
let didMerge = true;
while (didMerge) {
didMerge = false;
for (let j = 0; j < sortedSegments.length; j++) {
if (merged[j]) continue;
const nextSegment = sortedSegments[j];
// Check if horizontally aligned (top, bottom, or center)
const topAligned = Math.abs(mergedSegment.y - nextSegment.y) <=
verticalAlignmentTolerance * Math.min(mergedSegment.height, nextSegment.height);
const bottomAligned = Math.abs((mergedSegment.y + mergedSegment.height) -
(nextSegment.y + nextSegment.height)) <=
verticalAlignmentTolerance * Math.min(mergedSegment.height, nextSegment.height);
const centerAligned = Math.abs((mergedSegment.y + mergedSegment.height/2) -
(nextSegment.y + nextSegment.height/2)) <=
verticalAlignmentTolerance * Math.min(mergedSegment.height, nextSegment.height);
const isVerticallyAligned = topAligned || bottomAligned || centerAligned;
if (!isVerticallyAligned) continue;
// Check for overlap or close spacing
const mergedRight = mergedSegment.x + mergedSegment.width;
const nextLeft = nextSegment.x;
// Calculate horizontal spacing
const horizontalSpacing = nextLeft - mergedRight;
const maxAllowedSpacing = horizontalSpacingThreshold * Math.min(mergedSegment.height, nextSegment.height);
// Check for overlap
const isOverlapping = mergedRight >= nextLeft;
// Calculate overlap percentage if overlapping
let hasSignificantOverlap = false;
if (isOverlapping) {
const overlapWidth = Math.min(mergedRight, nextSegment.x + nextSegment.width) -
Math.max(mergedSegment.x, nextSegment.x);
const smallerWidth = Math.min(mergedSegment.width, nextSegment.width);
hasSignificantOverlap = overlapWidth / smallerWidth >= overlapThreshold;
}
// Merge if overlapping significantly or closely spaced
if (hasSignificantOverlap || (horizontalSpacing >= 0 && horizontalSpacing <= maxAllowedSpacing)) {
// Create a new bounding box that encompasses both segments
const newX = Math.min(mergedSegment.x, nextSegment.x);
const newY = Math.min(mergedSegment.y, nextSegment.y);
const newRight = Math.max(mergedSegment.x + mergedSegment.width,
nextSegment.x + nextSegment.width);
const newBottom = Math.max(mergedSegment.y + mergedSegment.height,
nextSegment.y + nextSegment.height);
mergedSegment = {
x: newX,
y: newY,
width: newRight - newX,
height: newBottom - newY,
// Preserve the virtual path from the leftmost segment
imagePath: mergedSegment.x <= nextSegment.x ? mergedSegment.imagePath : nextSegment.imagePath
};
merged[j] = true;
didMerge = true;
break;
}
}
}
// Add the topLeft and bottomRight properties for consistency
mergedSegment.topLeft = { x: mergedSegment.x, y: mergedSegment.y };
mergedSegment.bottomRight = {
x: mergedSegment.x + mergedSegment.width,
y: mergedSegment.y + mergedSegment.height
};
mergedSegments.push(mergedSegment);
}
return mergedSegments;This function works as follows:
1. It sorts segments from left to right to process them in reading order 2. For each segment, it looks for potential merges with other segments based on: - Vertical alignment (top edges, bottom edges, or centers within tolerance) - Either significant overlap (controlled by overlapThreshold) or - Close horizontal spacing (controlled by horizontalSpacingThreshold as a fraction of box height) 3. When segments are merged, it creates a new bounding box that encompasses both 4. It continues merging until no more merges are possible
You can integrate this function into your segmentation pipeline by adding it after the segment extraction:
```javascript function segmentImage(ctx, imageData, options = {}) { // ... existing code ...
const segments = boundingRects.map(toSegment);
// Coalesce horizontally aligned segments
const coalescedSegments = coalesceHorizontallyAlignedSegments(segments, options.coalesceOptions);
return { segments: coalescedSegments, contourTrees };Me: Do not write any code yet, but would it help if the segments were first grouped into approximate "rows" and then coalesced, rather than simply sorted by the x-coordinate?
Claude: Yes, grouping segments into approximate "rows" before coalescing would be significantly more effective than simply sorting by x-coordinate. Here's why:
1. *Better handling of multi-column layouts*: When a page has multiple columns of text or elements, sorting purely by x-coordinate would attempt to merge segments across different columns if they happen to be horizontally aligned.
2. *Respecting natural reading flow*: Text typically flows in rows, and grouping by rows first would respect this natural organization of content.
3. *More accurate merging decisions*: By first establishing which segments belong to the same "row" or line of content, we can make more informed decisions about which segments should be considered for merging.
4. *Handling of varying vertical positions*: Text lines on a webpage aren't always perfectly aligned. Pre-grouping into rows would allow us to handle slight variations in vertical positioning within what should be considered the same line.
5. *Efficiency*: By limiting the coalescing operations to segments within the same row, we reduce the number of comparisons needed.
The approach would work like this: 1. Group segments into rows based on vertical overlap or proximity 2. Within each row, sort segments by x-coordinate 3. Apply the coalescing logic only to segments within the same row
This approach would better preserve the semantic structure of the content while still merging segments that represent parts of the same logical unit (like words in a sentence).
Looking at the codebase, this approach would align well with how visual content is typically structured and would produce more meaningful segment groupings for downstream processing.
---
And then it proceeded to update the code as discussed. Sure this is not a very novel problem and it required a bit of back and forth, but look at the ratio of prompt to code. This exchange took a couple of minutes; I'd estimate it would have taken me an hour to get that code down with all edge cases handled. Look at the exposition, the quality of code, the choice to use optional parameters for tolerances, and edge-case handling.
It's very, very hard for me to not see this as reasoning. I mean, how is this not mind-blowing?
Trying to get Claude to do this without introducing a deadlock and without exiting too early and leaving valuable output in the pipe was hellish.
It's very good at some kinds of reasoning and very bad at others. There's not much it's mediocre at.
Yes, one of the terms for this phenomenon is "jagged frontier" from here:
https://www.oneusefulthing.org/p/centaurs-and-cyborgs-on-the...
This is also the main reason people have such diverging experiences and the discussion around AI is so bimodal in nature.
● Let me trace through what happens with the "Jordan Rudess" example:
1. Directory: Jordan Rudess/
2. file_rel_path would be Path("Jordan Rudess") (after removing MP3 Disk prefix)
3. If Jordan Rudess matches in path component 0, scope_path would be Path("Jordan Rudess")
4. _path_is_in_scope checks if "Jordan Rudess".startswith("Jordan Rudess") → True
This looks correct. Let me check the inference logic:
● The inference priority looks correct - path_component_match is indeed the highest priority. But I think I see the issue now. Let me look at the actual logic flow in the main organize method:
● Read(mp3_organizer_v2.py) ⎿ Read 10 lines (ctrl+r to expand)
● The flow looks right. Let me examine the actual problem more carefully. Looking back at the _apply_path_component_matching method, I think there might be an issue with when the matching happens. Let me check the logic:
● Update Todos ⎿ Check _path_is_in_scope logic for correctness Verify artist inference priority logic works with path_component_match Test and fix any remaining issues with artist propagation
● I think I see the issue now. The problem is that the current code only looks for matches in files that already have file_id3 tags, but it needs to propagate those matches to all files in the directory. However, the current implementation is still only applying matches to files that have matching candidates, not ALL files. Let me check the exact logic:
● Read(mp3_organizer_v2.py) ⎿ Read 8 lines (ctrl+r to expand)
● Actually, looking at this more carefully, the logic should work. The matched_artists dictionary contains the matches found from ANY file that had a file_id3 tag matching a path component, and then it applies that match to ALL files in the file_infos list via the loop at line 737.
Wait, let me understand the scoping issue better. Let me check what file_rel_path and scope_path would actually be in your example:
● Ah! I think I see a potential issue. The file_rel_path is calculated as the directory path, not the individual file path. So for all files in the same directory, file_rel_path will be the same. This should actually work correctly.
But let me double-check the scope matching logic. If the directory is "Jordan Rudess" and the scope_path is also "Jordan Rudess", then _path_is_in_scope should return
True.
Let me debug this by adding some debug output to see what's actually happening. But first, let me look at a potential issue: maybe the match isn't being found in the first place?
I'm not sure statements of 'aha, I see it now!' are meaningful in this context. Surely this is just the em-dash of 'issue tokens to have the user react like you're thinking'?
Only an Anthropic engineer would know for sure. I'm pretty sure that it was making multiple queries on my behalf during the chat transcript - each "Read ... mp3organizer_v2.py" is a separate network round-trip.
Sort of. You still can't get a reliable output for the same input. For example, I was toying with using ChatGPT with some Siri shortcuts on my iPhone. I do photography on the side, and finding a good time for lighting for photoshoots is a usecase I use a lot so I made a shortcut which sends my location to the API along with a prompt to get the sunset time for today, total amount of daylight, and golden hour times.
Sometimes it works, sometimes it says "I don't have specific golden hour times, but you can find those on the web" or a useless generic "Golden hour is typically 1 hour before sunset but can vary with location and season"
Doesn't feel like programming to me, as I can't get reproducible output.
I could just use the LLM to write some API calling script from some service that has that data, but then why bother with that middle man step.
I like LLMs, I think they are useful, I use them everyday but what I want is a way to get consistent, reproducible output for any given input/prompt.
For example, "write a comprehensive spec for a script that takes in the date and a location and computes when golden hour is." | "Implement this spec"
That variability is nice when you want some creativity, e.g. "write a beautiful, interactive boids simulation as a single file in html, css, and JavaScript."
Words like "beautiful" and interactive" are open to interpretation, and I've been happy with the different ways they are interpreted.
I agree and I feel that having LLM's do boilerplate type stuff is fantastic for ADD people. The dopamine hit you get making tremendous progress before you get utterly bored is nice. The thing that ADD/ADHD people are the WORST at is finishing projects. LLM will help them once the thrill of prototyping a green-field project is over.
LLMs, particularly Claude 4 and now GPT-5 are fantastic at working through these todo lists of tiny details. Perfectionism + ADHD not a fun combo, but it's way more bearable. It will only get better.
We have a huge moat in front of us of ever-more interesting tasks as LLMs race to pick up the pieces. I've never been more excited about the future of tech
Oh and also, from what I know, ADHD and perfectionism is a very common combination, I'm not sure if everyone has that but I've heard it's the case for many with ADD. Same with "standards" being extremely high for everything
Bunch of 80% projects with, as you mentioned, the interesting parts finished (sorta -- you see the line at the end of the tunnel, it's bright, just don't bother finishing the journey).
However, at the same time, there's conflict.
Consider (one of) my current projects, I did the whole back end. I had ChatGPT help me stand up a web front end for it. I am not a "web person". GUIs and what not are a REAL struggle for me because on the one hand, I don't care how things look, but, on the other, "boy that sure looks better". But getting from "functional" to "looks better" is a bottomless chasm of yak shaving, bike shedding improvements. I'm even bad at copying styles.
My initial UI was time invested getting my UI to work, ugly as it was, with guidance from ChatGPT. Which means it gave me ways to do things, but mostly I coded up the actual work -- even if it was blindly typing it in vs just raw cut and paste. I understood how things were working, what it was doing, etc.
But then, I just got tired of it, and "this needs to be Better". So, I grabbed Claude and let it have its way.
And, its better! it certainly looks better, more features. It's head and shoulders better.
Claude wrote 2-3000 lines of javascript. In, like, 45m. It was very fast, very responsive. One thing Claude knows is boiler plate JS Web stuff. And the code looks OK to me. Imperfect, but absolutely functional.
But, I have zero investment in the code. No "ownership", certainly no pride. You know that little hit you get when you get Something Right, and it Works? None of that. Its amazing, its useful, its just not mine. And that's really weird.
I've been striving to finish projects, and, yea, for me, that's really hard. There is just SO MUCH necessary to ship. AI may be able to help polish stuff up, we'll see as I move forward. If nothing else it may help gathering up lists of stuff I miss to do.
I've always much preferred figuring out how to improve or build on existing messy systems and codebases, which is certainly aided by LLMs for big refactoring type stuff, but to be successful at it requires thinking about how some component of a system is already used and the complexity of that. Lots of edge cases and nuances, people problems, relative conservativeness.
The problem with this perspective, is that when you try to offload exactly the same boring task(s), to exactly the same LLM, the results you get back are never even close to being the same. This work you're offloading via natural language prompting is not programming in any meaningful sense.
Many people don't care about this non-determinism. Some, because they don't have enough knowledge to identify, much less evaluate, the consequent problems. Others, because they're happy to deal with those problems, under the belief that they are a cost that's worth the net benefit provided by the LLM.
And there are also many people who do care about this non-determinism, and aren't willing to accept the consequent problems.
Bluntly, I don't think that anyone in group (1) can call themselves a software engineer.
I'm with you 100% on the boring stuff. It's generally good at the boring stuff *because* it's boring and well-trod.
This sounds like a wild generalization.
I am in neither of those two groups, and I’ve been finding tools like Claude Code becoming increasingly more useful over time.
Made me much more optimistic about the direction of AI development in general too. Because with each iteration and new version it isn’t getting anywhere closer to replacing me or my colleagues, but it is becoming more and more useful and helpful to my workflow.
And I am not one of those people who are into “prompt engineering” or typing novels into the AI chatbox. My entire interaction is typically short 2-3 sentences “do this and that, make sure that XYZ is ABC”, attach the files that are relevant, let it do its thing, and then manual checks/adjustments. Saves me a boatload of work tbh, as I enjoy the debugging/fixing/“getting the nuanced details right” aspect of writing code (and am pretty decent at it, I think), but absolutely dread starting from a brand new empty file.
Try aider.chat (it's in the name), but specifically start with "ask" mode then dip a toe into "architect" mode, not "code" which is where Claude Code and the "vibe" nonsense is.
Let aider.chat use Opus 4.1 or GPT-5 for thinking, with no limit on reasoning tokens and --reasoning-effort high.
> agents are a boon for extraverts and neurotypical people.
On the contrary, I think the non-vibe tools are force multipliers for those with an ability to communicate so precisely they find “extraverts and neurotypical people” confounding when attempting to specify engineering work.
I'd put both aider.chat and Claude Code in the non-vibe class if you use them Socratically.
Please stop with this kind of thing. It isn't true, it doesn't make sense and it doesn't help anyone.
So I just have to convert that conversation into an AI prompt, basically. It just kind of does the typing for the construct already in my head. The trick is to just get the words out of my head as prompt input.
That's honestly not much different than an author writing a book, for example. The story line is in their head, they just have to get it on paper. And that's really the tricky part of writing a novel as much as writing code.
I therefore don't believe this is an introvert/extrovert thing. There are plenty of book authors which are both. The tools available as AI code agents are really just an advanced form of dictation.
The thing is, they're just tools. You can choose to learn them, or not. They aren't going to make or break your career. People will do fine with and without them.
I do think it's worth learning new tools though, even if you're just a casual observer / conscientious objector -- the world is changing fast, for better or worse, and you'll be better prepared to do anything with a wider breadth of tech skill and experience than with less. And I'm not just talking about writing software for a living, you could go full Uncle Ted and be a farmer or a carpenter or a barista in the middle of nowhere, and you're going to be way better equipped to deal with logistical issues that WILL arise from the very nature of the planet hurtling towards 100% computerization. Inventory management, crop planning, point of sale, marketing, monitoring sensors on your brewery vats, whatever.
Another thought I had was that introverts often blame their deficits in sales, marketing and customer service on their introversion, but what if you could deploy an agent to either guide, perform, or prompt (the human) with some of those activities? I'd argue that it would be worth the time to kick the tires and see what's possible there.
It feels like early times still with some of these pie in the sky ideas, but just because it's not turn-key YET doesn't mean it won't be in the near future. Just food for thought!
I agree with all of your reasons but this one sticks out. Is this a big issue? Are many people refusing to use LLMs due to (I'm guessing here): perceived copyright issues, or power usage, or maybe that they think that automation is unjust?
That said, the amount of sort-of-thoughtless, I'm-just-repeating-something-I-heard-but-don't-really-understand outrage towards AI that I'm seeing appears to be increasing -- "how many bottles of water did that slop image waste??", "Clanker"-adjacent memes and commentary (include self-driving + robots in this category), people ranting about broligarchs stealing art, music, movies, books to train their models (oddly often while also performatively parroting party lines about how Spotify rips artists off), all the way to refusing to interact with people on dating apps if they have anything AI in their profiles hahaha (file "AI" alongside men holding fish in their pics, and "crypto" lol)
It's all chronically-online nonsense that may well just be perception that's artificially amplified by "the algorithm".
Me, I have no fundamental issue with any of it -- LLMs, like anything else, aren't categorically good or bad. They can be used positively and negatively. Everything we use and consume has hidden downsides and unsavory circumstances.
As an extrovert the chances I'll use an AI agent in the next year is zero. Not even a billion to one but a straight zero. I understand very well how AI works, and as such I have absolutely no trust in it for anything that isn't easy/simple/solved, which means I have virtually no use for generative AI. Search, reference, data transformation, sure. Coding? Not without verification or being able to understand the code.
I can't even trust Google Maps to give me a reliable route anymore, why would I actually believe some AI model can code? AI tools are helpers, not workers.
I'm not sure what part of programming isn't generally solved thousands of times over for most languages out there. I'm only using it for lowly web development but I can tell you that it can definitely do it at a level that surprises me. It's not just "auto-complete" it's actually able to 'think' over code I've broken or code that I want improved and give me not just one but multiple paths to make it better.
Programming LLMs will become awesome when we create more narrowly targeted LLMs rather than these "train on everything" models.
Whatever you like is probably what you should be doing right now. Nothing wrong with that.
If it doesn’t work for you that’s fine, but turning it into some tribalised over-generalization is just… why, why would you do that, who is that kind of thing useful for??
Automation productivity doesn’t remove your own agency. It frees more time for you to apply your desire for control more discerningly.
I also use it for adding features/feature polish that address user pain points but that I can't prioritize for my own manual work just yet. There are a variety of user requests which sometimes LLMs are able to get done very suddenly when I give it a shot quickly. For these tasks, it's ok to abandon & defer them if the LLM spins its wheels.
I completely disagree. Juggling several agents (and hopping from feature-to-feature) at once, is perfect for somebody with ADHD. Being an agent wrangler is great for introverts instead of having to talk to actual people.
I feel as if you need to work with these things more, as you would prefer to work, and see just how good they are.
As a neurodivergent introvert, please don't speak for the rest of us.