I’ve started learning into the various AI-isms in my prompts. Most recently, em dashes to chain related information in a single sentence.
“Something something main point — but also pay attention to this related thing — finish main point.”
Anecdotally, it seems to produce more consistent results when I “speak its language”.
On the output side, I’ve become much more aggressive about trimming and editing any prose it produces that I intend on sharing. Both for my own benefit to improve comprehension, but also because dumping the raw, verbose output on my colleagues feels lazy and disrespectful of their time.
What’s interesting is that it maps well to how my brain actually works. My chain of thought is very non-linear. Maybe even a little chaotic, going off on tangents before returning to the main thread as it were. This has always made written and verbal communication a bit of a challenge, but the AI seems to parse my unedited stream-of-consciousness without issue.
I had a similar situation where someone had their email client configured with my address in the reply-to header. We shared a first initial, last name, and isp… also happened to be my email address. His email was firsnamelastname, or something similar. I emailed the guy several times explaining how to fix it, and that I was getting a lot of his business correspondence. Never heard from him.
Then one day I get a Chase Zelle email saying that someone was sending me money. Something like $500. Logged into the Chase app and sure enough, could have taken it with the click of a button.
I contacted the sender to explain the situation and recommended they call the intended recipient for a correct email address.
Couldn’t image just taking it knowing it wasn’t intended for me.
Had a similar experience. Was at a party when I suddenly received a notification from our country's equivalent to cashapp/Venmo. It was about $450, so not a lot but enough to be significant to many people. About a minute later I get a call from a seemingly young man who's very stressed telling me he sent the money to the wrong number and asking me to send it back. I told him don't worry I'll get your money back but I need to contact customer service first just to make sure it's safe for me to do so. I wanted to avoid some kind of charge back scam or similar.
So I called CS, they said it was safe to return the money and so I did and the guy called back just to thank me.
The insurance requirement isn’t uncommon where I am (California). Though I would avoid whatever plan they are pushing. I got mine through my existing insurance provider and it worked out to ~$15 per month IIRC.
Same here. Little side projects and convenience tooling for $day_job that otherwise wouldn’t have gotten built for lack of time. Doesn’t need to be perfect, beautiful code for an audience of one. It just needs to work.
My personal experience: writing code has always been the easy part. AI does most of that now.
Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.
I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.
As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.
What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).
> My personal experience: writing code has always been the easy part. AI does most of that now.
The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part.
If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved from dev to BA.
> Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load.
I've found that the act of physically writing refines my understanding a lot more than simply reading.
We don't typically expect a person to read a trigonometry textbook and then perform well on an exam. They have to drill problems to surface their misunderstandings to themselves.
My fear is that, with developers adopting your approach, they're "designing" systems in much the same way that a read-the-book-only trigonometry student solves trigonometry problems.
GP's "design the right solution" is a role between "programmer" and "business analyst" that got merged with "programmer" to become "developer" decades ago. That's where the high salary came from. It's been reemerging as "architect" now that "developer" has been watered down to include "programmer".
thank you for putting into words that which has been hard for me to describe — I’ve noticed the worse a dev was at their job the more high their opinions of AI seem to be. The subject textbook analogy (trig book in your ex.) is a perfect frame of reference for why that might be the case…
to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians
other thing could be also true, if you are great developer who spent decade honing their craft (vim, working on hobby projects, grinding when your friends party) you would hold cognitive bias against it as it flips the script. I don't think our profession is going away, but the shift is happening and it's not very comfortable one.
Perhaps solution was the wrong word for me to use here. It was intended to encompass the implementation details (abstractions, architecture, observability, etc)… All the decisions the engineers would normally make during planning and execution. Once I have that nailed down, the act of writing the code is largely mechanical.
That’s the source of my “easy” framing. It has always had the lower cognitive load in my experience. Now that I can offload the mechanical part to AI, I spend more time on the hard parts.
I still read plenty of code along the way, maybe less of it now because it’s easier to surface which parts of the code I need to read.
There was a time back in the 1980s (and probably before) when "analyst" paid better than "programmer". The programmer wrote the code; the analyst figured out what the code was supposed to do to meet the business need.
In my view, "programmer" merged with "analyst" to become "software engineer".
> Who hires “pure solution modelers”? I don’t think I’ve ever encountered someone like that.
They're called Business Analysts, sometimes simply Analysts, and that's effectively their job - come up with a spec and give it to the software engineers.
Agreed; typically (especially if a client is involved) I’ve seen creative and dev define and articulate spec and expected behavior, and BA documents it. Then, when it inevitably evolves, BA’s job is to capture the changed spec. The artifact is simply documentation as a client deliverable that’s then often never referenced or used for anything outside of maybe complaining that a feature doesn’t do what the spec claimed, or maybe as context when the client takes their whole project to another vendor to be rebuilt from scratch lol
> What seems clear to me is that expectations around velocity and throughput will increase (are increasing).
This is why I don’t understand why folks around here (that are employed) feel so enthusiastic about AI. We are going to be working more in a rush to produce stuff that we won’t be feeling as proud of as we did before AI. Unless you were in the profession for the money, the delights of crafting software simply go away and AI is pushing us closer to be just… well, I don’t know, but I don’t like it. Sure thing, if you are a CEO, this new state of things must be wonderful
There was a recent interview with Dax Raad on the Pragmatic Programmer podcast, and they talked briefly about it. We would like a future where we do just a bit more work and are happier with legacy codebases or work on getting rid of tech debt, but that definitely won't be something our employers are interested in.
> My personal experience: writing code has always been the easy part. AI does most of that now.
That's exactly why I don't have AI writing my code. It is doing the easiest part of the job (making symbols appear in the text), which isn't actually valuable to me. A good tool should help me to do hard things, not easy things.
I didn’t know modern (2015-2026) software engineers were making such a strong distinction between “writing code” and “designing solutions”. It’s not the majority of engineers “design” and then hand over the implementation to others (at least Ive never seen that before).
From my experience, a typical software engineer needs to understand the business (e.g., knowing who your users are), design a solution (e.g., we probably need an event-driven arch right here) and write the code (e.g., we should use select for update skip locked to avoid over claiming). They all are equally challenging imho
Agree. Also, there is a lot fog at the moment. AI generates more code, we need a lot of markdowns now to teach it how to write "good code"... and <insert here a lot of AI processes>. But at the end... a programmer has to take ownership of that code and responsibility, meaning: reading A LOT of code and/or coding more code.
Responding to my own comment to add that I think this moment favors the curious and passionate. None of what I wrote above is a complaint. I’m having more fun now than I have in a long time.
Overnight oats have been my go to lunch and pre workout meal for a couple years now.
75g 0% Greek Yogurt,
75g Almond Milk,
10g Maple Syrup,
8g ISOpure unflavored protein powder,
8g PBfit powdered peanut butter,
Salt to taste.
Whisk everything else together in one bowl. Pour over 85g of old fashioned oats and stir.
511 calories, 79g carbs, 30g protein, 9g fat. Easy to tune the recipe to macro targets.
One specific example that comes to mind is developer tooling in the form of bash scripts. Sure, I can write it myself, but I do this so infrequently that there is a cost for the context switch and ramp up. This, and similar dev ex things that have been languishing in the “one day” pile because there is always the next feature to build. I can now spend 10 minutes here and there to ship incremental QoL improvements alongside my core work.
You don't have a scripting language in your toolbox that you're comfortable with?
I would probably say a shell is "the correct tool for the job" but other than the appeal to authority, or appeal to tradition. There's not a great argument for a shell script over a language you're already comfortable with.
There are hundreds of examples that are easier or faster in python than shell.
Engineers are bad at making tooling, we're even worse making ephemeral tooling we're willing to throw away. Contrasted with other makers, you have machinests who gladly make a one off tool to make a single process easier.
The more 'correct way' than a shell script, is something simple and composable. A large unwieldy shell script that you can't make simple changes in, is terrible design, and it's a mistake to allow that inertia to gain speed.
It's not exactly a complete refutation but something I've been thinking about recently.
I’m still a couple decades off from “senior”, but I have already reached a point where most day to day driving feels like a chore. If/When Waymo finally arrives in my smallish Bay Area city I can see myself using it a quite a bit. Hopefully self-driving cars are ubiquitous by the time I reach “shouldn’t be driving” age.
Multiline autocomplete is still the biggest productivity boost for me. This works well in a familiar codebase with reasonably consistent patterns.
After that it’s the “ask” capability when I need to get oriented in unfamiliar and/or poorly documented code. I can often use the autocomplete pretty effectively once I understand the patterns and naming conventions.
Similarly, agents are good for a first pass triage and plan when troubleshooting tricky bugs.
Still haven’t had a good candidate for going full vibe code. Maybe that’s because I don’t do a lot of greenfield coding outside of work, which seems to be where it shines.
Just my experience. It’s new set of tools in the toolbox, but not always the right one for a given task.
I should clarify. I do very little greenfield development, even outside of work. So my understanding of vibe coding being good for this use case is largely rooted in the relayed experience of others.
