Flagrant

Developer Round Table - Why Do We Still Dismiss CSS?

2026-07-20T09:08:00-05:00

You know what’s weird? CSS is everywhere, pretty much on every website and yet, there’s this attitude about CSS that persists that it doesn’t need to be taken seriously; it’s just icing on a cake. Casey brought this up at a Developer Round Table discussion, and it hit home. There’s this vibe that CSS is just… weird, or “not real code.” And I get it, a lot of us lived through the ‘try it in every browser and pray it works’ era. It was rough.

But honestly, those days are mostly gone. With Flexbox, grid, and modern tooling, styling is smoother than ever. But still, the reputation lingers.

So what’s our responsibility as web folks? Just hand-wave and blame the language? Or dig in and treat CSS with the respect it deserves?

On a certain level, it feels like a self-fulfilling prophecy. This was a thought brought up by Max, a developer at Flagrant. If you believe from the start that CSS is a lost cause, you’re never going to bother learning it well. You limp through, hate every second, and when it breaks, you get to say “Told you it was bad.” Which isn’t fair to the language to label it as difficult or broken just because you didn’t bother to truly understand how it works.

Part of the problem might be that CSS hasn’t had the same level of tooling and support other languages enjoy. In Ruby, Java, or JavaScript, your editor catches errors, helps autocomplete methods, points out typos, it’s a conversation. But with CSS, it’s often silent. No nudges, no suggestions, just… hope for the best.

But maybe that’s also on us.

As Casey pointed out, there’s a chicken-and-egg situation happening. We don’t take CSS seriously, so the tooling hasn’t caught up, and because the tooling hasn’t caught up, we don’t take it seriously.

That’s slowly starting to change. Visual regression testing, design linting tools, better devtools, the ecosystem is maturing. But it’ll only keep improving if we demand more of it and invest time into it.

This brings me to the heart of it: why do we dismiss CSS in the first place?

CSS isn’t just about making things “pretty.” It’s about creating a usable, intuitive experience. If you’ve ever visited a site that felt frustrating or clunky, buttons too small, text hard to read, weird layout, you know exactly how much design and styling matter. A beautifully engineered backend doesn’t mean much if the frontend makes users want to leave.

Styling is functionality. And yet, we treat it like decoration.

We also discussed how design has historically been a more female-dominated discipline. And we know, historically, that female-dominated fields tend to get dismissed or undervalued. That bias, even if it’s unconscious or unintentional, might be part of why CSS and design work often aren’t given the same technical respect.

I’m not saying developers are intentionally dismissive or malicious. But it’s worth examining how our own biases, whether personal or systemic, shape the way we value different kinds of work. If we want to grow as developers, and as a community, we have to be willing to question these patterns.

What would happen if we approached CSS as an equal partner in the stack?

We’d probably write better code. We’d build better tools. We’d create better experiences for users, and maybe we’d start to close some of the gaps in respect and recognition within our teams and communities.

Because in the end, CSS isn’t just how things look, it’s how things feel. And that deserves just as much care and craft as any other part of the web.

Let’s stop treating CSS like an afterthought. Let’s build with it like it matters, because it does.

Delightfully Friday Junior: Pet Art Gallery

2026-06-25T07:16:00-05:00

Here at Flagrant, we’re big fans of our fur babies and critters alike (we even have a dedicated Slack channel to share photos with each other). This week’s Delightfully Friday Junior is brought to you by our unconditional love for the non-human brethren in our lives and a healthy dose of artistic flair and critique.

I’m Still Clauding

2026-06-23T10:38:00-05:00

A couple of months ago, I wrote about starting to use Claude Code.

I’m still there, still living in Claudeville. I’m still feeling plenty of things, including being conflicted in many ways. And it all comes down to energy use — that is, what energy I have to dedicate to this work.

The biggest thing that I’m feeling now relates to my position as a consultant, not “just a developer”. Being a consultant at a small company means wearing a lot of hats. Even if you’re primarily a developer, you don’t have the luxury of dedicated PMs, or client management / liaisons, or ops, or all these things that would let you concentrate on just the software. And while I can do these other things, it’s difficult for me to do them all and do the development, the building. It’s not just that I enjoy the building part (the “craft”) the most, it’s also what I’m best at. And what that means for me in practice is it’s also the part I’m best at pulling back from and giving direction and review on. It’s the part I’m best at giving over to automation, to assistance, to an agent. It lets me concentrate on all the other things I have to do, and truly do myself.

I’m also feeling plenty about the amount of stuff to do, and the velocity with which it gets done. There’s just so much to deal with — mountains of LLM output, context-switching with bouncing between separate problems (and even separate projects) — and it’s hard to keep up. Yes, LLMs are truly a “force multiplier”, but consider what forces are being multiplied. I’m not fond of the military origins of the saying “slow is smooth, smooth is fast”, but I do strongly agree with it. I’m feeling so much demand for so much, and giving in to moving at speed means a future where you get caught in a tangle or run fill-tilt into a brick wall. This can only be countered by slowing down, looking around, and doing things well — or as well as possible. It takes all that time and effort to produce less — the right kind of less.

With so many people using these tools to create literally inhuman amounts of — let’s face it, cruft — that will need to be rescued, I’m remembering my earlier days. I’ve done rescue missions before. It used to be something of a specialty. But now, without some of these same tools in my tool chest, how will I possibly dig out that amount of rubble?

So yes, I’m continuing to dwell in Claudeville. I figure if I’m going to do this, I should do it “right”. I should use the tools at my disposal. So I’ve done plenty to understand the tools and fit them into my tool chest, to shape them to my hands. I set up my dotclaude repo, so I could have a dependable(?), consistent(?) assistant/colleague(?) that goes with me from project to project (and I have plenty of projects to deal with). And as my understanding has grown, so has that repo, accreting with the sediment of lessons learned, and (hopefully) coral of helpful skills and scripts, and (most likely) the barnacles of wild-attempt stabs at stopping or redirecting away from certain unwanted behavior. If you like, you can take a look at the history, and watch these things happen. And in my not-so-humble opinion, that repo and its history show two things that are not always found in other such places.

Ownership. My biggest issue with what’s going on is the lack of ownership, the common anti-pattern of, as Simon Willison puts it, “inflicting unreviewed code on collaborators”. So my CLAUDE.md starts with “You help; I own the result.” This is probably as much a reminder to myself as it is to the agent. It can be seductive to delegate more and more, and try to take yourself out of the equation. This is another aspect of the vigilance I wrote of last time.
Cleanup. It’s not all about doing more, building up. It’s not all about addition. There’s also removal, deletion. Call it refactoring. Call it consolidation. Call it judgement. This dotclaude repo is a project like any other — maybe more so, given its foundational nature, and how every bit I add there has the potential for knock-on effects everywhere I use Claude. Which is, of course, everywhere. Or everywhere I’m working professionally. And I do try to put the emphasis on professional there (refer to the previous point on ownership).

So that’s where I am now, moving along with the world as it is, as best as I can. I hope you, too, are doing the best you can.

Delightfully Friday Junior: Coloring Bonanza

2026-06-16T11:29:00-05:00

When it was my turn to plan the DFJ activity, I wanted to make something that would allow us to relax together, take our minds out of work mode, and just get into the flow of creating without stress. When I think about times when I was the most relaxed and in the creative flow, I think about these huge coloring pages my dad would buy for my sisters and I at the Woodmans near my childhood home. These coloring pages were pictures of fairies, goblins and princesses, and I would lose myself in them, hours of time spent making the drawings just so.

In this case, we couldn’t spend hours on our coloring pages, so I went for some simpler choices, but the effect was the same: fun times just coloring!

Here are the pages the team got to choose from and the results!

And now, without further delay, here are the fruits of our labor!

I think you can see a lot of the team’s personality based on how they approached the activity :P (Credit to the artists on Pinterest, I vectorized for this activity, I don’t have their names, but their work was adorable!) Enjoy!

I hope this inspires you to get out there and be creative, even if it’s just a lil doodle :P

Developer Roundtable: Herb

2026-05-22T03:23:00-05:00

Herb, created by Marco Roth, is a new HTML-aware ERB parser designed to improve developer tooling for Rails view templates. Unlike traditional parsers that either ignore embedded Ruby or modify the original HTML, Herb understands both HTML and ERB simultaneously while preserving the source exactly as written. This makes it fast, error-tolerant, and suitable for real-time editor features. By generating a precise syntax tree for .html.erb files, Herb enables better formatters, linters, language server integrations, and other tooling for modern Rails applications. Throughout this blog post, the images used are pulled from various blog posts by Marco Roth about Herb.

Historically, Ruby developers have had gems like Nokogiri, that parse their html. Nokogiri can detect when you’re missing a closing tag, using the wrong tag, or need to update your code for security reasons. This is just a basic example of what Nokogiri can do, and I encourage you to dive deeper into the linked URL to learn more. The shortcoming of Nokogiri is that it’s just an HTML parser, not an ERB parser, and it modifies your files for you. While that can be useful, it’s also limiting.

How does Herb set itself apart, and what makes it special and different from current HTML/ERB parsers?

Today, in a Rails application, when your HTML template has an error, it shows up in the browser, but the way it’s displayed isn’t very helpful. You’ll typically see red text on a white screen showing the problematic code, and you have to sift through it to figure out where and what the issue is.

With Herb, you’ll see exactly where and what is wrong. Herb shows a top red banner detailing the issue because the parser already knows what’s wrong. It might display something like “Template errors (1)” and then show the file and exact location of the error. This makes debugging easier and faster.

Similarly, when you have warnings about your code, like invalid nested <p> tags, Herb will display them. You can review and dismiss these warnings if you choose, allowing you to continue your development workflow uninterrupted.

Currently, developers use lots of tricks when debugging template errors in their applications. I’m speaking from my own experience and from what co-workers, friends, and random people on the internet have shared. Tricks are necessary because it’s not always easy to know what kind of template error you’re facing or where in your code it’s coming from. It’s not readily apparent, so it requires a bit of sleuthing and detective work to figure out what’s going on.

Some common debugging tricks include rendering comments in the HTML to mark elements for easier visualization, opening the browser inspector to locate those comments, or deleting portions of code to see what disappears after a refresh, helping you locate where something lives in the application. Another example is adding visible borders (like thick red outlines) to containers, divs, or elements to identify where they are on the page. There are countless variations of these techniques, but you get the gist, they exist because debugging templates are inherently limited.

Herb lets you skip all those clever workarounds. You can apply a data attribute like data-herb-debug-file-name and style it in your CSS to get visual outlines of elements. You can even specify types with attributes like data-herb-debug-outline-type="view", which color-codes different types for clearer visual differentiation. Additional labels let you show the full file path, and clicking a path can take you directly to that file in your editor.

You can do the same with ERB output tags. A dropdown toggle menu on the right side of your application (in development mode) lets you control debugging behavior like, for example, showing ERB output tags on hover. Hovering over dynamic content, such as link_to elements, will show what the link_to tag looks like. Just like the HTML tags, you can click these to open the corresponding file and line in your editor. To set this up, follow these steps.

This is all really exciting to see. In my opinion, Herb is a game changer for working with the front end of your application and will save countless hours of development time. It’s easy to understand, simple to integrate, and yet incredibly powerful in its impact. If you spend a lot of time in Rails views, it’s absolutely worth trying in your next project.

Delightfully Friday Junior: Who’s Actually on Your Team?

2026-05-07T07:12:00-05:00

I’ve been putting off writing this for over a month. Turns out I find writing hard. Moving on.

We’re into the next cycle of Delightfully Friday Junior. The format: one team member hosts 30 minutes, no work allowed, activity of their choice. Games, creative tasks, questions — whatever they want. I opened the first round. Since then, two other people have hosted, and both landed on the same instinct I had: ask the team something real.

Who are these people? What’s happening off-camera that’s shaping their day?

In an office you can just… observe. You catch a long sigh. You notice someone’s been staring at the same spot for an hour. You read the room without anyone having to say anything. Remote takes all of that away. If you want to know someone, you have to go looking.

So I gave the team 12 questions and asked them to answer at least 6. Here’s what came back:

What is the best thing that happened to you this week outside of work?

“Helping my Mom get through a challenging time at the hospital and bringing her back home.”

“Reconnecting with an old high school friend.”

What is the biggest distraction you face while working from home?

“Just taking care of home stuff. It’s good to be able to quickly take care of the dogs, or the baby, or the laundry, or whatever. But it also means that the only separation I have from all these things is, at most, a closed door.”

“My own mind always seems to be the biggest distraction. It is a constant wrestling match to figure out how to structure whatever I am working on in such a way that I can get started and stay focused.”

What is one remote work habit you’ve picked up that you’ll never give up?

“Working when I am unable to sleep.”

“Having a nice lunch with my partner away from screens.”

What is one thing your colleagues might be surprised to learn about you?

“I was a member of a dance company in my youth and part of a performance aired on WMTV.”

“maybe surprising or maybe not surprising at all (not sure which): I am a little house cat who likes quiet environments and 1:1 time, not very outgoing or comfy in multi-human settings. She is a sensitive lil granny at heart.”

What is the most significant challenge you’ve overcome in the last year?

“Getting a puppy. Having a puppy. Dealing with a puppy. Did I mention puppy? I’m not sure I’ve fully ‘overcome’ this challenge, btw.”

“Feeling numb and burnt out from stress of the world and life. Getting to leave my house and go touch dirt with my hands and make something that is just for me helped me find community and create new friends.”

What is one thing you wish you were more courageous about?

“Failing and not beating myself up.”

“Confidence. I wax and wane with feeling like I have an ego or showing off, which makes me not toot any horns or feel proud of my work. Which could lead to writing more or speaking about what I do to a crowd without feeling judged.”

What is a piece of feedback you received that changed your perspective?

“You don’t suck at this — it’s just new to you.”

“Labeling yourself as ‘junior’ or ‘beginner’ sets expectations for the person hearing it. I think everyone has experiences that bring value and that we are all at the same level but in different places.”

What is the most rewarding part of your job?

“Getting to create things for and with people that want to do better in this world. Being able to be creative and get paid for it and make a living wage, which is something my parents didn’t get for their skills.”

“Working with people that are so open about their process and kind about feedback. I was recently talking with an old classmate and she was describing some really toxic work environment conditions and I was reminded how wonderful it is to be in this space.”

“Collaborating with you all on cool shit.”

What is one thing you are truly grateful for today?

“I am grateful that spring is here and the birds are singing and the flowers are putting out their flagrances (Freudian slip intended).”

“My supportive partner and the lovely Flagrant team that cares about people.”

I didn’t know I was looking for any of that. But there it is — connection, surprise, context. The things that explain why someone’s quiet on a call, or brilliant in a meeting, or particularly good at one kind of work and not another.

The deeper we go into AI, the more I want to be around actual people. A prompt won’t surprise you. The people I work with did.

If you’re on a remote team, go find out who’s in that rectangle. Not as a team-building exercise. Just because they’re a whole person and you’re missing most of them.

Delightfully Friday Junior: Curiosity Roundtable

2026-05-05T08:25:00-05:00

This week’s Delightfully Friday Junior (if you’re catching up on what this is, learn more here) involved a roundtable sharing of some prompted questions.

A few of these questions were: “What song have you had on repeat?”, “What cartoon or movie character would you want to meet and why?”, “What is the most beautiful place you’ve been?”, “What was your first job?” and “What’s a hobby or activity you’ve picked up in the last couple months?” just to list a few.

As expected, the weirdos at Flagrant did not disappoint in their answers. Here are some highlights.

Gusgus (What cartoon or movie character would you want to meet and why?)
All of the Bob’s Burgers cast (What cartoon or movie character would you want to meet and why?)
Nighttime dip in a historic geothermal pool in Iceland (“What is the most beautiful place you’ve been?”)
“The Rainbow Connection” (original Muppet Movie version) (“What song have you had on repeat?”)
“Chalk Outlines” – Ren and Chinchilla (“What song have you had on repeat?”)
Bakery Clerk (with a very ugly green polyester shirt :’) (“What was your first job?”)

These questions pull out answers you wouldn’t normally hear in day-to-day conversation. Not just the highlights, but the small details that come with them, like that each cast of Bob’s Burgers feel like a different human personality that we all have, or why the muppets could be an answer to every question.

You start with a simple prompt, and suddenly you’re picturing someone standing behind a bakery counter in a questionably green shirt, or imagining what it would actually feel like to sit in a geothermal pool in the middle of the night.

And while the answers themselves are fun, it’s really the sharing of them that makes this a favorite. It gives everyone a chance to bring a small piece of their world into the room, whether that’s a song they can’t stop replaying or a place that left a lasting impression.At the end of the day, this is the kind of thing that makes work feel a little more human and a lot less like just work.

Not a bad way to break up the week.

Delightfully Friday Junior: Rose, Thorn, Bud

2026-04-20T05:28:00-05:00

This week’s Delightfully Friday Junior (if you’re catching up on what this is, learn more here) involved a roundtable sharing of Rose, Thorn, Bud. It’s a great activity in reflecting and learning about our teammates and the full, rich lives we each lead.

Everybody shared at least one Rose, Bud, Thorn from their past week.

A Rose is a highlight, success, small win, or something positive that happened.

A Thorn is a challenge you experienced or something you can use more support with.

A Bud is a new idea that has blossomed or something you are looking forward to knowing or understanding more.

This exercise was a great reminder that while we’re here for a job and have work to do, each person on the team contains multitudes of things that are weighing on them and bringing them joy in the day to day.

Developer Roundtable - Clojurescript

2026-04-10T08:00:00-05:00

This developer roundtable, Casey showcased learnings from his experience using ClojureScript. He is a senior UI/UX engineer and worked at Flagrant previously. He created a game with ClosureScript called Counterspell that was inspired by Strands, the New York Times game.

But first, what is ClojureScript? ClojureScript lets developers write code in a style known as functional programming, and then run that code anywhere that JavaScript can (like web browsers). It is built on top of Clojure, which is a programming language and a dialect of Lisp on the Java platform. ClojureScript uses immutable data structures, or more plainly, once you create information you cannot change it. Additionally, from what I have read from blog posts and related content, ClojureScript fixes a lot of pain points that Javascript has like inconsistent type comparisons, truthy/falsy inconsistencies and unintended type conversions to name a few. To read more about this, here is an article that goes more in depth than this surface level explanation.

Now that we got the foundation for what we are talking about out of the way, let’s get into the meaty bits.

Counterspell, the game Casey created to learn ClojureScript, had a main goal to create words on the board from the options of letter tiles. After you create 3 words, a score will show on the screen letting you know, scrabble points style, the amount of points left on the board. So, the goal is to find 3 words with the highest points so that the remaining letter tiles will be the smallest amount possible. He learned a lot about ClojureScript and here are some take-aways.

The Wins

Interactive development: The whole idea with interactive development is you are taking the notion of REPL (Read-eval-print-loop), all the way to its logical conclusion. You have your text editor and the running session connected to each other. Casey showed an example of the editor open and looking at all the state he had stored in one file (atom file). When changes were made on the running local server, you could see the states of variables, updating in real time. So if he were to select three letters in the application running on his local server, you could see those letters show up in this file live. And this is true also in reverse. If he makes changes on the variable states, those changes show up on the application that is running locally. Pretty neat!

Structure editing: lisp code has all the parentheses and nested lists everywhere describing the tree structure of your program.

Clojure immutable data structures: As described above, if you describe a vector somewhere, you can count on that always referring to the same vector. Even if someone else comes along and tries to get another reference to that vector. This solves the errors that can occur if you have aliases to the same data structure and multiple places where you are editing it.

The Frustrations

Mental model error: Conflating seq and vector.

Sequence abstraction (seq) is one of the central organizing ideas to Clojure’s standard library. A seq is a logical list but it is specifically an abstraction. Like a vector or a list or an inherited Javascript type. The core definitions of seqs are: the function first, which gives you the first thing from the list, and rest, which gives you everything else. Sounds simple but the ramifications are super powerful. Important to know, seqs are lazy. Which means they’ll only evaluate members of the seq that you are asking about specifically.

Vectors are ordered, indexed, immutable collections of values. A fundamental data structure in Clojure, kind of like arrays in other languages. But the big difference is the immutability. A property of vectors is that they are associative unlike seqs. You can care about any position on them, just like an array. Associative means that we’re mapping between key and values but Clojure takes it a step further and says, since vectors are mapping keys that are integers, they are also associative.

The issues with the mental model error was thinking that seqs and vectors are interchangeable. This is obviously not true. The abstraction goes one way. Lots of confusion was had when working with vectors of vectors but using seqs.

Big functions: The base of this is more tactical. Mistakes were made due to being in an unfamiliar programming language. In functional programming, specifically Clojure, the functions are smaller than anticipated. In JavaScript it’s easy to write a big messy first draft and then pull out smaller functions from that bigger one. This is a mistake in Clojure. You want to start small and build the big out of the small. One of the big benefits for doing it this way, is you accrete an abstraction layer around your data by writing small functions.

Overall, it seems like from the conversation that ClojureScript is a really nice expansion and allows for some awesome interactive development as long as you keep the underlying organizing ideas of Clojure in mind. Happy coding!

Welcome to Claudeville

2026-04-06T08:43:00-05:00

For the past couple of weeks, I’ve been reluctantly using Claude Code. This is “reluctant” for a host of reasons I don’t want to get into at the moment, because I don’t want to turn this into a diatribe or rant, or a series of rants (no promises). Instead, I just want to talk about what I’m experiencing.

So first of all, why am I using it? I could say a lot about the genie being out of the bottle, or trying to keep up with the times, or whatever else. But the real truth is that I was deep in the doldrums and I was having a hard time thinking of what would make me feel worse. And I had access to an account, so I thought I might as well try it out.

Now here I am, two weeks later, with my meds adjusted, and I’m still using it. And I’m still reluctant, but less so. However, no small part of that lessened reluctance has made the lateral-at-best move to wariness.

And there’s the vigilance. So much vigilance. I’m doing so much checking and re-checking — verifying the code does what it should, and does what it says. Verifying the tests do what they say, and cover what they should. Verifying all this sticks to the plan.

Yes, the plan. That’s one significant reason I started using this and am continuing. And it’s not “plan mode”, but picking up a workflow I saw that really spoke to me. Let’s call it “ADR-driven development”.

Seeing this pattern really made me think this could actually be a thing. Because I didn’t want to use these tools to do small things. And I didn’t want to use them in fully-autonomous ways. Really, even what I’m doing now feels too much like managing and not enough like building, especially for someone who cares about “the craft” as much as I do. But what else do I care about? I care about ADRs. I care about documentation. And I don’t always have the time and energy to do these things when I also fall into the common trap of “working code is what matters”.

So what’s “ADR-driven development”? It’s just a fancy name for using Claude Code to write up an ADR based on what I want to do. How does that compare to “plan mode”? I’m not 100% sure because I don’t use “plan mode”, but I gather the most-significant difference is that the “plan” lives in the session and is maybe saved in a file that could be who-knows-where, whereas an ADR lives and is tracked in the repo, in a directory of more ADRs that get created over time, so you can see a history of decisions and changes. If you can’t tell, I consider an ADR a useful artifact in and of itself, something worth saving and sharing.

No small chunk of time and effort is spent creating that ADR. There’s the initial creation and reading it over, and then there’s the refinement loop of checking things out, suggesting changes, reading over the changes, checking things out, suggesting changes, &c. Sometimes “suggesting changes” takes the form of asking for clarification or fleshing out some points, and sometimes it takes the form of pointing out something in the ADR is just plain wrong, or there are inconsistencies. Sometimes “checking things out” takes the form of a quick jaunt into a console to see how some code works, and sometimes it takes the form of reading documentation, cross-referencing it with forum or blog posts, and going further than just a quick jaunt for the testing. In one case, where I wanted to consume and process webhooks, these two steps together took the form of giving up on documentation and capturing several real responses to feed into the context. This not only finally got past a cluster of mistakes, but it also meant I had more useful documentation to save and share in the form of those sample webhook responses. And don’t worry — it was all staging / test data.

It’s only when I’m satisfied with the ADR that I allow it to be committed, and then the next step is just to request an implementation of the ADR. But that’s only the single very next step. That has its own check-suggest-read refinement loop, which can involve pointing out inconsistencies between the implementation and the ADR (and deciding which one should change), or finding more wrong things like bad assumptions when integrating with external services, or any of a host of problems from violating style guidelines (either personal or configured in the linter) to large structural issues. And for the most part, I’m checking everything over and reading it all myself, but I’m requesting Claude Code do the changes.

I don’t know where the workflow will end up, but this is what I’ve been doing, progressing from an initial tentative dipping my toe in the water to making basically no edits myself. I’ve been going for an immersive experience, trying to feel out what the tool can do. It’s partly an attempt to adapt, partly an attempt to best use whatever energy I have for work after waking up in the morning and remembering that I live in this world.

But it’s still tiring, and frustrating. And takes so much vigilance. Claude Code provides results that are so much better than any of my previous attempts, which were all painful and maddening: just arguing with a chatbot about the obviously-wrong things it’s doing, and having it go back and forth between previous wrong solutions as I attempt to provide more context. But sometimes better is worse? Those obviously-bad results were so easy to dismiss. The problems and mistakes I’ve been seeing here are smaller, subtler, more insidious. I need to be so careful and review so much.

And what’s most tiring and frustrating is seeing what happens when people don’t do this review, or neglect this vigilance. It’s tiring and frustrating to spend my time and energy being careful with 90-95% of this and get worn-out and sloppy for the last 5-10%, and that’s where I miss a problem. And it’s tiring and frustrating to have to spend my time and energy being careful with code someone else has produced using a tool like this, without checking it over themselves.

And it’s tiring and frustrating to be well aware of the long history of complaints about new technologies, going back to the invention of the written word — famously (and ironically? or fittingly?) immortalized in Plato’s Phaedrus. So I know that I sound (and sometimes even feel) like an old man shaking his fist at the clouds when I complain about this, but I also have some significant concerns. Three main ones, in fact:

Not understanding what’s going on with the code you’re producing and should be responsible for. I think it’s great to use higher-level things and appreciate the abstractions — I moved on from C and memory management long ago — but it’s not great if you don’t have an understanding of what’s going on underneath it all, especially when things go wrong or the abstractions start to leak.
People disparaging themselves and their own skills, also connected to anthropomorphizing the tools. Some people will have conversations with the tools, reach an understanding, and attribute that understanding to the tool. They’re essentially rubber-ducking, but since it’s happening with something that talks back and affects a personality, they feel like it’s all external and not something they did themselves.
Depending on more external tools and services to do the work. No internet: can’t work. Payment stops: can’t work. Tokens ran out: can’t work. And this dependence being not on something that’s a commodity or a public good, but instead belonging to a private company with a vested interest in extracting as much value from you as possible.

I acknowledge that I may be a curmudgeon, and that caring about the craft doesn’t necessarily mean one particular thing. You’re not less of a woodworker if you use power tools or machines instead of hand tools, and you’re not less of a programmer if you use a higher-generation programming language instead of assembly (or binary). But this does feel different to me, and as a difference of kind rather than merely of degree. As I said before, I feel like I’ve been delegating and managing, rather than building. Other people might not feel that way, or they may be fine with it. I’m not a big fan. It does not spark joy.