I've been through a few cycles of using LLMs and my current usage does scratch the itch. It doesn't feel like I've lost anything. The trick is I'm still programming. I name classes and functions. I define the directory structure. I define the algorithms. By the time I'm prompting an LLM I'm describing how the code will look and it becomes a supercharged autocomplete.
When I go overboard and just tell it "now I want a form that does X", it ends up frustrating, low-quality, and takes as long to fix as if I'd just done it myself.
YMMV, but from what I've seen all the "ai made my whole app" hype isn't trustworthy and is written by people who don't actually know what problems have been introduced until it's too late. Traditional coding practices still reign supreme. We just have a free pair of extra eyes.
I also use AI to give me small examples and snippets, this way it works okay for me
However this still takes away from me in the sense that working with people who are using AI to output garbage frustrates me and still negatively impacts the whole craft for me
Having bad coworkers who write sloppy code isn't a new problem, and it's always been a social problem rather than a technical one. There was probably a lot less garbage code back when it all only ran on mainframes because fewer people having access meant that only the best would get the chance, but I still think that opening that up has been a net benefit for the craft as a whole.
Before there was some understanding that at least they wrote and understood their own garbage code
Now it is not true. Someone can spend a few minutes generating a non-sense change and push for review. I will have to spend a non-trivial amount of time to even know it’s non-sense.
This problem is already impacting projects like curl who just recently closed their bug bounty because of low-effort AI generated PRs
> Before there was some understanding that at least they wrote and understood their own garbage code
> Now it is not true. Someone can spend a few minutes generating a non-sense change and push for review. I will have to spend a non-trivial amount of time to even know it’s non-sense.
The problem sounds basically the same to me honestly. If someone submits code that I can't understand and asks me to review it, the onus on them to explain it. In the previous case, maybe they could, but if they can't now, the review is blocked on them figuring out how to deal with that. If that's not what's happening, it sounds more like an process or organizational problem that wouldn't be possible to fix with the presence or absence of tooling.
> This problem is already impacting projects like curl who just recently closed their bug bounty because of low-effort AI generated PRs
External contributions are a bit of a different problem IMO. I'd argue that open source maintainers have never had any obligation to accept or review external PRs though. Low effort PRs can be closed immediately with no explanation, and that's fine. It's also totally possible and acceptable to limit PRs to only people explicitly listed as contributors. I've even seen projects hosted on their own git infrastructure that don't allow signing up through the web UI so that you can only view everything in the browser (and of course clone the repo, which already isn't something that requires credentials for public git servers).
I guess my overall point is that the changes are more social than technical, and that this isn't the first time that there was a large social shift in how development worked (and likely won't be the last one either). I think viewing it through the lens of "before good, after bad" is reductive because of how it implies that the current changes are so large that everything else beforehand was similar enough to gloss over what had been changing over time already. I'm not convinced that the differences in how programming was achieved socially and technically between 43 years ago (when the author says they started programming) and the dawn of LLM coding assistants were obviously smaller than the new changes that having AI coding tools have introduced, but that isn't reflected by the level of cynicism in most of these discussions.
You can’t really claim any PR is “low-effort” without actually reading and digesting the thing
Yes in the past you could check “oh this doesn’t have back trace or any steps to reproduce, close with won’t fix”
Now you cannot do that, the “low-effort” could be a 500+ lines code change with accompanying documentation and a 300 lines in prose describing the “problem” alongside with “backtraces” showing the issue
Except, the fix is non-sense but you have to read 500+ lines too know that. The documentation doesn’t match the changes but you have to read it to know that. The backtraces literally contain made up functions but once again you need to look closely to verify.
And if the thing isn’t immediately obvious to be AI generated then you’ll end up asking questions which will get forwarded to some AI and end up playing broken telephone.
All of this literally happened to curl in different issues.
I see comments like this a lot. In fact, I've run into it in my own side projects that I work on by myself -- what is this slop and how do i fix it? I only have myself to blame.
I can't speak to open source orgs like curl, but at least at the office, the company should invest time in educating engineers on how to use AI in a way that doesn't waste everyone's time. It could be introducing domain-specific skills, rules that ensure TDD is followed, ADRs are generated, work logs, etc.
I found that when I started implementing workflows like this, slop was less and if anyone wanted to know "why did we do it like X" then we can point to the ADR and show what assumptions were made. If an assumption was fundamentally wrong, we can tell the agent to fix the assumption and fix the issue (and of course leave a paper trail).
Engineers who waste other engineers' time reviewing slop PRs should just be fired. AI is no excuse to start producing bad code. The engineer should still be responsible for the code they ship.
> Engineers who waste other engineers' time reviewing slop PRs should just be fired. AI is no excuse to start producing bad code. The engineer should still be responsible for the code they ship.
Yeah, this is the unfortunate truth about what's going on here in my opinion. The underlying problem is that some workplaces just have bad culture or processes that don't do enough to prevent (or even actively encourage) being a bad teammate. AI isn't going to solve that, but it's also not really the cause, and at the end of the day, you're going to have problem at a place like that regardless of whether AI is being used or not.
Serious question: so what then is the value of using an LLM? Just autocomplete? So you can use natural language? I'm seriously asking. My experience has been frustrating. Had the whole thing designed, the LLM gave me diagrams and code samples, had to tell it 3 times to go ahead and write the files, had to convince it that the files didn't exist so it would actually write them. Then when I went to run it, errors ... in the build file ... the one place there should not have been errors. And it couldn't fix those.
The value is pretty similar to autocomplete in that sometimes it's more efficient than manually typing everything out. Sometimes the time it takes try select the right thing the complete would take longer to type manually, and you do it that way instead, and sometimes what you want isn't even going to be something you can autocomplete at all so you do it manually because of that.
Like autocomplete, it's going to work best if you already know what the end state should be and are just using it as a quicker way of getting there. If you don't already know what you're trying to complete, you might get lucky by just tabbing through to see if you find the right result, or you might spend a bunch of time only to find out that what you wanted isn't coming up for what you've typed/prompted and you're back to needing to figure out how to proceed.
I mean, it's not actually autocomplete. But it serves the same role. I know approximately what I want to type, maybe some of the details like argument-order are a bit foggy. When I see the code I recognize it as my own and don't have too much trouble reading it.
But I use LLMs one level higher than autocomplete, at the level of an entire file. My prompts tend to look like "We need a new class to store user pets. Base it on the `person` class but remove Job and add Species. For now, Species is an enum of CAT,DOG,FISH, but we'll probably turn that into a separate table later. Validate the name is just a single word, and indicate that constraint when rendering it. Read Person.js, CODE_CONVENTIONS.md, and DATA_STRUCTURES.md before starting. When complete, read REFACTOR.md"
With the inclusion of code examples and conventions, the agent produces something pretty close to what I'd write myself, particularly when dealing with boilerplate Data or UI structures. Things that share common structure or design philosophy, but not common enough to refactor meaningfully.
I still have to read it through and understand it as if I'd written it myself, but the LLM saves a lot of typing and acts as a second pair of eyes. Codex currently is very defensive. I have to remove some unnecessary guardrails, but it will protect against rare issues I might not have noticed on my first pass.
I've found small features helps. If I ask the ai "do this", I wait 10 minutes for it to be finished, then another 30 understanding what was written
Instead, I start out broad. "I'm thinking of this feature. Let's talk about what components will go into it and where that code will live... Here are my initial thoughts. Let me know if I get anything wrong..."
This puts it in a conversation mode and gets you on the same page, and best of all it's quick. The llm agent isn't searching files and building, it's just giving general opinions
Once I have a good idea of the architecture, I move on to "write this class. Here is an overview of how I would do it", or point the agent to an existing file with the right conventions in place. Once again, if you've done your conversation doesn't take long. 20-second turnaround.
Then it's time to refine. "Move this function here, refactor that"
If you're going to have to understand the code anyway, read it while your writing it. Line by line, function by function, class by class. "Growing" a feature this way keeps you and the llm in sync. It doesn't go off on tangents. And building incrementally keeps you in the loop and in your flow. You don't have 5 things going at once. You have 1, faster.
I've let agents do their thing for a dozen minutes and usually end up having to rewind the whole thing piece by piece to understand what's actually happening
If you're truly vibe coding, maybe you don't have to read the code and can have a dozen agents on a dozen projects. But if you're making Serious Software, I don't see how you can commit code unseen. And in that case, you're not losing anything working incrementally and reading code as it's written?
I'm in the JS ecosystem pretty regularly and "restrictive with no benefit" is the right description. I use JSON5 now when I have to, which greatly reduces the restrictions. I already have a build step so throwing in a JSON5 -> JSON converter is negligible.
As for FracturedJson, it looks great. The basic problem statement of "either minified and unreadable or prettified and verbose" isn't one I had put my finger on before, but now that it's been said I can't unsee it.
I do a lot of local dev using docker. I've taken to adding an image just for agents and using that to make modifications. Agents can install or run anything they need without touching my actual machine. I can also limit what they can read and write.
Yes, that would be the ideal setup indeed, agreed.
But ruined health made me laser-focus on my wife and my work and I ignored many other things. Much to my shame, I don't even have a home media center and I have all the skills to make it happen and have it be much better than f.ex. Netflix or Disney+ UI.
It's all about carefully picking my battles, at least in this stage of life. Lack of focus and trying to be everywhere led to me making dozens, if not hundreds, of easily avoidable mistakes. I am hellbent on never allowing that again.
I think the point though is it's not a "story". It's a fundamental shift. The shift is subtle and doesn't lend itself to sensationalism.
Entire countries have built their clout on fossil fuels. Wars have been fought. Now any country with a sufficient manufacturing base can be energy independent. And the resource is less controllable by a small group of people.
AI and geopolitics and everything else is huge right now, but they're being bent to the will of the current world order. The article is saying that that world order is going to change.
What font has been more tested for quick pass-through of data than the default system fonts? To me, this simply screams "This is the main body. You can find your information here"
No. System fonts have completely different reasons for existing than fonts you would want to use to communicate with the public. System fonts were initially created for legibility at certain screen resolutions, for dot-matrix printers, etc.
But it's worse than that. What I'm trying to explain is that every typeface, even the most innocuous one gives subtle, subconscious cues to the readers. Every font. The associations can range from some childhood Disney movie to a font you saw at a hospital while you were having a really serious medical problem. But after 30 years of everyone on earth looking at system fonts, readers now get the cue when they see a system font that they are looking at a shitty MS Word document their boss just pinned to the felt board. Or else they assume the author did not bother or did not have the skill to make it look good.
I'm a writer. I've written 6 novels. I love words and ideas, unencumbered by visuals. I've written at least 500k LoC on in my life, maybe double that, I don't know. That's all pure thought and logic. So I get the agitation: All I want to get across to you, my reader, my employer, is the information, my distilled ideas. That's all that's important. Read it or don't, I don't care, it's good and the logic works.
I'm also trained as a designer. My first several jobs were in ad agencies, since I was 14 years old as an intern. How will people subconsciously interpret the ancillary visual aspects of this is something I learned early on: what will they construe? Because bad design can prejudice someone against a great piece of writing, and vice-versa.
No visual thing you can make has zero cultural reference; everything you make that other people will see drags some bundle of pre-understood tropes into it. You can't make one without referencing some aspect of culture that affected you. The job of a designer - what makes a designer different from someone who just has aesthetic chops and can tell if a web page looks good - what constitutes the black arts of design - is to know every single cultural trope you are dragging in front of the customer's target audience and to understand how it will psychologically affect their state while they read the content, so you know how to trigger certain emotional resonances in them while they absorb the information the client is trying to get across.
That's what "giving a shit" means in terms of communicating visually.
Observe how there's no custom font, no weird font, and no "associations with some childhood Disney movie" to be found on a page seen and used by 2+ billions of users daily.
Funny you should bring that up, because FB is a perfect example of a visual relic from the late '00s which didn't age well. Much of the post-dot-com-crash world of design in the web and early mobile space was defined by a rejection of the excessive - wild crazy idiotic irreverent and often incoherent - typography and design of the '90s web. So, super basic fonts, white backgrounds, and what they thought was "minimalism". However, because they relied on the tooling rather than creating their own cues, (and also because their UI turned into a towering nightmare of crap) Facebook looks extremely dated to most people's eyes now. It looks like a 20 year old website...and not a particularly good one.
My outside opinion is that Meta does not give a shit at all about how Facebook looks at this point. I'm not here to make the case that revolutionizing their design would improve their onboarding rate now or something. I'm making the case that if you are some nobody with no network effects and no billion dollars, you have a better chance at getting people to read your content if you take the time to (a) get it out of system-ui fonts and (b) make a bunch of other aesthetic decisions that trigger certain pleasing feelings in your audience.
Most current system screen fonts in major OSs - as a general group, as a set of letter forms - are not and never were printed fonts. They evolved from bitmap fonts that were created with 90s constraints in mind. They retain some of that aesthetic, and they are not usually the best candidate for the job.
Leaving it up to your user's system font is also an arguably poor choice.
> Most current system screen fonts in major OSs - as a general group, as a set of letter forms - are not and never were printed fonts. They evolved from bitmap fonts that were created with 90s constraints in mind. They retain some of that aesthetic, and they are not usually the best candidate for the job.
This couldn't be more wrong. Things have progressed since the '90s.
Apple, Google, Microsoft hired real typographers to create their new fonts. Apple uses San Francisco in their printed materials all the time.
On Apple devices, system-ui is San Francisco, a TrueType variable font with 2937 glyphs, 4 axes and 369 instances. The axes are width, optical size, grade and weight. San Francisco also has all of the goodies someone who cares about typography could want: ligatures, small caps, contextual alternatives, true fractions, etc.
I think this qualifies as "giving a shit". ;-)
BTW, you can see each named instance in the developer tools in Firefox and Chrome on macOS.
An instance is a combination of the 4 axes; the instance of San Francisco compressed thin uses can be specified in CSS as:
Could you recommend any good books, video series, blogs, or other training for those that who need to understand fonts at your level professionally? Or maybe you could write one?
I know someone that is trying to break into this space but doesn’t have the past experience, and it’s almost impossible to catch up. I’d love to provide them with a resource.
In defense of Comic Sans, it’s not just for realtor pages. It can be effective for local, casual communication by appearing friendly and approachable. If I saw a flyer pinned to a corkboard advertising a fish and chips special in Comic Sans in a seaside town, my mouth would be watering, because I’d know that’s a mom and pop place that focuses more on the food and taking care of people than the marketing.
>> If I saw a flyer pinned to a corkboard advertising a fish and chips special in Comic Sans in a seaside town, my mouth would be watering
Heh. You absolutely nailed the concept. This is precisely right. Comic Sans is a totally crap font, but it's great if that's the feeling you want to get across! That's exactly how thoughtful design works. Level one is to know your references. Level two is: Use the kitsch when you want it. Use the profane. Use the found art. Then use the "classy" or "expensive" when you want to show a "classy" client. Level 3 and up is knowing how to play with those high and low cultural notes to make a kitschy client still look kitschy but subconsciously implant that the fish is of a slightly better quality; or make your "classy" real estate agent still look "classy" but show that they aren't a stuffy asshole. And do this without either client outright complaining.
Far as books, I'd qualify by saying that I learned the design craft on the job from an early age and was tutored by great art directors who let me experiment and explained these things to me; why what I was communicating with a certain background or certain font was going to negatively affect a consumer in a way I hadn't considered. And I had a couple great professors in college (but I dropped out). Most of the basic theory of the higher level of how to use this stuff to influence people is contained in Marshall McLuhan's "Understanding Media", which is the quintessential work on how one - in a design role - can change perception of the content of a piece by making informed psycho-sociological choices about the way it's presented visually. Lots of master works before and since on the concept of propaganda, but for designers McLuhan helpfully narrows it down to show that presentation is often more important than content, and for designers this means your role is essentially to master content the way an audio engineer masters a band's album. Which is often as important to the final output as the original recording quality itself. This is especially hard to do if you also wrote the content because it requires a certain objectivity about the work. Anyway, McLuhan's theory is timeless and kind of essential to get into the guts of everything: How brands work, how small design choices work, etc.
Being able to explain the difference between what looks good and being able to explain why you chose it (along with all the cultural references, positive and negative, which the choice is intended to trigger in the audience) makes the difference between a $40/hr design job and a $150/hr art direction job, so mastering the technique of selling the technique has a certain benefit as well. But you must come armed to your client with examples. The best way to learn is to look at everything you see around you and question all their design choices, why did they use those colors, those fonts, etc. and also see what trends are developing. Go back to the 1950s, 60s, 70s, 80s, 90s and see what they were using then. Now who is your target audience, and what feeling do you want to give them?
[edit] Just want to add: I was a purely technical child who learned to code and run a BBS way before I knew anything real about design. I came up doing what I thought was cool ANSI art and then "designed" some stuff in Photoshop 3.0 for people when I was 12. I didn't understand anything. When you're a technical person you tend to see design as a problem to solve with programs and with code. You don't realize that design is a programming language that runs on human brains. This was a revelation for me when I was about 15, and it's informed all my choices since. So yes - fonts matter.
I think we're still missing an "open social" closed social network. Something like old-Facebook where you can post to an intimate audience of friends and family, and your feed isn't stuffed full of ads and influencers. Just a little private windows into your friends' lives.
That feels like something that could displace other social media in a way that's difficult for for-profit businesses to replicate since it goes against every product manager's instinct to leave engagement on the table, and would stand in stark contrast to the current social media landscape.
That looks really promising. It checks a lot of the boxes I already had in mind for such a system, like being able to continue a thread without exposing the whole thing to untrusted parties
Same here. I was surprised at everyone here who prefers the more-complicated-but-arguably-more-intuitive lexical sort. Naive alphabetical sorts break some expectations, but don't produce any weird edge cases.
I wonder if there's an age divide at play here, where those of us who grew up with the naive alphabetical sort prefer it.
