This sort of thing is a great demonstration of why I remain excited about AI in spite of all the hype and anti-hype. It's just fun to mess with these tools, to let them get friction out of your way. It's a revival of the feelings I had when I first started coding: "wow, I really can do anything if I can just figure out how."
Great article, thanks for sharing!
> Claude was trying to promote the startup on Hackernews without my sign off. [...] Then I posted its stuff to Hacker News and Reddit.
...I have the feeling that this kind of fun experiments is just setting up an automated firehose of shit to spray places where fellow humans congregate. And I have the feeling that it has stopped being fun a while ago for the fellow humans being sprayed.
I think it will be quite some time into the future, before AI can impersonate humans in real life. Neither hardware, nor software is there, maybe something to fool humans for a first glance maybe, but nothing that would be convincing for a real interaction.
Implemented so that if a person in your web vouches for a specific url (“this is made by a human”) you can see it in your browser.
If that isn’t exciting enough, Sam Altman (yea the one who popularized this LLM slop) will gladly sell you his WorldCoin to store your biometric data on the blockchain!
If Google wouldn't have let perfect be the enemy of good and had added PGP support to Gmail early on (even just the shittiest signatures that are automatically applied and verified), the world would be a completely different place. Scams just wouldn't exist at this scale when signing mails with a known key would be the standard.
The tech is there, now we have Matrix and XMPP and PubSub and god knows how many protocols to share keys. Even Keybase.io still kind of exists.
What is lacking is a browser ecosystem for people to use their known identities to vouch for a specific url (with smart hashing so that changing the content would invalidate the trust).
We have the technology. Someone(tm) "just" needs to build it :)
as an aside i've made it clear that just posting AI-written emoji slop PR review descriptions and letting claude code directly commit without self reviewing is unacceptable at work
People will be more than willing to say, "Claude, impersonate me and act on my behalf".
I'm now imagining a future where actual people's identities are blacklisted just like some IP addresses are dead to email, and a market develops for people to sell their identity to spammers.
As far as I can tell the owner of the original iris can later invalidate an ID that they've sold, but if you buy an ID from someone who isn't strongly technically literate you can probably extract a bunch of value from it anyway.
"Claude write a summary of the word doc I wrote about x and post it as a reply comment," is fine. I dont see why it wouldnt be. Its a good faith effort to post.
"Claude, post every 10 seconds to reddit to spam people to believe my politics is correct," isn't but that's not the case. Its not a good faith effort.
The moderation rules for 'human slop' will apply to AI too. Try spamming a well moderated reddit and see how far you get, human or AI.
1. I'm usually too emotional to write out why I feel that way instead of saying what I feel.
2. I really don't like the person (or their idea) but I don't want to get fired over it.
Claude is really great at this: "Other person said X, I think it is stupid and they're a moron for suggesting this. Explain to them why this is a terrible idea or tell me I'm being an idiot."
Sometimes it tells me I'm being an idiot, sometimes it gives me nearly copy-pasta text that I can use and agree with.
Not government owned, but even irs.gov uses it
(The fact that someone could correlate posts[0] based on writing style, as previously demonstrated on HN and used to doxx some people, makes things even more convoluted - you should think twice what you write and where.)
I grew up in... slightly rural america in the 80s-90s, we had probably a couple of dozen local BBSes the community was small enough that after a bit I just knew who everyone was OR could find out very easily.
When the internet came along in the early 90s and I started mudding and hanging out in newsgroups I liked them small where I could get to know most of the userbase, or at least most of the posing userbase. Once mega 'somewhat-anonymous' (i.e. posts tied to a username, not like 4chan madness) communities like slashdot, huge forums, etc started popping up and now with even more mega-communities like twitter and reddit. We lost something, you can now throw bombs without consequence.
I now spend most of my online time in a custom built forum with ~200 people in it that we started building in an invite only way. It's 'internally public' information who invited who. It's much easier to have a civil conversation there, though we still do get the occasional flame-out. Having a stable identity even if it's not tied to a government name is valuable for a thriving and healthy community.
A German forum I'm on allows members limited invites based on participation. The catch is, you are responsible for the people you invite. If they get in trouble, you will share a part of the punishment.
But I still can't help but grin at the thought that the bot knows that the thing to do when you've got a startup is to go put it on HN. It's almost... cute? If you give AI a VPS, of course it will eventually want to post its work on HN.
It's like when you catch your kid listening to Pink Floyd or something, and you have that little moment of triumph - "yes, he's learned something from me!"
I think the processes etc that HN have in place to deal with human-generated slop are more than adequate to deal with an influx of AI generated slop, and if something gets through then maybe it means it was good enough and it doesn't matter?
The bar is not 'oh well, it's not as bad as some, and I think maybe it's fine.'
* well crafted, human only? * Well crafted, whether human or AI? * Poorly crafted, human * well crafted, AI only * Poorly crafted, AI only * Just junk?
etc.
I think people will intuitively get a feel for when content is only AI generated. If people spend time writing a prompt that doesn't make it so wordy, and has personality, and it OK, then fine.
Also, big opportunity going to be out there for AI detected content, whether in forums, coming in inmail inboxes, on your corp file share, etc...
Spoiler: no he didn't.
But the article is interesting...
It really highlights to me the pickle we are in with AI: because we are at a historical maximum already of "worse is better" with Javascript, and the last two decades have put out a LOT of javascript, AI will work best with....
Javascript.
Now MAYBE better AI models will be able to equivalently translate Javascript to "better" languages, and MAYBE AI coding will migrate "good" libraries in obscure languages to other "better" languages...
But I don't think so. It's going to be soooo much Javascript slop for the next ten years.
I HOPE that large language models, being language models, will figure out language translation/equivalency and enable porting and movement of good concepts between programming models... but that is clearly not what is being invested in.
What's being invested in is slop generation, because the prototype sells the product.
Forums like HN, reddit, etc will need to do a better job detecting this stuff, moderator staffing will need to be upped, AI resistant captchas need to be developed, etc.
Spam will always be here in some form, and its always an arms race. That doesnt really change anything. Its always been this way.
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.
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.
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.
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.
As a neurodivergent introvert, please don't speak for the rest of us.
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.
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.
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.
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.
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.
Whatever you like is probably what you should be doing right now. Nothing wrong with that.
Please stop with this kind of thing. It isn't true, it doesn't make sense and it doesn't help anyone.
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??
https://gist.githubusercontent.com/jgbrwn/28645fcf4ac5a4176f...
Often there's as much to be learned from why it doesn't work.
I see the AI hype to be limited to a few domains.
People choosing to spend lots of money on things speculatively hoping to get a slice of whatever is cooking, even if they don't really know if it's a pie or not.
Forward looking imagining of what would change if these things get massively better.
Hyperbolic media coverage of the above two.
There are companies taking about adding AI for no other reason than they feel like that's what they should be doing, I think that counts as a weak driver of hype, but only because cumulatively, lots of companies are doing it. If anything I would consider this an outcome of hype.
Of these the only one that really affects me is AI being shoehorned into places it shouldn't
The media coverage stokes fires for and against, but I think it only changes the tone of annoyance I have to endure. They would do the same on another topic in the absence of AI. It used to be crypto,
I'm ok with people spending money that is not mine on high risk, high potential reward. It's not for me to judge how they calculate the potential risk or potential reward. It's their opinion, let them have it.
The weird thing I find is the complaints about AI hype dominating. I have read so many pieces where the main thrust of their argument is about the dominance of fringe viewpoints that I very rarely encounter. Frequently they take the stance that anyone imagining how the world might change from any particular form of AI as a claim that that form is inevitable and usually imminent. I don't see people making those claims.
I see people talking about what they tried, what they can do, and what they can't do. Everything they can't do is then held up by others as if it were a trophy and proof of some catestrophic weakness.
Just try stuff, have fun, if that doesn't interest you, go do something else. Tell us about what you are doing. You don't need to tell us that you aren't doing this particular thing, and why. If you find something interesting tell us about that, maybe we will too.
I've tried to explain it to other devs that it's like dumping out a 10000 piece jigsaw puzzle and trying to put it together again.
it's just fun.
For some definitions of fun… :)
When those tools created some awful, complex and slow output, only the people who knew HTML could understand why it wasn't working and fix things.
Vibe coding is in a similar place. It demos really well. It can be powerful and allows for quick iteration on ideas. It works, most of the time. Vibe coding can produce some really terrible code that is not well architected and difficult to maintain. It can introduce basic logic errors that are not easily corrected through multiple prompts back to the system.
I don't know if they will ever be capable of creating production quality systems on par with what senior engineers produce or if they will only get incrementally better and remain best for prototypes and testing ideas.
Except this time it’s “if I can just figure out how and pay for the Claude API usage”.
This is one of the sadder things about AI usage getting more standard that I haven’t seen discussed much—-the barrier to entry is now monetary rather than just knowledge-based, which will make it _much_ harder for young people with no money to pick up.
Yes, they can still write code the manual way, but if the norm is to use AI I suspect that beginner’s guides, tutorials, etc. will become less common.
A kid interested in trying stuff can use Qwen Coder for free [1].
If the kid's school has Apple Silicon Macs (or iPads), this fall, each one of them will have Apple's 3 billion parameter Foundation Models available to them for free [2].
Swift Playground [3] is a free download; Apple has an entire curriculum for schools. I would expect an upgrade to incorporate access to the on-board LLM
[1]: https://openrouter.ai/qwen/qwen3-coder:free
It is a real question. It all depends on whether the AI future is linear or exponential.
There have always been costs and barriers for the cutting edge.
Cost of access is absolutely a problem in tech.
The problem can certainly be multi-faceted though.
A bigger question for me is "Does this actually increase my productivity?" The jury is still out on that - I've found that you really need to babysit the algorithm and apply your CS knowledge, and you also have to be very clear about what you're going to tell it later, don't let it make bad assumptions, and in many cases spell out the algorithm in detail. But it seems to be very good at looking up API details, writing the actual code, and debugging (if you guide it properly), all things that take a non-trivial amount of tedium in everyday programming.
I don't see my 7-year-old paying $5 for each hour he wants to program (and no way in hell would I give him my credit card), but I could easily envision paying $20/month for a Claude subscription and letting him use it. We pay more than that for Netflix & Disney+.
However chatgpt or gemini free tier is more than enough for a kid to figure out how python works and build some simple software. While I have the Gemini subscription I only got it because my family drive storage was nearly full. I could've probably got by with ChatGPT free to just stop using stackoverflow.
Not everyone was privileged, some of us were just lucky.
Wow! 12-year-old me was noodling around on a computer that my dad brought home from work because it would have otherwise ended up in landfill. We had very little money for computers back then, and I was thrilled when my parents gave me a budget to buy parts to build my own from scratch when I was about to go off to college (I'd saved up a bit myself, but not nearly enough).
I think your experience is pretty privileged, and not at all common.
Information on programming also wasn't as readily available as it is now. I used to go the book stores and use pencil and paper and copy out solutions since $50+ for a book was way more money than I could spend.
Everything today is crazy inexpensive for the value.
That sounds dismissive, and maybe it is, but I'm being serious here. What is the point of coming here and saying "when I was 12, my parents had less money than yours did when you were 12?" Privilege is relative, "common" is relative, and constantly being dragged into oppression Olympics of who has or had things slightly worse is exhausting and not conducive to conversation.
Better keep in mind that someone here almost certainly had it even worse than you when they were in elementary school, lest you go a few seconds without acknowledging your privileged upbringing, for some reason, in a conversation where it bears absolutely no relation to anything.
We were quite possibly less privileged than you were, if your dad brought a computer home from work. I grew up with a teacher and a househusband for parents; single-income, and that income made about 1/3 of what engineers or other computer professionals made. My kid had more passport stamps at age 2 than I did at age 18.
It was $2500 because it was a Mac LC, and it was a Mac LC because that could take an Apple 2E card and run both Mac and Apple software, and that was important because my mom was a teacher and had a large library of educational software at school that she could take home. Recall that in those days, software was sold in retail stores (no Internet), and cost $50-100 for kiddie stuff, and like $400 for productivity and compilers. 25 titles and the cost of the computer paid for itself in free software. I think we used about that.
It's a matter of priorities. My parents always prioritized my education: they bought a computer, and whatever software didn't come from my mom's workplace, and any books I wanted, and paid for my college education in full. We didn't have a whole lot other than that: we didn't take a lot of vacations or plane trips (and a single plane trip would cost more than that $2500 in those days), ran our cars into the ground (my mom owned 2 cars over my entire childhood), wore hand-me-downs.
My online upbringing was very much of the RTFM variety, and I am convinced that was and is a good method to learn. It’s not like the grumpy graybeards were cruel, they just didn’t want to waste their time answering the same “how do I…” questions from noobs. If you explained what you were experiencing, what you had read, and what you had tried, they were more than happy to help out. I don’t think that’s an unreasonable approach.
[0]: https://4-h.org/
I don't know for sure whether it's worth it yet. Further experimentation is needed, as well as giving it an honest shot and trying to learn the nuances of the tool. But the way I look at it - if this actually is a future career path, the net present value of its payoff is measured in the millions of dollars. It's worth spending ~$20 and a few nights of my time to figure that out, because the odds can be pretty damn low and still have the expected value pencil out. It's sorta like spending $200 on 1/4 of a Bitcoin in 2013 because I was curious about the technology - I fully expected it to be throwing money down the toilet, but it ended up being quite worth it. (I wish I'd had the same mindset when I could've bought into the Ethereum ICO at a penny or so an ETH.)
I am retired and not wanting to spend a ton of money getting locked long term into using an expensive tool like Claude Code is a real thing. It is also more fun to sample different services. Don’t laugh but I am paying Ollama $20/month just to run gpt-oss-120b very fast on their (probably leased) hardware with good web search tooling. Is it worth $20/month? Perhaps not but I enjoy it.
I also like cheap APIs: Gemini 2.5-flash, pro when needed, Kimi K2, open models on Groq, etc.
The AI, meaning LLM, infrastructure picture is very blurred because of so many companies running at a loss - which I think should be illegal because long term I think it is misleading consumers.
In a sense it is illegal, even though the whole tech scene has been doing it for decades, price dumping is an illegal practice and I still don't understand why it has never been considered as such with tech.
Most startups with VC investors work only through price dumping, most unicorns came to be from this bullshit practice...
"Dumping" in international trade is somewhat similar but the reasons that is illegal are very different: https://en.m.wikipedia.org/wiki/Dumping_(pricing_policy)
Pricing at a loss by VC funded companies is great for consumers. It rarely is at a loss though - they look at the lifetime value.
Pricing at a loss by big tech could be viewed as anticompetitive. Personally I like that Gemini keeps OpenAI prices lower but one could argue it has stopped OpenAIs growth.
Google uses Google hardware, which costs them 1/10 what nvidia hardware costs everyone else.
It's great for consumers only in the short term, the strategy to drive out competition that are not as well-funded has only one goal: to remove competition in the long-term to drive up prices at your will since most competitors won't have the chance to exist.
Edit: yes, technically dumping is a specific type of predatory pricing, so swap "price dumping" on my first comment to "predatory pricing" instead.
In fact driving out competition is rarely the goal at all.
Instead the goal is usually to reduce the barrier to people trying the thing - especially when it is a developer API which you hope developers will incorporate into their product.
Driving out competition is definitely a goal, the further you can snowball that makes your company a much more attractive investment since your competition will be bleeding money, attrition is definitely used as a tactic by VCs when a startup gets traction. Hell, it's one of the arguments they use to run further rounds of investments to others "this startup is very well capitalised and the competition has 1/10th of their funds, investing elsewhere is a losing proposition".
> Instead the goal is usually to reduce the barrier to people trying the thing - especially when it is a developer API which you hope developers will incorporate into their product.
I thought we were talking about unicorns such as Uber, AirBnb, etc., not some dev startup packaging APIs to serve other startups which is a whole other incestuous industry.
Or think it this way: It's easy to get base level free LLM (Toyota) but one should not expect free top of the shelf (Porsche).
Only in tech are we shocked when things cost money. I don't know that any other industry expects such a reality.
The knowledge check will also slowly transfer towards the borders of fast iteration and not necessarily knowledge depth. The end goal is to make a commodity out of the myth of the 10x dev, and take more leverage away from the devs.
[1]: https://www.notebookcheck.net/Powerful-Zen-6-Medusa-Halo-iGP...
> Uh oh. We're getting blocked again and I've heard Anthropic has a reputation for shutting down even paid accounts with very few or no warnings.
I'm in the slack community where the author shared their experiment with the autonomous startup and what stuck out to me is that they stopped the experiment out of fear of being suspended.
Something that is fun should not go hand-in-hand with fear of being cut off!
I’m personally hoping for a future with free local LLMs, and I do hope the prices go down. I also recognize I can do things a little cheaper each year with the API.
However it is far from a guaranteed which direction we’re heading in, and I don’t think we’re on track to get close to removing the monetary barrier anytime soon.
The spend prices most of the developing world out -- an programmer earning $10k per year can't pay for a $200/month Claude Max subscription..
And it does better than $6k-$10k programmers in Africa, India, and Asia.
It's the mainframe era all over again, where access to computing is gated by $$$.
No, but a computer earning $10k per year can probably afford a $200 used ThinkPad, install Linux on it, build code that helps someone, rent a cheap server from a good cloud provider, advertise their new SaaS on HN, and have it start pulling in enough revenue to pay for a $200 Claude Max subscription.
> It's the mainframe era all over again, where access to computing is gated by $$$.
It's still the internet era, where access to $$$ is gated by computing skill :)
LLM code still needs to be reviewed by actual thinking humans.
Considering opportunity cost, a young person paying $20 or $100 per month to Claude API access is way cheaper than a young person spending a couple of years to learn to code, and some months coding something the AI can spit in 10 minutes.
AI coding will still create generations that even programming graduates know fuck all about how to code, and are also bad at reasoning about the AI produced code they depend on or thinking systematically (and that wont be getting any singularity to bail them out), but that's beside the point.
People need to take time to get good at /something/. It's probably best to work with the systems we have and find the edge where things get hard, and then explore from there. It's partly about building knowledge, but also about gumption and getting some familiarity with how things work.
My introduction to programming was through my dad's outdated PC and an Arduino, and that put me on par with the best funded.
Agreed. And on the one hand you have those who pay an AI to produce a lot of code, and on the other hand you have those who have to review that code. I already regularly review code that has "strange" issues, and when I say "why does it do this?" the answer is "the AI did it".
Of course, one can pay for the AI and then review and refactor the code to make it good, but my experience is that most don't.
If the code becomes a mess and fixing anything becomes slower… well who cares I'm paid per hour not per task done.
I don’t think it is sad at all. There are barriers to all aspects of life, life is not fair and at least in our lifetimes will never be. The best anyone can do is to help those around them and not get caught up the slog of the bad things happening in the world.
It was common to have charity drives to get computers into schools, for example, but it's much harder to see people donating money for tokens for poor people.
Previous-generation equipment can be donated, and can still spark an interest in computing and programming. Whereas you literally now can't even use ChatGPT-4.
When the iPhone came out, not everyone had a smartphone. Now 90% of the US has a smartphone, and many of these smartphones run generative local models.
At some point you just have to accept that yes things are easier if you have a little bit of spending money for things. That's not "sad" it's a basic fact of life.
I am not saying, "It's harder to convince other people to pay for this for me".
I am saying, "It is harder for me to pay for this for someone else".
But it's certainly not any harder for you to donate this money to someone because they want to spend that money on tokens instead of a computer, for example.
Though, in a sense, I am donating tokens. I run an LLM box at my apartment, and I let some people in my community have a free account through my hosted Open WebUI.
I don't know that there's much we can do about that potentially becoming the new normal in the future, but it bums me out.
Also, running models locally requires good hardware to get acceptable performance. It's still a large barrier to entry.
I still carry that in my day job which I _think_ helps me write better code - even in unconstrained systems, thinking in terms of memory and instruction efficiency can still help make better/faster code.
Claude Code wrapper to run any models. Even local ones.
I'd probably be toiling away in a less productive industry if I hadn't been able to easily download Python and start learning it for free.
I think this is the main sentiment I can't wrap my head around. Using Claude Code or Cursor has been entirely a mind-numbingly tedious experience to me (even when it's been useful.) It's often faster, but 80% of the time is spent just sitting there waiting for it to finish working, and I'm not proud of the result because I didn't do anything except come up with the idea and figure out how to describe it well. It just ends up feeling like the coding equivalent of...like...copying down answers to cheat on a test. Not in the sense that it feels gross and wrong and immoral, but in the sense that it's unsatisfying and unfulfilling and I don't feel any pride in the work I've done.
For things where I just want something that does something I need as quickly as possible, sure, I wasn't going to care either way, but personal projects are where I find myself least wanting to vibe code anything. It feels like hiring someone else to do my hobbies for me.
In fact, I now prefer to use a purely chat window to plan the overall direction and let LLM provide a few different architectural ideas, rather than asking LLM to write a lot of code whose detail I have no idea about.
But it's far from perfect. Really difficult things/big projects are nearly impossible. Even if you break it down into hundred small tasks.
I've tried to make it port an existing, big codebase from one language to another. So it has all of the original codebase in one folder, and a new project in another folder. No matter how much guidance you give it, or how clear you make your todos, it will not work.
It simply forgets code exists during a port. It will port part of a function and ignore the rest, it will scan a whole file into context and then forget that a different codepath exists.
I would never rely on it for a 1:1 mapping of large features/code transformations. Small stuff sure, but beyond say a few large files it will miss things and you will be scratching your head for why it's not working.
How much of this is buildings versus recalling tutorials in the dataset. For every vibe coded project with 20 lines of requirements, I have a model with 20 different fields all with unique semantic meanings. In focused areas, AI has been okay. But I have yet to see Claude or any model build and scale a code base with the same mindset.
"I wrote this entire article in the Claude Code interactive window. The TUI flash (which I've read is a problem with the underlying library that's hard to fix) is really annoying, but it's a really nice writing flow to type stream of consciousness stuff into an editor, mixing text I want in the article, and instructions to Claude, and having it fix up the typos, do the formatting, and build the UX on the fly.
Nearly every word, choice of phrase, and the overall structure is still manually written by me, a human. I'm still on the fence about whether I'm just stuck in the old way by preferring to hand-craft my words, or if models are generally not good at writing.
"
Either he's lying, or you're wrong.
Agree on the structure part. I mostly read it as a piece from someone who's having fun with the tool. Not a structured article for future generations.
I thought the article was a satire after I read this ... but it wasn't!
> If you're from infosec, you might want to stop reading now — the rest of this article isn't going to make you any happier. Keep your medication close at hand if you decide to continue...
Still not convinced it is not satire.
So now I use a docker compose setup where I install Claude and run it in a container. I map source code volumes into the container. It uses a different container with dnsmasq with an allowlist.
I initially wanted to do HTTP proxying instead of DNS filtering since it would be more secure, but it was quite hard to set it up satisfactorily.
Running CLI programs with the dangerous full permissions is a lot more comfortable and fast, so I'm quite satisfied.
The author didn't do anything actually useful or impactful, they played around with a toy and mimicked a portion of what it's like to spin up pet projects as a developer.
But hey, it could be that this says something after all. The first big public usages of AI were toys and vastly performed as a sideshow attraction for amused netizens. Maybe we haven't come very far at all, in comparison to the resources spent. It seems like all of the truly impressive and useful applications of this technology are still in specialized private sector work.
However, I disagree that LLMs are anywhere near as good as what's described here for most things I've worked with.
So far, I'm pretty impressed with Cursor as a toy. It's not a usable tool for me, though. I haven't used Claude a ton, though I've seen co-workers use it quite a bit. Maybe I'm just not embracing the full "vibe coding" thing enough and not allowing AI agents to fully run wild.
I will concede that Claude and Cursor have gotten quite good at frontend web development generation. I don't doubt that there are a lot of tasks where they make sense.
However, I still have yet to see a _single_ example of any of these tools working for my domain. Every single case, even when the folks who are trumpeting the tools internally run the prompting/etc, results in catastrophic failure.
The ones people trumpet internally are cases where folks can't be bothered to learn the libraries they're working with.
The real issue is that people who aren't deeply familiar with the domain don't notice the problems with the changes LLMs make. They _seem_ reasonable. Essentially by definition.
Despite this, we are being nearly forced to use AI tooling on critical production scientific computing code. I have been told I should never be editing code directly and been told I must use AI tooling by various higher level execs and managers. Doing so is 10x to 100x slower than making changes directly. I don't have boilerplate. I do care about knowing what things do because I need to communicate that to customers and predict how changes to parameters will affect output.
I keep hearing things described as an "overactive intern", but I've never seen an intern this bad, and I've seen a _lot_ of interns. Interns don't make 1000 line changes that wreck core parts of the codebase despite being told to leave that part alone. Interns are willing to validate the underlying mathematical approximations to the physics and are capable of accurately reasoning about how different approximations will affect the output. Interns understand what the result of the pipeline will be used for and can communicate that in simple terms or more complex terms to customers. (You'd think this is what LLMs would be good at, but holy crap do they hallucinate when working with scientific terminology and jargon.)
Interns have PhDs (or in some cases, are still in grad school, but close to completion). They just don't have much software engineering experience yet. Maybe that's the ideal customer base for some of these LLM/AI code generation strategies, but those tools seem especially bad in the scientific computing domain.
My bottleneck isn't how fast I can type. My bottleneck is explaining to a customer how our data processing will affect their analysis.
(To our CEO) - Stop forcing us to use the wrong tools for our jobs.
(To the rest of the world) - Maybe I'm wrong and just being a luddite, but I haven't seem results that live up to the hype yet, especially within the scientific computing world.
The last task I tried to get an LLM to do was a fairly straightforward refactor of some of our C# web controllers - just adding a CancellationToken to the controller method signature whenever the underlying services could accept one. It struggled so badly with that task that I eventually gave up and just did it by hand.
The widely cited study that shows LLMs slow things down by 20% or so very much coheres with my experience, which is generally: fight with the LLM, give up, do it by hand.
Wow, this is really extreme. We certainly got to this point faster than I expected.
I use AI, and for some things its great. But I'm feeling like they want us to use the "blunt instrument" that is AI when sometimes a smaller, more fine grained tool/just handcrafting code for accuracy at least for me is quicker and more appropriate. The autonomy window as I recently heard it expressed.
(Sure, I could let them use my credentials but that isn’t really legit/fair use.)
Do the right thing, sign up for an API account and put some credits on there...
(and keep topping up those credits ;-)
I'm planning to run a local model on a $149 mini-pc and host it for the world from my bedroom. You can read a bit more about my thinking below.
https://joeldare.com/my_plan_to_build_an_ai_chat_bot_in_my_b...
These hosted models are better but it feels like the gap is closing and I hope it continues to close.
And of course, not the same, but Aider still exists and is still a great tool for AI dev.
It's interesting how everyone is suddenly OK with vendor lock-in, quite a change from years past!
Claude code is completely closed source and even DMCA’d people reverse engineering it.
https://techcrunch.com/2025/04/25/anthropic-sent-a-takedown-...
There are plenty of alternatives for other models like opencode et al, and you can always just set ANTHROPIC_BASE_URL with claude code to have it use another provider. I don't see why they need to do anything in addition to that.
My only request would be for claude code to be a bit more open, less obfuscated and to accept PRs - but I understand the unwillingness of also wanting to manage what would be a very popular open source project.
I think i'm done with this community in the age of vibe coding. The line between satire, venture capitalism, business idea guys and sane tech enthusiasts is getting too blurry.
Yes it's easy now so its by definition no longer impressive, but that in itself is impressive if you can correctly remember or imagine what your reaction _would_ have been 6 months ago.
Up to a point these have been probability machines. There's probably a lot of code that does certain likely things. An almost astonishing amount doing the same things, in fact. As such, perhaps we shouldn't be surprised or impressed by the stochastic parrot aspect any more than we're impressed by 80% of such sites being copy pasta from Stack Overflow a few years ago.
However, what we perhaps didn't expect is that on the margins of the mass probability space, there are any number of less common things, yet still enough of those in aggregate that these tools can guess well how to do those things too, even things that we might not be able to search for. Same reason Perplexity has a business model when Google or DDG exist.
And now, recently, many didn't expect one might be able to simulate a tiny "society of mind" made of "agents" out of these parrots, a tiny society that's proving actually useful.
Parrots themselves still impress me, but a society of them making plans at our beck and call? That can keep us all peeking, pecking, and poking for a while yet.
// given enough time and typewriters, who wins: a million monkeys, a society of parrots, or six hobbits?
Buuut for some people it just clicks and it becomes their chore to go find trash in the beach everyday and the occasional nickel or broken bracelet they feel the need to tell people and show it off.
Using coding agent is great btw, but at least learn how to double check their work cuz they are also quite terrible.
Which makes me feel early adopters pay with their time. I'm pretty sure the agents will be much better with time, but this time is not exactly now, with endless dances around their existing limitations. Claude Code is fun to experiment with but to use it in production I'd give it another couple of years (assuming they will focus on code stability ans reducing its natural optimism as it happily reports "Phase 2.1.1 has been successfully with some minor errors with API tests failing only 54.3% of the time").
It's so hit and miss in Rust too. When I ask it for help with a bug it usually tries a few things then tries to just delete or comment out the buggy code. Another thing it does is to replace the buggy code with a manual return statement with a comment saying "Returning a manual response for now". It'll then do a cargo build, proclaim that there are no errors and call it a day. If you don't check what it's doing it would appear it has fixed the bug.
When I give it very specific instructions for implementation it regularly adds static code with comments like "this is where the functionality for X will be implemented. We'll use X for now". It does a cargo build then announces all of its achievements with a bunch of emojis despite having not implemented any of the logic that I asked it to.
Really, any coding agent our shop didn't write itself, though in those cases the smiting might be less theatrical than if you literally ran a yolo-mode agent on a prod server.
> 1) Have faith (always run it with 'dangerously skip permissions', even on important resources like your production server and your main dev machine. If you're from infosec, you might want to stop reading now—the rest of this article isn't going to make you any happier. Keep your medication close at hand if you decide to continue).
Other people's blasé risk profile -- or worse, willful denial of risk -- is indeed our problem. Why?
1. Externalities, including but not limited to: security breaches, service abuse, resource depletion, and (repeat after me -- even if you only think the probability is 0.01%, such things do happen) letting a rogue AI get out of the box. *
2. Social contagion. Even if one person did think about the risks and deem them acceptable, other people all too often will just blindly copy the bottom-line result. We are only slightly evolved apes after all.
Ultimately, this is about probabilities. How many people actually take the fifteen minutes to thoughtfully build an attack tree? Or even one minute to listen to that voice in their head that says "yeah, I probably should think about this weird feeling I have ... ... maybe my subconscious mind is trying to tell me something ... maybe there is indeed a rational basis for my discomfort ... maybe there is a reason why people are warning me about this."
Remember, this isn't only about "your freedom" or "your appetite for risk" or some principle of your political philosophy that says no one should tell you what to do. What you do can affect other people, so you need to own that. Even if you don't care what other people think, that won't stop a backlash.
But I think I'm getting to the point where "If I'd let an intern/junior dev have access while I'm watching then I'm probably OK with Claude having it too"
The thing that annoys me about a lot of infosec people is that they have all of these opinions about bad practice that are removed from the actual 'what's the worst that could happen here' impact/risk factor.
I'm not running lfg on a control tower that's landing boeing 737s, but for a simple non-critical CRUD app? Probably the tradeoff is worth it.
Back when I worked at an F500 it was normal practice to give early-stage developers access to a "research" environment where our normal security policies were not applied. (Of course the flipside was that that "research" environment didn't have any access to confidential data etc., but it was a "prod" environment for most purposes)
Maybe my wrapper project is interesting for you? https://github.com/release-engineers/agent-sandbox It's to keep Claude Code containerized with a copy of the workspace and a firewall/proxy so it can only access certain sites. With my workflow I don't really risk much, and the "output" is a .patch file I can inspect before I git apply it.
https://github.com/anthropics/claude-code-security-review
The new command is something like /security-review and should be in the loop before any PR or commit especially for this type of web-facing app, which Claude Code makes easy.
This prompt will make Claude's code generally beat not just intern code, but probably most devs' code, for security mindedness:
https://raw.githubusercontent.com/anthropics/claude-code-sec...
The false positives judge shown here is particularly well done.
// Beyond that, run tools such as Kusari or Snyk. It's unlikely most shops have security engineers as qualified as these focused tools are becoming.
I have been kinda wondering if there's something that just isn't as good between the CLI and model because the Gemini CLI has been a mostly frustrating experience - and it's kept me from wanting to pay for Claude because I don't want to pay money for the same frustrating experience. But maybe I should try Claude and see.
The biggest pain point I've had is that both tools will try to guess the API of a crate instead of referencing the documentation. I've tried adding an MCP for this but have had mixed results.
And yes, when they guess APIs, it's highly annoying.
- Repeat more than 20 times the same response to my prompt rejecting its proposed changes; I just kept prompting to see how far it would go before doing something different. Claude Code would quickly guess there is something wrong and try something else or ask what I'm getting at
- Continually refer to outdated versions of files, even after I've told to re-read the files
- Refer to files in a different session on a different machine that have no relevance to what I'm currently doing, presumably simply because I logged in with the same account.
- Randomly crash or enter infinite loops, sometimes soon after starting
- Refuse to read files in a sibling or parent folder
- Fail to understand simple request.
- Propose empty changes
Claude Code is just far better. I only use Gemini CLI for the simplest of tasks
The future is vibe coding but what some people don’t yet appreciate what that vibe is, which is a Pachinko machine permanently inserted between the user and the computer. It’s wild to think that anybody got anything done without the thrill of feeding quarters into the computer and seeing if the ball lands on “post on Reddit” or “delete database”
I’ve noticed a new genre of AI-hype posts that don’t attempt to build anything novel, just talk about how nice and easy building novel things has become with AI.
The obvious contradiction being that if it was really so easy their posts would actually be about the cool things they built instead of just saying what they “can” do.
I wouldn’t classify this article as one since the author does actually create something of this, but LinkedIn is absolutely full of that genre of post right now.
Presumably, they are all startups in stealth mode. But in a few months, prepare to be blown away.
FYI, this can be shortened to:
IS_SANDBOX=1 claude --dangerously-skip-permissions
> I asked Claude to rename all the files and I could go do something else while it churned away, reading the files and figuring out the correct names.
It's got infinite patience for performing tedious tasks manually and will gladly eat up all your tokens. When I see it doing something like this manually, I stop it and tell it to write a program to do the thing I want. e.g. I needed to change the shape of about 100 JSON files the other day and it wanted to go through them one-by-one. I stopped it after the third file, told it to write a script to import the old shape and write out the new shape, and 30 seconds later it was done. I also had it write me a script to... rename my stupidly named bank statements. :-)
export VAR=foo && bar is dangerous because it stays set.
env IS_SANDBOX=1 claude --dangerously-skip-permissions
This is so funny. Thank you for sharing :)
Repo: https://github.com/sixhobbits/hn-comment-ranker
I need to modify this to work with local models, though. But this does illustrate the article's point -- we both had an idea, but only one person actually went ahead and did it, because they're more familiar with agentic coding than me.
[1] Oh. I think I understand why. /lh
Are there internal guardrails within Claude Code to prevent such incidents?
rm -rf, drop database, etc?
A couple of weeks ago I asked it to "clean up" instead of the word I usually use and it ended up deleting both my production and dev databases (a little bit my fault too -- I thought it deleted the dev database so I asked it to copy over from production, but it had deleted the production database and so it then copied production back to dev, leaving me with no data in either; I was also able to reconstruct my content from a ETL export I had handy).
This was after the replit production db database wipe-out story that had gone viral (which was different, that dev was pushing things on purpose). I have no doubt it's pretty easy to do something similar in Claude Code, especially as Replit uses Claude models.
Anyway, I'm still working on things in Replit and having a very good time. I have a bunch of personal purpose-built utilities that have changed my daily tech life in significant ways. What vibe coding does allow me to do is grind on "n" of unrelated projects in mini-sprints. There is personal, intellectual, and project cost to this context switching, but I'm exploring some projects I've had on my lists for a long time, and I'm also building my base replit.md requirements to match my own project tendencies.
I vibe coded a couple of things that I think could be interesting to a broader userbase, but I've stepped back and re-implemented some of the back-end things to a more specific, higher-end vibe coded environment standard. I've also re-started a few projects from scratch with my evolved replit.md... I built an alpha, saw some issues, upgraded my instructions, built it again as a beta, saw some issues... working on a beta+ version.
I'm finding the process to be valuable. I think this will be something I commit to commercially, but I'm also willing to be patient to see what each of the next few months brings in terms of upgraded maturity and improved devops.
I throw their results at each other, get them to debug and review each others work.
Often a get all three to write the code for a given need and then ask all three to review all three answers to find the best solution.
If I’m building something sophisticated there might be 50 cycles of three way code review until they are all agreed that there no critical problems.
There’s no way I could do without all three at the same time it’s essential.
I'm surprised it didn't get to the point of blackmailing the author to give it more resources and keep itself running.
The problem is that whatever consequences come of it won’t affect just them. You don’t really have any way of knowing if any service you use or depend on has developers running LLMs in production. One day not too far off in the future, people who don’t even like or use LLMs will be bitten hard by those who do.
It absolutely boggles my mind how anybody thinks that this is Ok?
Unless you are in North Korea, of course.
When the AI company is "policing" your agent by requiring a "human in the loop", it's just CYA (cover your ass) for the AI company.
If your agent goes off and does something illegal, the AI company would be liable unless they have some legal deniability. By requiring you the human account owner to sign-off on what your agent is doing, you become liable for any crimes your agent commits on your behalf. I haven't read their TOS but I can guarantee there is some clause like this in there.
You are still completely free to commit crimes with your agent and suffer whatever legal consequences follow!! You just have to be clear that you intentionally wanted those actions to occur which resulted in the crime. If you repeatedly allow your agents to take actions that could potentially be criminal without any human-in-the-loop, they're going to ban you because it exposes themselves to potential criminal charges.
system_instructions = """You will generate an image. The image will be used as the background of a poster, so keep it muted and not too detailed so text can still easily be seen on top. The actual poster elements like margin etc will be handled separately so just generate a normal image that works well in A4 ratio and that works well as a background."""
full_prompt = f"{system_instructions}\n\nGenerate a background image for an A4 poster with the following description: {prompt}"
openai_request = {
'model': 'gpt-4.1-mini',
'input': full_prompt,
'tools': [{
'type': 'image_generation',
'size': '1024x1536',
'quality': 'medium'
}]
}
# Make request to OpenAI
response_data = self.call_openai_api('/v1/responses', openai_request)I'm exaggerating of ourse, and I hear what you're saying, but I'd rather hire someone who is really really good at squeezing the most out of current day AI (read: not vibe coding slop) than someone who can do the work manually without assistance or fizz buzz on a whiteboard.
There is still a place for someone who is going to rewrite your inner-loops with hand-tuned assembly, but most coding is about delivering on functional requirement. And using tools to do this, AI or not, tend to be the prudent path in many if not most cases.
You don't collaborate on compiled code. They are artifacts. But you're collaborating on source code, so whatever you write, someone else (or you in the future) will need to understand it and alter it. That's what the whole maintainability, testability,... is about. And that's why code is a liability, because it takes times for someone else to understand it. So the less you write, the better it is (there's some tradeoffs about complexity).
And again, we're at a point in time where we do collaborate on the source code artifacts. But maybe we won't in the future. It assumes that we see AI progress, I can see a world where asking questions of the AI about the code is better than 99% of developers. There will be the John Carmack's of the world though who know better than the AI, but the common case is that we eventually move away from looking at code directly. But this does rely on continued progress that we may not get.
One small example was a coworker that generated random numbers with AI using `dd count=30 if=/dev/urandom | tr -c "[a-z][A-Z]" | base64 | head -c20` instead of just `head -c20 /dev/urandom | base64`. I didn't actually know `dd` beyond that it's used for writing to usb-sticks, but I suddenly became really unsure if I was missing something and needing to double check the documentation. All that to say that I think if you vibe-code, you really need to know what you're generating and to keep in mind that other will need to be able to read and understand what you've written.
and the reason for you to do that would be to punish the remaining bits of competence in the name of "the current thing"? What's your strategy?
I say this as someone who would definitely be far less productive without Google, LSP, or Claude Code.
Not the point at all, but I have found it quite common among younger professional engineers to not know SQL at all. A combination of specialization (e.g. only work on microservices that do not directly touch a database) and NoSQL has made the skill of SQL more obscure than I would have thought possible as recently as 5 years ago.
probably why people think rails is slow. our integration partners and our customers are constantly amazed by how fast and efficient our system is. The secret is I know how to write a damn query. you can push a lot of logic that would otherwise be done in the api layer into a query. if done properly with the right indexes, its going to be WAY faster than pulling the data into the api server and doing clumsy data transformations there.
- relative speeds of programming languages (https://github.com/niklas-heer/speed-comparison)
- database indexing (https://stackoverflow.com/questions/1108/how-does-database-i...)
- numbers everyone should know (https://news.ycombinator.com/item?id=39658138)
And note that databases are generally written in C.
I wasn't trying to argue that ruby is slow (it objectively is). I was arguing that its slowness is irrelevant for most webapps because you should be offloading most of the load to your database with efficient queries.
FROM Users
WHERE Type = 'Foo'
SELECT id, name
You probably have the reverse problem, it doesn't fit your mental model which is in fact the right logical model.
It gets even worse when you add LIMIT/TOP or GROUP BY. SQL is great in a lot of ways, but logically not very consistent. And UPDATE now I think about it, in SQL Server you get this bizarreness:
UPDATE u
SET u.Type = 'Bar'
FROM Users u
JOIN Company c on u.companyId = c.id
WHERE c.name = 'Baz'The semantics of SQL and a standard programming language are quite different as they are based on different computing/data model.
I can't have explained myself well, I find the SQL way "normal" even though it's logically/semantically a bit silly.
Because that's how I learnt.
My point was, if you learnt on ORMs, the SQL way must be jarring.
BUT
ecto isnt' an orm. its a sql dsl and it take a lot of pain out of writing your sql while being very easy to map what you're writing to teh output dsl
so instead of
``` select Users.id, count(posts.id) as posts_count from Users left join Posts on Posts.user_id = Users.id group by users.id ```
you can write ``` from(u in User) |> join(:left, [u], p in Post, on: u.id = p.user_id, as: :posts) |> select([u, posts: p], %{ id: u.ud, posts_count: count(p.id) }) |> group_by([u], u.id)
```
the |> you see here is a pipe operator. I've effectively decomposed the large block query into a series of function calls.
you can assign subqueries as separate values and join into those as well. it doesn't try to change sql. it just makes it vastly more ergonomic to write
db.Users
.Inlude(u => Posts)
.Select(u => new {
u.Id,
Count = u.Posts.Count()});Needless to say, I did not get the job, but several years later I still don't know how to answer his question.
I've worked with NOSQL (Mongo/Mongoose, Firebase) and I've worked with ORMs (Prisma, drizzle, Hasura), and I've been able to implement any feature asked of me, across several companies and projects. Maybe there's a subset of people who really do need to know this for some really low level stuff, but I feel like your average startup would not.
I think maybe it's similar to "can you reverse a linked list" question in that maybe you won't need the answer to that particular question on the job, but knowing the answer will help you solve adjacent problems. But even so, I don't think it's a good qualifier for good vs bad coders.
So the equivalent of
`rails db:migrate` after doing what you suggested in the interview. You could write in SQL as..
``` ALTER TABLE posts ADD COLUMN user_id INT, ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id); ```
I don't know if that's what he was after but that's what my mind jumped to immediately. I'd recommend learning a bit as sometimes I've found that orms can be a lot slower than writing plain SQL for some more complex data fetching.
Or if you have the luxury to choose, which can happen later in your software engineering career, you can simply turn down companies with bad interview processes. Personally I’m a fan of this method, but it’s a luxury for sure.
What's nice about prisma and hasura is that you can actually read the sql migration files generated, and you can set the logging to a level where you can read the sql being run when performing a query or mutation. I found that helpful to understand how sql is written, but since I'm not actually writing it I can't claim proficiency. But I can understand it.
I trust that some people can deal with ORM, but I know that I can't and I didn't see anyone who can do it properly.
So, I guess, there are some radical views on this issue. I wouldn't want to work with person who prefers to use ORM and avoids know SQL, and they probably hold similar opinion.
It is really weird to me that someone would call SQL low level. SQL is the highest level language available in the industry, definitely level above ordinary programming languages.
With regards to SQL being low level, I primarily work with TypeScript so a language that talks directly with the DB (SQL) seems pretty low level compared to TS. I'm not sure what you mean by an ordinary programming language though (obviously not machine code).
The SQL is declarative query language. You describe the query, and database engine automatically builds a plan to execute the query. This plan automatically uses statistics, indices and so on. You don't generally specify that this query must use this index, then iterate over this table, then sort it, sort another table, merge them, the database engine does it for you.
Imagine that you have few arrays of records in JavaScript and you need to aggregate them, sort them, in an efficient way. You'll have to write your logic in an imperative way. You'll have to write procedures to maintain indices, if necessary. SQL does it better.
It it an interesting exercise to imagine programming in a language with built-in RDBMS (or object database system) for local or global variables. For example React Redux uses structures, which are somewhat similar to database. I don't really know if it would be useful or not, to write SQL instead of functional API (and get performant execution, not just dumb "table scan") but I'd like to try. C# have similar feature (LINQ), but it's just API, no real engine behind it.
Namely, the ORM got in my way so much. I knew exactly which query to run and how to word it efficiently, but getting the ORM to generate sane SQL was nearly impossible. I eventually had to accept my fate of generating shitty SQL at every company since then...
That being said, I'll always advocate for ditching an ORM if given the chance and the expertise is available. If nobody knows why you generally wouldn't want to put an index on a boolean column, we're probably good. If people think it will help performance on a randomly set boolean field, we should probably stick with an ORM.
Most ORMs don't have the SQL tools we did to sanitize variables when putting them into queries. Some do, but not all.
Come on guys, working on backend applications and not having a clue about writing simple SQL statements, even for extracting some data from a database feels...awkward
My point is that there are acceptable levels of abstraction in all parts of software. Some companies will have different tolerances for understanding of that abstraction. Maybe they want a front-end dev to understand the CSS generated from tailwind. Or maybe they want them to know exactly what happens when a React node is rerendered. Or maybe the company doesn't care as long as the person is demonstrably productive and efficient at building stuff. What some consider basic knowledge can be considered irrelevant to others. Whether or not that has lasting consequences is to be seen, but that just brings us full circle back to the original problem at hand (is it good that people can vibe code something and not understand the code it generates)
That said, I do know enough basic SQL to understand what ORMs are doing at a high level, but because I almost never write SQL I wouldn't consider myself proficient in it.
Companies should do that more!
If that's required, then you are working with a bad abstraction. (Which in the case of ORMs you'll probably find many people arguing that they are often bad abstractions.)
I agree that there should be a general understanding one should be able to interact with it when needed. But at the same time I don't think devs need to be able to spit out queries with the right syntax on the spot in an interview setting.
It's one thing to have a query language (DDL and DML no less) that was built for a different use case than how it's used today (eg: it's not really composable). But then you stack a completely different layer on top that tries to abstract across many relational DBs - and it multiplies the cognitive surface area significantly. It makes you become an expert at Hibernate (JPA), then learn a lot about SQL, then learn even more about how it maps into a particular dialect of SQL.
After a while you realize that the damn ORM isn't really buying you very much, and that you're often just better off writing that non-composable boring SQL by hand.
- assuming you have a decent testing infrastructure in place. Much of the supposed benefit of ORMs is about a form of psuedo-type safety, and making it easier to add more fields. If you have fast running tests that exercise the SQL layer, you might find those benefits aren't very compelling since you have such rapid feedback for your plain SQL anyway.I've almost never changed the vendor of DB in a project, so that's another supposed benefit that doesn't buy me much. I have often wanted to use vendor-specific functionality however, and often find an ORM gets in the way of that.
To sum it up - I agree completely. If it's your job to wrangle an SQL DB - you ought to learn some SQL.
> assuming you have a decent testing infrastructure in place. Much of the supposed benefit of ORMs is about a form of psuedo-type safety, and making it easier to add more fields. If you have fast running tests that exercise the SQL layer, you might find those benefits aren't very compelling since you have such rapid feedback for your plain SQL anyway.
"decent testing infrastructure" is kinda doing a lot of heavy lifting — I love TDD but none of the startups I've worked at agreed with my love of TDD. There are tests, but I suspect they wouldn't fall under your label of decent testing infrastructure.
But let's say we do have a decent testing infrastructure — how does this solve the type safety benefit that you mentioned?
This might be something I'd ask about in an interview, but I'd be looking for general knowledge about the columns, join, and key constraint. Wouldn't expect anyone to write it out; that's the boring part.
I use claude code quite liberally, but I very often tell it why I won't accept it's changes and why; sometimes I just do it myself if it doesn't "get it".
I’m honestly so sick of interviews filled with gotcha questions that if you’d happened to study the right thing you could outperform a great experienced engineer who hadn’t brushed up on a couple of specific googlable things before the interview. It’s such a bad practice.
And most things that are useful daily is not pure knowledge. It's adapting the latter to the current circumstances (aka making tradeoffs). Coding is where pure knowledge shines and it's the easiest part. Before that comes designing a solution and fitting it to the current architecture and that's where judgement and domain knowledge are important.
That's kind of an ironic statement given the context. AI is just a glorified search engine that makes it very easy to find relevant information on a topic, just like a search engine but faster. One must still verify the results to be true, just like a search engine. AI is a tool to help you do your work faster, not do it for you, and should be trusted as much as any other anonymous source.
Let me share you something, maybe it helps to update your perspective.
We reject people not because they help themselves with AI, everyone on the team uses AI in some form. Candidates are mostly rejected, because they don't understand what they write and can't explain what they just dumped into the editor from their AI assistant. We don't need colleagues who don't know what they ship and can't reason about code and won't be able to maintain it and troubleshoot issues. I can get the same level from an AI assistant without hiring. It's not old vs. young, we have plenty of young people on the team, it's about our time and efforts spent on people trying to fake their skills with AI help and then eventually fail and we wasted our time. This is the annoying part, the waste, because AI makes it easier to fake the process longer for people without the required skills.
Tried Cursor, Windsurf and always ran into tool failures, edit failures etc.
I agree that it's bad. What I noticed using AI was that it tends to introduce gradients whenever you want to make something look nice. Whenever I see a gradient now I immediately assume that it was designed with AI
For example, AI could produce Graphanas design standards, which is fine for the audience.
It truly cannot reason well yet about geometry, visual aesthetics, placement, etc. The performance varies: it's quite good at matplotlib but terrible at any non-trivial LaTeX / TikZ layout or graphic. Why? Not a clear idea yet -- would love to think more about it.
I've tried many things now to try and give it eyes (via text), and this is unavoidably a place where things are ... rough ... right now.
I've had bad results with image screenshotting. More often than not, it has no idea what it is looking at -- won't even summarize the image correctly -- or will give me an incorrect take "Yes indeed we fixed the problem as you can tell by <this part of the UI> and <that part of the UI>" which is wrong.
I typically have to come in and make a bunch of fine-grained changes to get something visually appealing. I'm sure at some point we'll have a system which can go all the way, and I'd be excited to find approaches to this problem.
Note -- tasks which involve visual design which I've run into diminishing returns: * proper academic figures (had a good laugh at the GPT 5 announcement issues) * video game UI / assets * UI design for IDEs * Responsive web design for chat-based interfaces
All of these feel like "pelican" tasks -- they enter into a valley which can't be effectively communicated via textual feedback yet ...
Hardened and long use systems like TikZ of course, do have something like this -- but in complex TikZ graphics, you end up with a mixture of "right of" and "left of" (etc) and low-level manual specification, which I think tends to fall into the zone of issues.
I've been leaning hard on the code-gen crutch, don't get me wrong, and it's a force multiplier some of the time. I'm not even doing anything that out there, but it keeps stumbling over its shoelaces all the time.
This is why we can't have nice things. Anthropic is placing more restrictive limits and now you risk being locked out for hours if you need to use it a bit more than usual (e.g. you have an impending deadline or presentation).
I wish Anthropic just banned these abusive accounts instead of placing draconian (and fuzzy) limits. The other day there was an idiot YouTube streamer actively looking to hit limits with as many concurrent Claude Code sessions as he could, doing nonsense projects.
Just letting a single instance run all the time … is not that bad, seriously.
Wow, the danger is not so much from Claude Code itself, but that it might download a package that will do nasty things on your machine when executed.
Sure, go have fun with the new software -- but for godsake don't actually depend on a company that can't bother to reply to you. Even Amazon replies.
Saw the double bill and contacted them, I had a full refund in a couple days and a nice personal note thanking me for being a max user.
This was a couple months ago so it’s possible they’ve had a huge influx of requests that made it difficult to respond fast lately but I had a good experience with their customer service.
Otherwise good article, I'm still not sure vibe coding is for me and at the price, it's hard to justify trying to out, but things like this do make me a little more tempted to give it a shot. I doubt it'd ever replace writing code by hand for me, but could be fun for prototyping I suppose
Sir, do you realize that crud is such a solved problem that popular MVC frameworks from over a decade ago generate it for you from templates? No wasteful LLM prompting required.
A frustration of using tools is that they never entirely act exactly the way you want... instead of it working the way you want, you have to work they way it wants (and before that, you have to figure out what that is).
...We're stuck with this, because it's just not feasible to build custom software for each person, that works exactly the way they want.
...Or is it?
I'm intrigued by the possibility that coding models do in fact make it feasible to have software customized exactly to what I want.
Of course, that includes the coding agent, so no need for Claude Code.
You can use these tools in lots of different ways. You don't have to go all the way to the vibe coding extreme. You can go down to individual functions and have it write them and adjust them step by step if you want, approving every diff. Or even just have it on the side to chat with about your code (Aider is great for this in /ask mode). You can guide its behaviour with CONVENTIONS.md / CLAUDE.md and get it to work how you want as well. I find it handy just asking Aider to write comments for my functions.
It's definitely early days but I'm expecting we'll pretty quickly evolve to having standard "profiles" you can apply to work in different ways, and projects will start shipping with them out of the box (a bit like lint config). This will relieve a lot of the friction at the moment where you spend the first hours / days just corralling it to work the way you want.
Using it for iOS development is interesting. It does produce working output (sometimes!) but it's very hit-or-miss. Recently I gave it a couple hours to build a CarPlay prototype of one of my apps. It was completely unable to refactor the codebase to correctly support CarPlay (even though I passed the entire CarPlay documentation into it). I gave it three attempts at it. Then I intervened and added support for CarPlay manually, following that I added a lot of skeleton code for it to flesh out. Claude was then able to build a prototype
However, over the next few days as I tried to maintain the code I ended up rewriting 60% of it because it was not maintainable or correct. (By "not correct" I mean it had logic errors and was updating the display multiple times with incorrect information before replacing it with correct information, causing the data displayed to randomly refresh)
I also tried getting it to add some new screens to a game I develop. I wanted it to add some of the purchase flows into the app (boring code that I hate writing). It managed to do it with compile errors, and was unable to fix its own build output despite having the tools to do so. Instead of fixing the build errors it caused, Claude Code decided it would manually verify that only its own changes were correct by running `swiftc` on only files that it touched. Which was nonsense
All that said, there was a benefit in that Claude Code writing all this code and getting something up on the screen motivated me to finally pick up the work and do some of these tasks. I had been putting them off for months and just having the work "get started" no matter how bad, was a good kick start
Regarding some of the comments here: I found the article style fine, and I even like the "follow my journey" style writing as it helps the reader understand the process you went though. That kind of engineering and debugging workflow is something I enjoy about this industry.
I think the issue with this conversation is that no one tells you what they are working on, and I suspect there is both a skill gap in usage, but also a lack of capability in the LLMs, both surfacing as the same outcome.
There is definitely stuff an LLM cannot do on its own, at which point is the LLM really achieving the outcome or is it the human just achieving it by backseat driving. Much like a senior telling the junior how to solve a tricky bug, you wouldn't say the junior came up with the solution and therefore you would not say the junior is capable of solving the bug.
Recently my CC subscription ran out, tried 3 prompts with Cursor Agent and then went back to subscribing CC. I still use Cursor though for autocompletion.
Because I think 'sending everything to the ai' would be a bit of an obstacle for most company environments
They even PAY for this privilege.
Yea, I know that was the case when I clicked on the thumbnails and couldn't close the image and had to reload the whole page. Good thing that you could just ask AI to fix this, but the bad thing is that you assumed it would produce fully working code in one shot and didn't test it properly.
*EDIT* prominent close button and closing on back navigation added (probably people will complain about hijackng the back button now)
https://www.media.mit.edu/articles/a-i-is-homogenizing-our-t...
Instead of giving it a VPS, I just made a tool that allows synchronization of localStorage data.
I now just upload the HTML it generates and have an app instantly.
This is something a third of your total gross income - if we take a median over the people of the world.
doppelgunner•6mo ago
sixhobbits•5mo ago
libraryofbabel•5mo ago
mwigdahl•5mo ago
dangus•5mo ago
Even if the prompting and looping logic is better, the direct integration with the graphical system along with the integrated terminal is a huge benefit, and with graphical IDEs the setup and learning curve is minimal.
mwigdahl•5mo ago
CodingJeebus•5mo ago
I’m just glad we’re getting past the insufferable “use Cursor or get left behind” attitude that was taking off a year ago.
bicx•5mo ago
vemv•5mo ago
That's a critical feature for keeping a human in the loop, preventing big detours and token waste.
reasonableklout•5mo ago
vemv•5mo ago
The opposite approach is also possible: just hit the option (or .json setting) to accept all edits. Then you'd review the persisted changes using your favorite Git tool.
perryizgr8•5mo ago
cyprien_g•5mo ago
Recently, I tried using Claude Code with my GitHub Copilot subscription (via unofficial support through https://github.com/ericc-ch/copilot-api), and I found it to be quite good. However, in my opinion, the main difference comes down to your preferred workflow. As someone who works with Neovim, I find that a tool that works in the terminal is more appropriate for me.
threecheese•5mo ago
cyprien_g•5mo ago
I may stop my experiment if there is any risk of being banned.
bfeynman•5mo ago
CuriouslyC•5mo ago
suninsight•5mo ago
The company I work for builds a similar tool - NonBioS.ai. It is in someways similar to what the author does above - but packaged as a service. So the nonbios agent has a root VM and can write/build all the software you want. You access/control it through a web chat interface - we take care of all the orchestration behind the scene.
Its also in free Beta right now, and signup takes a minute if you want to give it a shot. You can actually find out quickly if the Claude code/nonbios experience is better than Cursor.
CuriouslyC•5mo ago
suninsight•5mo ago
If you use the interface at nonbios.ai - you will quickly realize that it is hard to reproduce on slack/discord. Even though its still technically 'chat'
CuriouslyC•5mo ago
It's still nice to have a direct web interface to agents, but in general most orgs are dealing with service/information overload and chat is a good single source of truth, which is why integrations are so hot.
irskep•5mo ago